360Logica.com

Component testing offering:
Every small systems can require a large number of test cases. Prioritization orders the test cases based on the amount of resources that will be allocated but it does not organize the cases into a logical model. If an iterative development process is being used, the problem of a large number of test cases is compounded by the continuous change of the development products. The test cases must be maintained in synch with the current state of the system; however, changes to the production system must first be tracked to the appropriate test cases.

That perspective views the software being tested as intended for integration with other pieces rather than as a complete system in itself. This both helps to determine what features of the software are tested and how they are tested.

There are several situations in which the individual component should be tested regardless of their size or complexity:

Reusable components - Components intended for reuse should be tested over a wider range of values than a component intended for a single focused use.

Domain components - Components that represent significant domain concepts should be tested both for correctness and for the faithfulness of the representation.

Commercial components - Components that will be sold as individual products should be tested not only as reusable components but also as potential sources of liability.

360logica provides you value proposition if customer wants to get software tested upto very thorough level.

Unit testing offering:
360logica provides wide range of expertise in Unit testing using unit testing tools like Nunit, JUnit, and PHP Unit etc.

This is the Extreme Programming maxim, and our experience is that it works. First you write the test, and enough application code that the test will compile (but no more!). Then you run the test to prove it fails (see point two, below). Then you write just enough code that the test is successful (see point four, below). Then you write another test.

The benefits of this approach come from the way it makes you approach the code you are writing. Every bit of your code becomes goal-oriented. Why am I writing this line of code? I'm writing it so that this test runs. What do I have to do to make the test run? I have to write this line of code. You are always writing something that pushes your program towards being fully functional.

In addition, writing the test first means that you have to decide how to make your code testable before you start coding it. Because you can't write anything before you've got a test to cover it, you don't write any code that isn't testable.

Basic points about Unit testing: 

• Testing done to each module or class, in isolation, to verify its behavior.
• Typically the unit test will establish some sort of artificial environment and then invoke routines in the module being tested
• It then checks the results returned against either some known value or against the results from previous runs of the same test.
• When the modules are assembled we can use the same tests to test the system as a whole
• Usually performed by programmers.
• When we write unit tests we want to write test scenarios that ensure a given unit honors its contract (i.e. a given unit performs same function which it is intended to perform)

Six Rules of Unit Testing

1. Write the test first
2. Never write a test that succeeds the first time
3. Start with the null case, or something that doesn't work
4. Don't be afraid of doing something trivial to make the test work
5. Loose coupling and testability go hand in hand
6. Use mock objects

For more details, please write This e-mail address is being protected from spambots. You need JavaScript enabled to view it