2024 Public Training Schedule
December 9 – 12, 2024 – Agile Analysis and Design Patterns – Half-Day Sessions
2025 Public Training Schedule
January 14 – 17, 2025 – Agile Analysis and Design Patterns – Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- January 10, 2018
- Write the Test First
Developers love writing code. It’s what we’re good at. It’s what we do.
But all sorts of things get in our way: Meetings. Reading and interpreting specifications. And the worst time-sink of all—debugging. Most of us would rather do anything other than debugging, but that’s where we end up spending a lot of our time.
Doing test-first development isn’t debugging, it’s writing code.
It replaces the need for extensive internal documentation because it exercises the system the way it will be used. It concretizes abstract requirements by forcing developers to create examples for the behavior they want to build through the act of writing tests.
This is equivalent to creating a rough sketch of what you want to build before you build it. Test-first development helps keep you on track and lets you know when you’re done building a feature. And knowing when to stop building a feature is important. We tend to overbuild not because we like overbuilding, but because we’re scared that that feature might be used in the field in ways we hadn’t anticipated, so we tend to overbuild to compensate.
Having a test that embodies the service we want to create, how we want to call it, and what we expect back, is equivalent to aiming a rifle before you fire it. Knowing your criteria for completion before you start is a good habit to get into.
All this is embodied in the unit test we write before we write the production code. Tests are the concretization of abstract requirements so they’re easier to understand and work with. Writing the test first isn’t busy work, it helps us nail down the behaviors we want to create and think about them apart from their implementation. This is central to properly encapsulating a system so it’s modular, verifiable, and extensible.
Writing the test first forces us to think of the services we write from our caller’s perspective. This also helps simplify the system. When we write the test first it guarantees that the code we write to make that test pass will be testable. It must be, by definition, so this means we’re always writing testable code.
Too often I see developers write their code first only to find that trying to write a unit test for the existing code is so hard they usually have to rewrite the code to make it more testable. If you write the test first then you never have this problem.
Doing TDD is writing code: test code and production code. We spend less time on written requirements and debugging and more time on what we love doing most: writing code.
Previous Post: « Don’t Be Scared to Touch Legacy Code
Next Post: Changeable Code »