Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Controversy
Test-driven development is often misunderstood. To be honest, it wasn’t until I spent some time learning basics with a developer, and then actually practiced it myself, that I felt I had a basic grasp of TDD. Seasoned TDD programmers will read my story and find obvious gaps, naïveté, and assumptions, and those who practice the craft have a lot of good ideas on how to do TDD well (and much better than I described). However, since test-driven development contains the word test, other stakeholders, particularly QA or testing departments, feel that they should somehow "own" these tests and this process. In some cases, development managers have asked me or the testing team to take responsibility for the unit tests, and to ensure that they’re developed properly. There are a couple of problems with this approach:
- In order to speak to the code that the developers are writing, we need to have testers who have a strong architecture, design, and programming background, particularly in TDD. Generally the people with this kind of skill are senior developers or architects.
- TDD developers often favor collective code ownership, and this practice extends to tests. We should also strive for "collective test ownership," in which everyone has a stake in using the tests instead of causing division by claiming tests as turf, which can cause team dynamics to break down.
Another source of confusion is the activity of test-driven development. A lot of it is serious program design. Some people use this point to counter "quality police" trying to be gatekeepers of TDD. Since TDD is about design, why try to have testers police it? Many developers say that TDD isn’t about testing at all—it’s a design technique.
Cem Kaner, Brian Marick, and others have pointed out that TDD is a lot like development using "examples." Maybe "example-driven development" would be a more accurate term. We write an example in the form of a test, and write the code to fit the example.
Still other developers argue that TDD is about testing: "Sure, it’s about design, but that design is driven out by the tests!"
My view is that TDD is about both design and testing, and while it’s more about design than testing, testing is still part of it. Some TDD practitioners have told me they feel that TDD is often at least 80% design, 20% testing, so I’m not alone in my views. However, TDD testing may look much different from what conventional software testers are used to. I certainly had some challenges starting out, and I consider myself to have basic programming skills. Modeling TDD using William Wake’s "generative test" and "elaborative test" phases of TDD helps me to understand it as both design and testing.
Cem Kaner has identified TDD as another school of thought in software testing, and I tend to agree. We can learn a lot from TDD practitioners, and there’s an enormous community of practice from which we can learn. While TDD is a different school of thought, it still requires programming skill to master. Many testers see TDD as programming at first, and it takes them a while to think of testing in the code context in a way that they can relate to. The TDD community of practice is often geared toward object-oriented programming and design patterns. Testers who want to do more TDD will need to gain a strong understanding of design as well as programming.
QA testers are often intimidated by programmer testing: "If the developers are testing now, what will we do?" However, TDD involves testing in only one context—the source code context. There’s still a lot of room for testing in other contexts. I’ve also found that working with the developers provides a great experience for test idea generation, helping make the code more testable, and gets more people involved in testing the application.