At VMware Pivotal Labs, we practice test-driven development (TDD). That means before we begin work on a new feature, we first write a test that describes the behavior we want to add to our software. Once we’ve written a test and seen that it fails in the way we expect, we make just enough changes to the code to give our software the behavior we described. When the test passes, we look for opportunities to refactor what we’ve written. We try to make the code easier to read and change, executing the test after every revision to ensure our software still has all the behavior we expect.
We find test-driven development to be the most effective way to build quality software, in part because it results in a test suite that serves as a comprehensive, executable description of the software’s expected behavior. Programmers who practice TDD can change their software with confidence—to add new features, update technologies, or reduce complexity—knowing that the test suite will quickly identify any regressions.
But you already write tests and appreciate the value they provide. You just think it’s better to write them last.
No problem; at least you’re writing tests. But if you’re writing tests after you’ve already implemented a feature, you’re slowing yourself down. Here are three reasons why you’ll build software faster when you write tests first.
Write tests first to build the right thing
When you write tests first, you’re forced to think through the requirements of a feature before you begin implementing it. More often than not, this will lead to questions and further discussions with your team and your stakeholders to clarify the feature’s intent before you’ve written any code. That’s a good thing. Without taking the time to think through the details of a feature with the precision that’s necessary to write a test, it’s easy to proceed with the implementation based on faulty assumptions, which can lead you to build the wrong thing. Writing a test first forces you to make your assumptions explicit, before you commit to one implementation or another. And that means you’ll be in a better position to build the right thing more quickly.
Write tests first to know when you’re done
We all know tests are great at providing feedback on changes to the code. If you mistakenly introduce a regression, then a test should fail. But when you write a test before implementing a feature, you’ll get two other forms of feedback. First, the failures you observe before you finish development will guide you toward the next change to make, and when those changes result in a different failure, you’ll know you’re making progress. Second, once the test passes, it means your software now has all the behavior you expect. Without this feedback, it’s easy to continue writing code until you find yourself going beyond the original requirements, implementing other related features that might seem just as important. By writing a test first, you’ll get feedback that keeps you moving forward and lets you know when you’re done, so you can deliver valuable software, faster.
Write tests first to end up with tests you can trust
When you write tests after you’ve finished implementing a feature, you can expect that your tests will pass; after all, you’ve just written all the code. But can you trust that your test is exercising that code in the way you expect? How do you know if it covers all the relevant cases?
When you start with a failing test, you have to change the code to cause it to pass, so you know immediately that the test covers the behavior you just implemented. If, however, you write a test last, then you won’t have the same feedback. To trust that test, you’ll need to manually verify it, finding and intentionally breaking the code that should be exercised by the test in order to ensure that the test fails in the way you expect. By writing tests first, you’ll avoid all that work and quickly end up with tests you can trust. And when you trust your tests, you have the confidence to change the code in ways that reduce its complexity over time, so you can deliver new features as fast as ever.
Interested in learning more about test-driven development? Consider building your next product with Pivotal Labs. We’ll work side-by-side to teach you practices and strategies—like test-driven development—that will help your team go fast forever.
Image courtesy of Fatos Bytyqi via Unsplash.
