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
- July 14, 2021 ( 2 comments )
- Specify Behaviors with Tests
In practice I found that there are times that I want a bit more test coverage than I get from just doing test-first development. When I do test-first development, I always write a failing test first and then I create the implementation to make that failing test pass. As a result, I get by default 100% test coverage for my code. But that still may not be enough. There are edge cases and boundary conditions that may also make sense to have tests for.
So, I think of my tests at three levels. At the highest level are acceptance tests. These tests certify that features are working as expected. The next level is the unit tests I write to drive the creation of my code while doing test-first development. Amir Kolsky calls these kind of test “green tests,” and they’re almost always written in a unit testing framework like JUnit for JAVA or NUnit for .Net.
Green tests are the tests we use to drive the development of our code. They are the result of doing test-first development. Green tests should never break when you refactor code because green tests test behavior; they do not test implementations of behaviors.
Finally, there may be additional tests needed to assure that features behave as they’re supposed to. This can include functional and non-functional tests. I prefer to do much of this kind of testing in a unit testing framework rather than a more traditional testing framework. This allows me to test at the code level. The tests you write after you write the code are what Amir Kolsky calls “red tests.”
Red tests, unlike green tests, may be implementation dependent. They are written after the code is written, during a review process that basically asks: “What else could go wrong?” We don’t ask that question when we’re writing the code initially because we’re in a different mindset. We’re in the mindset of what could go right so we’re laying out what we call the happy path and perhaps picking off a few exceptions along the way.
But just like in creative writing, where we don’t want to try to edit ourselves while we’re in the process of writing, when we’re doing test-first development we don’t have our “QA hats” on. We’re not thinking about what could go wrong. That’s the second stage—the editing process. It happens later. If you try to do both writing and editing at the same time, you often end up with writer’s block. The same thing is true in software development. That’s why I start by writing green tests to build out the behaviors I want to create and then later I go back and write red tests to address any areas I feel I need additional coverage.
{2 Comments }
Previous Post: « Radiators and Silos
Next Post: See Stories as Placeholders »
Great post! I am wondering if there is any other way to tell the difference between acceptance tests and green tests. I feel all the acceptance tests could be seen as green tests.
Yes, I agree. All acceptance tests should be based on acceptance criteria and not on implementation details so all acceptance tests should be green tests.