2024 Public Training Schedule
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
- November 13, 2019
- Write the Test First
One of my favorite books on acceptance test-driven development is by Gojko Adzic called Specification by Example. This book talks about how you can specify the features of a system through examples cleanly and clearly so that they are straightforward to work through.
Examples allow us to quickly flesh out details and drive out inconsistencies in our thinking so that we can all get on the same page.
The problem with features specifications or system requirements or use cases is that they talk about system capabilities in the abstract, which makes it fairly hard for us to comprehend. It leaves room for ambiguity and very often when we talk about features in the abstract, everyone gets a different impression on exactly what the feature is.
Conversely, when we work through an example of a feature and how it should operate, even if we’re not clear on the user interface yet, we can immediately get on the same page in terms of what the future should do and why. When we do this it greatly reduces the number of errors and inconsistencies in a system.
Working through examples is really at the heart of both acceptance test-driven development and test-driven development or test-first development, as I like to call it. In all cases, we are asserting a particular behavior in a system before we create that behavior and then we implement that behavior by making our assertions pass. This makes software development kind of like a dialogue between the programmer in the system where we’re constantly asserting a new behavior and then teaching the system how to implement that behavior. It’s a fun way to develop.
I’m a huge advocate of test-first development and I find that many of the things that I like most about doing TDD, I also find when I do ATDD or acceptance test-driven development. I find that I can more quickly and easily flesh out error conditions and inconsistencies in a feature description by working through an example quickly with my Product Owner and thus get my questions answered while they are available rather than waiting until I’m knee-deep in development and they’re off doing something else.
Working through just a few examples with my Product Owner oftentimes gives me enough clarity to let me dive right into development and build out the feature that they want. It gives us all clarity on exactly what they want so they’re getting more of what their users need.
I highly recommend Gojko’s book. It’s well written and full of great information. You don’t need to do acceptance test-driven development formally with a framework to be able to benefit from the ideas in his book. Just thinking through examples gives us a great deal of insight into a system that we are about to build and that clarity translates into better features that built more rapidly.
Note: This blog post is based on a section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software called Seven Strategies for Seven Strategies for Measuring Software Development.
Previous Post: « Specify Edge Cases
Next Post: Split Behaviors on Acceptance Criteria »