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 12, 2022
- Say What, Why, and for Whom Before How
Continuing my series of posts based on Seven Strategies for Writing Better Stories from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, here is the next strategy.
Although stories are composed of three elements that include WHAT the feature is, WHO the feature is for, and WHY the feature is wanted, I always think about a fourth element to a story and that is the edge cases. Edge cases represent the boundary conditions of a story. This includes exceptions and error handling as well as alternate and secondary paths of execution.
Often, I’ll jot these edge cases down on the back of a story card as I think of them. They sometimes end up as unit tests that I used to drive the creation of exception handlers.
If I’m using an exception testing framework such as FIT or Cucumber or SpecFlow then these edge cases can be expressed as acceptance tests that I can use to drive the development of the feature. Edge cases include boundary conditions for all parameters, starting with an object’s constructor.
Objects should be instantiated in a stable, ready-to-use state that often involves passing dependencies into an object’s constructor or initialization method. Constructors should be short and simple. They should accept and validate their parameters and if one of the parameters that they depend on is invalid they should throw an exception in languages like Java or C# or C++.
When we’re writing unit tests for exceptions, we have to test two things. First, we have to test that the exception is thrown when it’s supposed to be thrown and this drives us to create the exception handler. Next, we have to test that the exception is not thrown when it’s not supposed to be thrown.
Edge cases help us drive the creation of exceptions and error handling and help make our systems more robust. Edge cases often hold core business rules that need to be expressed in the system and so they’re valuable to document.
But we can go overboard in specifying edge cases and so we want to only really focus on major edge cases in stories. We’re not trying to ferret out all the error conditions or do quality assurance at this point.
We’re simply trying to cover the major cases so that we can come up with a clear high-level definition of the behavior in the system. “The devil is in the details,” as they say. Very often the details are in the edge cases. Capturing them can help us define significant aspects of our systems.
Previous Post: « Start Simple then Enhance
Next Post: Use Acceptance Criteria for Stories »