There is no difference between the notion of Test-Driven-Development and that of Test-Driven-Design; rather the former implies the later, meaning the Test-Driven-Development brings to Test-Driven-Design. The benefits of TDD are obvious, many studies have been carried out and some say the results were mixed, but if you approach TDD from the logical point of view, it is definitely worth giving a shot.
What it has to offer?
The core principle of TDD is that there is can be no code without a test that covers that code, even the test comes first. Yes of course it fails, while there is no code, yet it starts passing as soon as the functionality that the test is written to assert is implemented.
So, let’s elaborate the paragraph above using simply common sense. Since in TDD the tests are developed first, we can say that all the code implemented is covered with Unit Tests. In the contrary in traditional software development sequence, sometimes the unit tests get procrastinated due to other top priorities. What we have got so far is that we can explicitly say that it increases the code coverage. If the code coverage has increased, it means that the units of functionalities get tested regularly, and every new born defect can be quickly found. This is the obvious benefit that TDD has to offer.
Test-Driven-Design is largely a consequence of Test-Driven-Development. When the developers work using TDD they have more insight into the functionality they develop, because they have to think about testing it beforehand. The developers who utilize TDD produce code that’s cleaner and less coupled. Similarly TDD improves also the quality of the Unit Tests, because the developers know they will have to visit the tests many times and try to make the tests as clean as possible.
TDD improves the transparency of the developed code, being able to feedback instantly on the quality. If the developers also utilise refactoring, the practices will led to a better organised and side-effect free and maintainable code.
Does it affect productivity?
Whether or not the TDD affects the productivity largely depends on the maturity of the development team that follows the notion. There is no doubt that the introduction of TDD will include a learning curve and it will take time for inexperienced developers to digest the methodology. Another aspect of TDD that needs to be taken into account is the fact that since TDD implies many tests, these tests will need to be maintained, and taken care of. That will mean increase of the build time due to the tests, many failed tests due to changed functionality, however all these will prove to be essential for the quality of the software developed.
Further maintenance of code/software also needs to be considered in the light of TDD, because TDD makes the code and the developed software itself more maintainable implying reduced maintenance time.
Shall we give it a try?
There is no logic or test that would correctly suggest that TDD makes the procedure worse and the simple practices of TDD unequivocally make the software better by trying to pin point code problems. It also makes the developers think about the quality, especially students and junior developers, since they have to write the tests in the beginning.
It may be hard in the beginning, but once the knowledge has been gained and shared, and there is a shared understanding of the simple principles the code coverage will increase, test suits become larger and as a consequence the software more robust. It is worth giving it a try.