“As part of our modernization efforts, we are going to become an agile organization,” says the new CTO to his teams. A pronouncement like this is likely to spark several reactions that can vary from excitement and curiosity to confusion, skepticism, and fear. This is story we’ve all heard before. To narrow the frame a bit, I’ll talk about software developers, one of the groups affected in a radical way by the switch to agile, and the initial change they’ll face: unit tests.
Common developer responses to the “test first” approach:
- “How can I test code that doesn’t exist?
- “Why should I write code that I know will fail to test code that doesn’t exist yet?”
- “I’m a developer, not a tester. I’m not writing unit tests.”
Test Driven Development and Behavior Driven Development both require a change in mindset for software developers. It can be a hard sell, because not all the benefits of writing unit tests can be reaped right away. In the short term, the “test first” method benefits the team by acting as a blueprint and limitation for the code that will be written (no more code is written once the test passes). Getting developers to understand the long-term benefits is more challenging.
One of the longer-term benefits is the suite of unit tests. A single unit test will validate one small portion of the code base. These unit tests can be run manually at any time or as part of an automated build process. If a single unit test fails, the developers know exactly where the issue has occurred and troubleshooting becomes easier. It can also help prevent developers from inadvertently breaking another part of the application unexpectedly. Before committing the code, unit tests for an entire program should be run to ensure any new or modified functionality doesn’t break existing behavior. Similarly, when code needs to be refactored, unit tests act as a safeguard from breaking the current functionality.
Getting teams to embrace and become proficient at agile, iterative approaches takes time. Learning a different technique to write code might slow the team down initially, but increases their velocity in the long run. Beginning with a unit test may take more time, but it makes everyone’s lives easier later on. For my part, I’ll gladly work harder today to save time tomorrow – and that’s what unit testing does for agile teams.