Why Going Agile Excludes TDD in Most Cases (Revised)

You are here

This the revised variant of the formerly written post about my thoughts on inconsistency of test-driven development applied to agile processes, modified according to our LinkedIn readers’ opinion.

The agile practice called test-driven development (TDD) suggests writing tests before actual program code. It can technically increase the agility of the developer or product project levels. Among other significant benefits, existing empirical literature about TDD has also demonstrated more robust code and increased productivity. However, results show that sometimes TDD adoption is difficult and its potential agility benefits are not readily available.

Let's list the main points where agile excludes TDD:

  • TDD produces systems of higher quality, but also increases the time of development. TDD lets developers achieve high test coverage easier than by using the traditional techniques, but at the same time it forces them to also write unit tests which are an essential development part which cannot be left out. The evidence found in empirical literature shows the number of tests in TDD may vary from 50% more production code than test code to 50% less production code than test code.
  • Again, empirical literature indicates TDD is more difficult to use since it increases developers’ workload causing them to create not so functional code. Such prejudices are fought with support and training, especially at the outset of TDD adoption. Without the provided support, the TDD practice is unlikely to work. Also, it seems TDD does not fit all types of development environments. It highly depends on the used testing framework and requires developers using it to be skilled and motivated.
  • Finally, TDD is not that easy and many developers have some prejudices against this practice. Some of them assume TDD lets them write less functionality due to the test writing. Others are afraid of the difficulties they are to face while TDD adoption.

Thus, the resistance to use TDD at first is due to inexperience and growth in the amount of work. 
When no support for TDD is available, inexperienced developers slip back to no unit testing development, that’s why support is needed at least at the early stages.