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:
- http://osherove.com/tdd-kata-1/
- http://www.peterprovost.org/blog/2012/05/02/kata-the-only-way-to-learn-tdd/
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.
What caused this real-world difficulty for the group? I think these issues started when our system needed to make queries to databases communicate with other systems. In these scenarios, we’d typically use a mock testing framework like to add behaviors to the unit test. But I soon realized even for a simple test we needed to mock up a lot of components. This couldn’t be the norm for TDD, but I couldn’t determine if these should be integration tests instead or if I still needed to do more TDD learning, and we were running into similar issues when trying to develop UI using javascript.
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.