Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Lessons Learned
I learned a lot from using TDD in a test automation project. I learned that for a testing library that automated tests use, unit tests might be a good idea. It’s another software service that we depend on, and is subject to change according to the changing requirements of the production software. In fact, the automated unit tests for my custom test library revealed a specification error in the production software when I got test data from a new build. When the specification was upgraded at the customer’s request, I simply added a new unit test and updated my test data to reflect it. The automation code that relied on this library didn’t notice a thing, so I had written a good interface. TDD helped me develop a good, testable interface that was simple to maintain. Testers used my automated unit tests as another form of documentation for the API. Users would frequently skip my wordy prose (the published API documentation), and just look at the tests in the unit test folder as examples to figure out how to use the interface.
I also learned that trying to implement TDD within legacy code is a daunting task. Working with a new project that was done with TDD from the beginning was much easier than trying to deal with a legacy project. I learned firsthand about the fear TDD developers express when writing tests without automated unit tests as a safety net. I had a new appreciation for those who try to introduce TDD into established software code-bases.
Lessons from my pair-testing sessions with a developer were reinforced by this process. I was reminded not to get too caught up in thoughtlessly generating tests, but to keep the design in the forefront of my mind. I was reminded once again that it’s easy to get too caught up in the automated unit tests and develop a false sense of security. Using other test techniques with real data in a real system was important; it complemented the automated unit tests on which I was relying. I now had a sense for what TDD developers go through and how they think when developing software. I had firsthand TDD experience that, while very simple and basic, was a great learning experience for me. I had a better understanding of the struggles and pitfalls that programmers face, and of how to develop software in a different way. I could relate to TDD developers more easily after doing it on my own, and I had a wealth of new testing ideas to apply in other areas of my work.
Armed with understanding and fresh ideas about testing, I was ready to reflect on my experience. I was feeling confident about the practice, but I needed to think of what could go wrong to balance my enthusiasm. Continue to part 3 of this series to read my thoughts and conclusions about TDD and testing.