TDD misconceptions

The 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 talk 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 come from Unit Testing. It builds upon these concepts to construct a framework following which developers can build software components abiding by 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 are rooted due to a lack of knowledge in the community regarding the subject. Misinformed developers take the word from the sources with which they are confronted.

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 instead 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. The 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 one manages to understand what TDD is the job is still not done. Another misconception is ready to creep in: 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 a bit sluggish is what I call the unlearning phase. You are accustomed to following 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 strategy. Let the results speak for themselves but for someone to say that it doesn’t suit him or her, someone should try it first. Don’t judge by the cover, let's 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 meet the definition of done.

Figure 1. b.

With 11+ years of experience in the field, Leanpitch has successfully upskilled 90,000+ people across 12+ countries. Explore our website, Our trainers are internationally acclaimed for their insightful and experiential training.

We upskill and boost your career by providing a wide range of courses such as CSPO, CSM, ICP-ACC, etc. Visit our website to learn more about all the courses we offer.