Refer & Earn

TDD misconceptions

tdd misconceptions

TDD misconceptions

Amjad Mohiuddin
1st Mar, 2019

Test first approach is a widely misunderstood concept in the industry. Did people understand agile and scrum well? If yes, then it’s not difficult to convince them that TDD is great for them. So do you see where the actual root of the problem lies? There is nothing wrong if I say Agile/Scrum misunderstood than saying TDD misunderstood. TDD complements agile so well for obvious reasons. Consider TDD as the implementation and adoption of the concepts that agile and scrum talks about. How would you realize the concept of early feedback when you sit for implementing a user story, no better way to implement it than using TDD.

The core values of TDD comes from Unit Testing. It builds upon these concepts to construct a framework following which developers can build software components abiding agile/scrum principles. Where is the misunderstanding creeping in from? The decision power to bring-in and implement anything new lies with the upper management of an organization. If the value is not seen at this level, it will be eradicated in no time. I wouldn’t recommend any tool or process for the sake of recommending. There are two sides to each coin. If an Organization tried TDD and I mean the TDD in its pure form and then they realize that it wouldn’t work for them, I will be more than convinced. In most cases, if the Organization is coming so far then they would definitely see the positive results and would like to tap benefits by staying a little longer with it.

TDD is misunderstood in many forms, one disguised form that people mistake TDD for is, they think it is one of the manual testing approaches of a software component. Undoubtedly that is not true. Another common form of misconception is that people implement Unit Tests after writing production code and they call it TDD. Obviously they are doing it another way around.  These misconceptions rooted due to a lack of knowledge in the community regarding the subject. Misinformed developers take the word from the sources which they are confronted with.

Another matter of concern is the goal set for the teams. The definition of done is defined or rather dictated to scrum/agile teams that they need to achieve a coverage of x% and they need to thrive to meet it in order to get their work pushed through the production pipeline. Nevertheless, it fails to meet its purpose. Should we be concerned about the coverage paths as shown in figure 1.a,   which rather stands as a mere formality? Should you be following TDD then there’s no need to track the paths manually. It will be born implicit into the code as we inverse the starting points. Complete focus is to write your tests first and you get going on your think pads to cover all possible positive and more importantly negative flows. You write the production code just to pass these test cases hence you won’t find the red patches that you see in figure 1.a. If at all you see them then it’s a retrospective item that how did you manage to get it in the first place as you started with the intentions that you would cover the paths that you have written the test cases for.

If at all one manages to understand what TDD is the job is still not done. There comes another misconception ready to creep in, is that TDD is a laborious time-consuming process. You define test cases and have these frequent hops between production code and test code that you may lose precious productive time in a timebound sprint. This is more of a mental model formed due to the legacy approach. The initial time that may seem bit sluggish is what I call the unlearning phase. You are accustomed to follow pre-defined conventional steps which are formulated in a stipulated process. When you start breaking these habits with a new one it would take a while to tune your process. Let the results speak for themselves but for someone to say that it doesn’t suit him or her, that someone should try it first. Don’t judge by the cover, lets plunge in and take a swim through the process before calling it off!

Figure 1.a

      If I had to summarize TDD, I would do that by saying it’s a RED-GREEN-REFACTOR template done in that order. Each of these steps has its own significance. Figure 1.b talks about these mini-steps that you take in TDD. Repeat them again and again till you are done with the implementation and meets the definition of done.

   Figure 1.b.

About the author
Amjad Mohiuddin
Amjad works at ADP as an Architect. He is a technology geek and teaches TDD, BDD and Agile Engineering Practices
Follow on:

Upcoming Training

This website uses cookies to improve your experience. See our terms and conditions to learn more.