An approach to improve the TDD flow

The continuous learning in acquiring a new skill becomes harder as time passes. With TDD happens the same, but there are different flavors of this phenomenon. I have been in contact with many professionals who support and disregard the practice, who disregard the practice and have strong arguments regarding the maintainability of the tests and who support are towards the short feedback loop. Despite both of the groups, they had to start at some point and evolve the practice and incorporate that in the day-to-day to evaluate better the pros and cons.

Supporters and detractors

Supporters that are successfully applying TDD daily have a common approach to keep sharpening their skills through code katas. They have the habit of learning and iterating over a problem to train new techniques. The katas are usually practiced within a group or individually. There are special events dedicated to that known as code retreats. References in the industry support this kind of approach for learning.

Professionals who are proficient with TDD also have a trait of recognizing that it is a continuous learning journey even when they are considered experts in the subject, besides, the constant evaluation of the context of the problem and the fit to use or not TDD is also combined with pragmatism.

Detractors of the practice also have common traits that are spotted in the conversations or the results of the tests written. Detractors of the practice display a shallow understanding of the practice, as the flow consists of three rules, reading once or twice makes it reproducible. Therefore, the translation from the theory into the practice is the bit that is lacking for this group.

They also have this urgency of “this is not possible to test” or “we don’t have time to do that”, which in the long term increases the entropy in the entire software chain, not only in the technical aspect. The 20th-anniversary edition of The Pragmatic Programmer depicts the effects that entropy has and how to resist [1].

I also refer to this behavior not only with technical people who develop software often in the industry business representatives are the ones that install this kind of thinking in developers’ ways of working. More experienced developers tend to resist more often however less experienced professionals might bend earlier and believe that this is the way they should be doing things.

In the clean architecture book and other presentations by the author, there is an example and a shirt that depict exactly what happens with the software’s lifetime when such behavior is adopted. One of the results is that businesses try to get a value less frequently and with more defects. Of course, this is not only related to the TDD practice. It is also related to other aspects such as the software architecture. Now that we have an idea about those two categories or two groups before moving on I would like to make it clear that code katas are often practices isolated from a professional context meaning that there is a difference between doing the kata and applying it in a real project industry. this distinction is fundamentally important because it reveals a deficiency of the industry and also of the ways that the education is being done because of that.

The latest research done by Tramontana et al. reveals that only 39% percentage of universities in four European countries offer a software testing subject in the computer science curriculum [2].

So the tractors as I am referring to people that do not incorporate TDD as a professional and society need to think about how programming and more specifically software testing is being taught to fill this gap.

In the next session, we will start to see concrete actions and what to do to start elaborating on a plane through katas and to improve the TDD practice.

Assessment

code katas also have different levels and different objectives. To that end, before he starts to do writing and gold or true diving to a new Kolkata it is also important to self-assess understanding of the practice of TDD and the theory that is behind it. before it started too cold, I would recommend to answer the following questions

• Do I know the TDD stages?
• Can I write code fluently without thinking about each TDD stage?
• Do I feel comfortable thinking about test-first?

It is not a requirement to answer all the following questions, but those might help one self-reflect and think about their practice.

Most of the katas are defined into categories the first is the level so you might find katas that are for beginners katas. There are four experts and katas. There are four intermediate levels and the other is categorisation by Objectives for example a cold kata to exercise my understanding of TDD outside or an exercise in which we focus on a single design pattern for example comment pattern. Understanding at which level or which objective what might have becomes a matter of decision which kata to pick so for example if I am just starting with TDD, I would pick fish bus if I feel that I am competent and I’m comfortable with TDD already I might be the bunk kata. The following list is a shortlist and just aims at giving minimum options for whoever wants to have an idea of what to do in each level The following list is a shortlist and just aims at giving minimum options for whoever wants to have an idea on what to do in each level.

A maturity model for the rescue

For years, the maturity model has been applied to different areas of knowledge. For software specifically speaking, two types became widely spread by academia and by the industry: DevOps and rest APIs. The DevOps maturity model has different proposals among authors but the foundation remains the same. The goal is to provide consumers with a baseline of the path toward the highest level in the maturity model. Mohammad et al. researched the different types of maturity models available and created a list of the levels and dimensions of each one of them [3].

In the API space, the Richardson maturity model is widely used and spread to categorize at which level a rest API is. It has 4 levels. The higher it gets the more mature an API is considered.

Put it into practice

Now that you are ready with the minimum schedule, it is time to put it into practice. code katas are meant to be not an extensive problem but a problem that gives enough challenge that keep you learning and give you room for creativity as well. In that sense for each Qatar that you pick and start to exercise it is important to push it to completion. There is no need to complete the kata at the same time that you’ve started however Abu device that keeping up from starting and finishing the kata is a good approach, once completed you might want to reflect on what went well or what you might do differently and what you’ve learned.

At this moment it is often a good idea to ask professionals or people who are references in the subject to go through your line of thought how you developed the solution and how you wrote the code those professionals offer valuable insights and tips for the next iteration that you decide to write and go over the kata again.

Repeat

What we have discussed so far does not mention anything regarding repetition. However, repetition is one of the key aspects of the code the problems that they solve are not necessarily really complex ones because they are meant to be repeatable so then repeating will make you more proficient and make you more proficient we allow you to unlock new skills.

In that regard, the repetition is a key aspect. Once you have completed a cold Katner reflect on it and try to repeat it over and over again applying or improving on the reflections that you had.

References

1. [1]D. Thomas and A. Hunt, The Pragmatic Programmer: your journey to mastery. Addison-Wesley Professional, 2019.
2. [2]P. Tramontana et al., “State of the Practice in Software Testing Teaching in Four European Countries.”
3. [3]M. Zarour, N. Alhammad, M. Alenezi, and K. Alsarayrah, “A research on DevOps maturity models,” Int. J. Recent Technol. Eng, vol. 8, no. 3, pp. 4854–4862, 2019.