TDD revamped, five years and many more to come
The content here is under the Attribution 4.0 International (CC BY 4.0) license
This post goes through my journey that started at least five years ago with testable code, specifically using Test-Driven Development (TDD). I remember when I found it out it was a moment of magic, even though, it took some time for me to realize that TDD changed my way of thinking. Not just about my code, but about software development in general.
Throughout this post, there are references on the first TDD international conference, XP and agile, if some of them is not familiar to you, feel free to jump to the references.
As a companion, I offer a youtube playlist that I built (and maintain) over the years as my interest in TDD grew. The playlist is a walk through TDD, starting the basics and leveling up on each video. I tried to build a video sequence that makes sense and hopefully will have a chronological timeline that progresses bit by bit, from basics to more advanced concepts.
A tale of a newbie
I don’t recall who introduced me to that, but I do remember reading the iconic book from Kent Beck, TDD by Example on my commute time. Every page that I turned, it was a new discovery. Also, with some frustration, because the baby steps was conflicting with my confidence that my code would work. “Of course it will pass the test, it is hard coded”. One of the listed misconceptions by  is related to that kind of thinking.
On the other hand, thinking about when I started, the context where I was, did not help me to improve my TDD skills. Places that I worked at in the past unfortunately care more about the task delivered, instead of the value added, going against the XP  values.
Keep on going
One of the biggest challenges form my professional career was to keep going with the test first approach, often, the projects I joined didn’t have any culture test and as a result: no automated tests (be it TDD, ITL, or any kind of test, really). Some of them, I had to build the culture myself, and build the mindset from the ground up.
For that, I used different techniques, in which I found to be the right next step. For example, I used the test pyramid described in the book succeeding with agile by Mike Cohn  and  as a guide, but instead of having a solid unit tests in the bottom first, I started by writing e2e tests in a way that the team would start to build up the unit tests. I also shared my ideas with the PHP community in Madrid around that that topic.
Moving way back, I also shared my process and opinions on TDD. For example, I took notes while reading TDD by example by Kent Beck, as a follow up on this post, I started a two parts blog posts named “Are you not using TDD?”.
Part two, was focused on legacy systems. Thinking about the timeline, it was the next challenge I had while learning TDD. I started on a relative new project and I remember being the only person in the team using TDD, which later, led us to refactor the “legacy” code in the same standard. This post is code heavy and depicts a piece of code that was legacy, and gives an alternative to that.
I also wrote about a polemic trend on TDD that appeared one year earlier from that post, asking the question “is TDD dead?”. I had strong opinions regarding TDD, but listening to the videos and the conversation between Martin Fowler, Kent Beck and DHH, helped me to keep practicing even more.
Finally, one of the most recent posts I did around TDD is related to the misconception of code coverage, there I elaborate on how I see the coverage being used (usually in the wrong way) and I try to put together why teams should not aim for coverage.
I don’t believe I achieved many things, but certainly I feel that I am more confident writing code, and not only for me, for further developers on my team or the open source projects I collaborate to. TDD changed my way of thinking about code and about how I develop software, and clearly influences me till today.
Testable  , is one of the things I spent time building as part of my research project. The focus is to use gamification and teach unit test, I consider this a first step towards the full TDD cycle. During the research time, I found that the lack of focus for studying on producing testable code and on top of that, the boredom that students feel when testing code. Testable tries another way of teaching to tackle those issues.
I feel that I have been working with TDD for a while now, it gives me comfort while writing code, I don’t feel weird when starting from the test first anymore, nor, I feel that it is obvious that the test case will pass, it is hard coded anyways. TDD is kind of a companion, and when I am not test driving, I feel uncomfortable.
Still, I know that there are thinks I need to practice or to keep improving. Variations of TDD come and go all the time, for example, the classist approach or the mockist approach. It is a medium that keeps improving, the industry is pushing it even further, dedicating a full day to talk about TDD. Meanwhile, I am trying what I can to keep sharp, on top of my game, for that, katalyst helps me.
- O. Borzenko, “TDD Misconceptions,” 2021 [Online]. Available at: https://www.youtube.com/watch?v=TbkBMeAt4K0. [Accessed: 29-Jul-2021]
- C. A. Kent Beck, Extreme Programming Explained: Embrace Change (The XP Series). Addison-Wesley Professional, 2004.
- M. Cohn, Succeeding with Agile: Software Development Using Scrum. Addison-Wesley Professional, 2009.
- H. Vocke, “The Practical Test pyramid,” 2018 [Online]. Available at: https://martinfowler.com/articles/practical-test-pyramid.html. [Accessed: 29-Jul-2021]
- M. Marabesi and I. F. Silveira, “Towards a gamified tool to improve unit test teaching,” in 2019 XIV Latin American Conference on Learning Technologies (LACLO), pp. 12–19.
- M. Marabesi and I. Frango Silveira, “EVALUATION OF TESTABLE, A GAMIFIED TOOL TO IMPROVE UNIT TEST TEACHING,” in INTED2020 Proceedings, 2020, pp. 330–338, doi: 10.21125/inted.2020.0150 [Online]. Available at: http://dx.doi.org/10.21125/inted.2020.0150