Test – Driven Development (TDD) has been proved to be the best practice for software development.

In the process of TDD a method can communicate with other classes to accomplish its function.  If we create a class that communicates firstly with this method we deviate from the concept of unit testing. For this case the concept of mocking is useful because we can mock the objects that the methods interact with so we don’t need real object to test that method.

TDD is a design and testing approach that produces automated Unit Tests, code and refactors. The unit tests specify and validate the functionality of small pieces of code. Producing more code will depend on as much code will enable the unit test to pass. Then the refactor will simplify the production code and the test code.

By TDD, writing new code is allowed only after a failing of an automatic test. Duplication has to be eliminated from the code.

The process is iterated as many times as necessary until each unit is functioning according to the desired specifications.

TDD Cycle:

• Write one test
• Write code to pass the test,
• Refactor
• Repeat

There are TDD misconceptions. Some understand that TDD is about testing, but this is wrong because TDD is about design. Automated tests are the lateral effect.

TDD is misunderstood as a suite of tests than building a system that passes the tests. TDD is a practice not a process like waterfall, Scrum, XP (Extreme Programming), TSP.  TDD is similar to pair programming, code reviews and stand up meetings.

Most people think that getting a red failure in JUnit console bar is bad. It's not! It is good; it means that you have found a potential bug to be fixed. Finding and fixing bugs is a good thing. Making a red bar become a green bar (by fixing the code and then re-running the test program) can be very rewarding.

As the compilers provide feedback on the syntax of the code, TDD provides feedback on the execution of the code. Mistakes are easy to find and fix.

In TDD, the test methods are written as in a class’s public interface. They focus on the class behavior, not its implementation.

TDD follows the cycle:

TDD can have of course common difficulties as:

• forget to run the test frequently
• too many tests
• too large tests
• writing tests for trivial code

Without TDD the programming needs to depend fully on manual testing. In non-TDD approach it will be used mostly debugging to test or find bugs.

We can detect that TDD is used in programming often in version control logs that should show that the test code is checked in each time that product code is checked in.

After applying TDD many teams have reported reductions in the number of defects but also a moderate increase in initial development effort.

With TDD the testing time will finally be reduced and developers don’t need to depend heavily on manual testing and testing with QA teams I shortened.