Is TDD Really Extreme?

By Alex Yakyma.

Many organizations and individuals used to believe that Test-Driven Development (TDD) is some kind of really extreme engineering practice, and that it is something that only real fanatics would use as a sustainable routine. That is partially the result of the "guilt by association" tendency with respect to TDD, which as we perfectly know originates from Extreme Programming (XP) and really is one of the key practices there. But is it really so extreme? Or is it extreme at all? There is one big reason that we should not think so.

Quite often we witness a certain resistance among people, especially those who used to work in traditional (non-agile) environments, regarding TDD. They don't actually believe it works, along with most other agile engineering approaches such as emergent design, simplicity or continuous refactoring. According to them, design needs to be elaborated up-front and you can't "just develop" your software. Well, I can't agree with them more. In fact, we see how Intentional Architecture works very well (hand-in-hand with Emergent Design practices) on a large scale and represents an important balance of forces in Scaled Agile Framework. I very much agree that you can't develop software without, at the very least, some up-front analytical thinking. Thus, the argument is understood, appreciated and is conceptually applicable. However, there is one little problem with such thinking...

If we take a closer look at unit tests or component tests we will discover an interesting fact: tests that critique the behavior of classes or components actually behave just like their "clients" (figure 1).


Figure 1. Tests simulate the behavior of "client" classes

Thus developing classes and components along with the tests - and especially after the tests represents a way to think through the design prior to its actual implementation. Design is basically the way in which entities in the code are going to relate to and interact with each other; unit/component tests really provide a way to model that interaction up-front. That simply means that TDD is an example of a practice that tremendously supports up-front design. So how is it that it could cause any troubles for people that believe in intentional design effort? If someone thinks that it is possible to plan the entire system design weeks or even months up-front, why then would it cause such a big problem for them to define a much smaller piece just a few minutes away from its implementation? …Because that is exactly what we do in TDD with tests - we actually define internal system organization and behavior a little bit up-front. 


Looks like the takeaway is quite simple - we shouldn't view XP practices (and especially TDD) as something really extreme. Sometimes just looking at something like this at a different angle helps people that used to work in more traditional process environments to find a clear rational behind agile engineering approaches. Meanwhile, it helps agile people realize that agile, in fact, does not at all neglect up-front analytical thinking but vice versa – utilizes it continuously.

No comments:

Post a Comment