2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – 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
- April 14, 2010
- Specify Behaviors with Tests
Part of allowing change to happen during development is by building software with engineering practices that support change. The most important of these practices is correctly using unit tests. Tests represent a way to both embody understanding of the system and prove that the system works.
Unit tests are really a form of specifications because by running them and seeing them succeed we know they are up to date. So we really want to use test as a form of documentation that specifies the behavior of a system.
This implies using unit tests in a different way than many people think of them but it is perhaps the most powerful way to think of using tests. It also guides us for creating the right number of tests. If we see tests as documenting the system then we are not tempted to write more tests than are needed to specify the behavior of the system.
I notice that I can learn a system much more quickly when there are tests in place. I invariably look at the tests first and that tells me how the system should behave. I then look at the production code to see how the behavior is implemented.
Previous Post: « Resistance to Change
Next Post: Retrofitting Tests »