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
- October 18, 2017
- Bits and Pieces
Acceptance criteria are simple tests to tell us when we’re finished implementing a feature.
Knowing when we’re done building a feature is extremely important to developers because we’re not always sure how robust a feature should be.
We don’t like it when our code breaks in the field so we want our code to be robust, which often leads us to overbuild in one area, taking time we need to give other areas the attention they deserve. Knowing when we’re done with one feature helps us move on to the next with confidence.
Acceptance criteria should be seen from the perspective of how the user evaluates a feature. It can be jotted down as a conditional statement on the back of a story card, or it can be automated with an acceptance testing tool like FIT, FitNess, SpecFlow, Cucumber, etc. These tools help us create acceptance tests in a form that the computer can execute while still being easy for a non-developer to read.
But there’s another major benefit to coding to acceptance criteria. It keeps code focused on providing something useful to our users and puts acceptance tests at the right level of abstraction.
Creating the right tests for code is paramount. If tests are too fine grain then we’re likely writing implementation-dependent tests. If they’re too broad then we’re likely to miss edge cases and other exceptional conditions.
Good code depends on building it at the right level of abstraction, and the right level of abstraction is often defined in the acceptance criteria itself. When we write our acceptance test around the acceptance criteria of a story and our acceptance test passes, we know our story is finished.
Just like literature, code can tend to ramble when it should be succinct. When code is focused around passing some acceptance criteria then it’s more straightforward and to the point. We spend far less effort building cruft and put far more effort into code that provides value to our users. We also end up with a more assertive system that’s more straightforward to test and extend.
Another important aspect of coding to an acceptance criteria is that it helps us write code that produces an observable result, which means it’s generally more testable and modular. Acceptance criteria speak to the very core of what makes a feature valuable to the user. Keeping acceptance criteria in mind as we’re building a feature helps keep us focused on producing code that provides value.
“How will we know we’re finished?” is the question we should always ask before we begin building a feature. It’s starting with the end in sight. Defining this up front ensures that everyone starts on the same page with what’s being built, and stays there until it is built.
Previous Post: « Use Examples
Next Post: An Object Model »