There was a time when I began to use JUnit to make integration tests to test a few sections of my code because it was faster than testing the Web Application Server, and it confirmed that my code was working. After some time, I read about a software development process known as TDD, or Test Driven Development. TDD is “a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved to pass the new tests, only.”
The first time I heard about TDD, I wondered why it was becoming popular, so I set off to do a little more research., I began my journey into the TDD world with a book titled , which serves as a how-to reference for test driven development and programming.
The book made me feel like TDD could work as a programming approach, in part, because the examples were very easy to digest. I came to see the TDD technique is powerful but also comes with a change of mindset, and a change of paradigm toward thinking of unit test development as an integral part of creating code. The question I was left with was how can I most effectively adopt this software development process?
The first step was to learn more about putting TDD into practice. I began to looking for sites on internet about TDD and found some web pages that really helped me on my TDD journey:
The second step was to tell some developer friends about TDD and create a study group. This started our TDD kata as described in the web references above. We collaborated as a group to build our TDD skills and help each other through the learning process. However, when we moved from theoretical exercises to real programming, we got stuck.
I remember being in a job where I got assigned a ticket related mostly to SQL sentences and string manipulation, so there wasn’t much need to communicate with other systems (where I had gotten bogged down in the past). I thought it was a good opportunity to use TDD, so I began with the well-known TDD cycle:
TDD was working very well with almost 21 test cases done, Then, a colleague of mine needed new functionality, which I added. When my colleague used SQL sentences with a real database, we discovered 2 test cases I hadn’t considered. I ran through a new TDD cycle felt the TDD approach made the project work.
Nowadays I know how to resolve most issues with the TDD approach. Still, though, I feel most conformable using TDD when there is little need to communicate with external systems or I don’t have to mock up components of external systems. Otherwise, when I have the opportunity to use TDD, I’ll do it because I think TDD produces a better outcome. As Ken Beck said “TDD encourages simple designs and inspires confidence.” It might even shift your software development in a more robust direction. I like TDD, and writing tests before code works pretty well in most situations, but I’m not dogmatic about it.
By Raymond Garcia.