- Learning About TDD
- A Unique Learning Opportunity
- Getting Started
- Early Challenges
- Remember the Design!
- Lessons Learned
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
A Unique Learning Opportunity
For the past couple of years, I had worked as a tester on software development teams that were doing test-driven development. I learned that, in TDD, you write tests while you’re developing code, instead of writing the code first and then testing after the fact. In fact, in TDD, you write a test first, and then write the code to satisfy the test. You only add new code when you have first written a test for it.
As a tester, I would pair with developers from time to time, but I had never spent full days working with them as they developed new software from scratch. I was to spend the next two weeks working full-time on a small project with John, an experienced TDD programmer.
John and I spent some time looking at the problem domain. He thought about possible design challenges, and I thought about possible tests. We worked together talking about areas where we thought we might have the most challenges. As a tester, I had experience with similar software and knew areas where bugs tended to come up over and over. John thought this was interesting, and took note of my experience. He talked to me about testable interfaces, and was bridging testing ideas with architectural design ideas. He wanted me to be completely prepared for when we started working together at the same computer doing test-driven development.
As we worked together sharing ideas during this preparation time, I had a breakthrough when it came to my understanding of testable interfaces. I viewed testing mostly through the user interface, because that was where my experience as an exploratory tester and much of my test automation work had been done. I tended to think of an application in terms of how the end user would see it; in other words, I modeled the application according to the visible, interactive user interface. I had also spent time programming, though, so I was familiar with modeling the application in terms of program code, When I worked with John and we talked about how he viewed the application, I realized that a testable interface is really any sort of doorway into the application that we could use to communicate with the application. The graphical user interface was just one of many potential testable interfaces we could program into the application. These testable interfaces differed in how we communicated with each interface, and with what area of the application.
This concept of many possible testable interfaces was something John wanted me to grasp. He told me that this was a key point to understand with test-driven development. He explained that a testable design is a good design; the two concepts are tightly related.
To prepare, I thought of test designs that might be applicable, brushed up on some testing skills, and gathered any related information we could use in development, such as data dictionaries. I wanted to be sure that I wasn’t holding John up when we were working together, so I prepared in order to be quick on the draw with test idea generation, which I thought was the most important contribution I could make.