When the Triad (Customer, Developer, Tester) have a conversation about a requirement such as a story, domain terms often come up in the conversation. These terms could represent the elements in a requirement, such as a loan amount or an interest rate, or a type applied to the elements, such as Dollar or Percentage. They could also represent actions, such as charge interest.
Eric Evans describes these terms as a Ubiquitous Language. Understanding these terms is crucial to creating a shared understanding of the requirement. But do you just leave the terms in Jira or Sharepoint? If so, then you’re missing an opportunity for creating a good design. Continue reading Use Your Ubiquitous Language in Your Design
In reviewing a book, I was reminded about the Gilded Rose kata. It revolves around some legacy code that has no tests. You need to make some changes to the code to support a new requirement. The kata was created by Bobby Johnson (http://iamnotmyself.com/) and updated by Emily Bache (http://coding-is-like-cooking.info/).
A detailed explanation of the Gherkin approach is in this PDF. An html version is here. The code that the PDF references is at https://github.com/atdd-bdd/GildedRose . There is one function that has not been refactored yet. It’s left as an exercise to the reader.
You can compare this solution to other solutions to the Gilded Rose kata to see alternative ways to approach this problem.
Gojko Adzic asked for opinions in his blog “How to Specify Something Should Be Random. He presented alternative scenarios and asked for your choice.
The situation he described is having a robot’s chat response appear like it comes from a human being. There could be multiple levels of tests associated with this requirement. Let’s take a look at these levels and along the way give my choice(s) for an answer. Continue reading Layers of Scenarios and a Reply on Randomness
“How to organize feature files?” was a question asked by Gojko Adzic in a recent blog. He presented several options and then asked for responses. The options included grouping them by user story, by capability and level of detail. This question has often come up over the past years in the workshops that I teach.
Continue reading Organizing Your Feature Files
A blog question on relative dates by Gojko Adzic triggered a blog post by Seb Rose. The two blog posts showed there are many shades of gherkin. I’d like to use the example in those two posts to demonstrate a couple of facets of scenario decomposition. This uses a slightly different shade than Seb’s.
Continue reading Decompose Scenarios for Simpler Scenarios
A blog on specflow.org talked about ways to document scenarios for a business rule. It reminded me about some aspects of blog wrote a few years ago called Six Shades of Gherkin. Here’s the business rule that was used as the example in specflow.org blog:
A volume discount rule provides 10% off for purchases between 5 and 10 items, 15% for purchases between 10 and 20; and 20% above that.
One of the issues with business rules is making sure they are understood by the entire triad (customer, developer, tester). In this example, what is the discount for 10 items? One way to document is to use a scenario outline that gives the results for each side of each breakpoint. Another important value is documenting the results at the limits and beyond. Continue reading A Few Shades of Gherkin For Business Rules
A common format for scenarios is Given/When/Then. The Gherkin language revolves around the Given/When/Then organization. Scenarios can be written in Gherkin in many variations, each of which has a different shade of meaning. These shades I’ve denoted as outline, values, domain terms, table values, calculation, and chatty.
Continue reading Six Shades of Gherkin
This is a report from a team at a leading financial company:
Continue reading ATDD Lets Team Frequently Release Software
Cucumber is usually considered a customer acceptance test automation tool. However, it can also be used as more of a unit testing tool in place of JUnit or other language-based tools. This can make those tests better and more understandable, with the probably of better maintainable code underneath. Continue reading Using Cucumber for Unit Tests
There is often a question as to whether a test such as a business rule should be made more generic. In this article, we’ll examine ways of making tests more generic.
Continue reading Generifying Acceptance Tests