How Extreme Programming (XP) started my TDD journey

In a previous post, I mentioned how I happened to land in JUnit while I was trying to find implementations of design patterns. In this post, I will talk about how I could take that test automation to the next level by practising Test-Driven Development (TDD).

I first learned about Extreme Programming by reading an edition of DeveloperIQ, a magazine. One of my friends attending medical school gave me a book on Java and a few editions of a magazine called DeveloperIQ. The only XP I was aware of at the time was Windows XP. I hadn't even heard the term Waterfall (Waterfall model of software development). The XP article from the magazine mentioned the book "Extreme Programming Explained" by Kent Beck.

It took me a couple of years to get my hands on the XP book. Before that, I had read a few articles from the authors of the Agile Manifesto online. By this time, I was studying Software Engineering as part of my college curriculum. This was the right time for me to explore XP, and I read Kent's book. Even though I did not have much real-world software development experience other than my pet projects.

One of my key realisations from reading the book was how testing suffers when waterfall model based software development experiences delays. Also, I discovered this interesting practice called Test-Driven Development (TDD). I can't remember what aspect of TDD inspired me to start with it, but I can say I was confident that TDD would add value to my professional skills. However, I didn't find many people who thought TDD would work for the next several years.

By then, I was working on a few projects on .Net technologies and decided to try Test-Driven Development (TDD). I committed all possible silly mistakes while practising TDD. For example, my tests worked only when they were executed in a particular order. Also, a test's failure led to the failure of subsequent tests due to the use of shared data between the tests, and data was corrupted by the first test, etc. I believe these are stages one has to go through while learning Test-Driven Development. There is no way one will become an expert TDD practitioner in a very short period. I observed many developers committing these mistakes while working at software development firms.

I continued practising TDD in many projects, even in cases where writing automated tests wasn't mandatory. This was because I myself benefited from TDD. So, it wasn't about compliance or pleasing someone else. Later in my career, I got opportunities to work as a TDD coach for software development teams. This would not have happened had I not trusted TDD enough to give it a try.