Tag Archives: #ATDD

Use Cases and ATDD/BDD Scenarios

Ivar Jacobson And Alistair Cockburn have a great article on “Use Cases are Essential”. You can read it at https://dl.acm.org/doi/pdf/10.1145/3631182. Its summary says, “Use cases provide a proven method to capture and explain the requirements of a system in a concise and easily understood format”. I have incorporated use cases in my ATDD/BDD workshops for many years. In this article, I’ll show one transformation of the use case they used in their paper into the detailed ATDD/BDD scenarios. 

The PDF is here

The HTML version is here.

A Coalesced View of Software Development

You’ve read about agile development, BDD/ATDD, agile architecture, and many of the other facets of agile.   Many articles tend to discuss individual aspects, rather than putting them in a perspective of a whole development picture.  Over the past year and a half, I’ve been coalescing ideas on software development.  This view has emerged from my interactions with students, agile enthusiasts, and agile coaches, trainers, and authors.  I’ve listed at the end many of the people from whom I’ve gathered different perspectives and feedback.  This article merges in ideas that have appeared in my books on BDD/ATDD, software development, programming, and interface-oriented design.  The PDF is here; HTML version is here.

A Flow Perspective

Some agile practice articles discuss how individuals should be organized into teams and work
collaboratively. Other articles describe how product backlog items/features and sprint backlog
items/stories/tasks should be estimated and scheduled. In this article, the flow perspective focuses on how customer or business value is delivered. This flow is sometimes shown with value streams, story maps, customer journeys, workflows, or other means. Understanding and making the flow visible can help with organizing the other views of agility. The article in html is here. The article as a PDF is here.

Requirement Driven Development – Test Driven Development

There is a flow from external requirements to internal tests. Requirement Driven
Development
(RDD) (aka Behavior Driven Development / Acceptance Test Driven
Development / Specification by Example) focuses on the external behavior.  
Test Driven Development focuses on the internal behavior that creates the
external behavior.  There is an overlap between the two.  TDD can go all the
way up to external behavior.  RDD can differentiate into more detailed
behavior.   Go here for html. Go here for PDF.

Use Your Ubiquitous Language in Your Design

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

The Gilded Rose Kata from a Gherkin Perspective

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. 

Layers of Scenarios and a Reply on Randomness

 

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