TDD misconceptions
Test first approach is a widely misunderstood concept in the industry. Did people understood 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 an implementation and adoption of the concepts that agile and scrum talks about. How would you realise 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 of 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 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 approach 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 other way round. These misconceptions rooted due to lack of knowledge in 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. 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 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 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 loose precious productive time in a timebound sprint. This is more of a mental model formed due to the legacy approach. 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 suits him or her, that someone should try it first. Don’t judge by cover, lets plunge in and take a swim through the process before calling it off!
Leanpitch Technologies PVT LTD
309- 4th B Cross Rd, HRBR Layout 3rd Block, Kammanahalli, Bengaluru, Karnataka 560043.
Comments
Post a Comment