How Can I accept it? – Starting with ATDD

This is the fifth post in the first Build-Measure-Learn cycle. In the last post I detailed the user story “Import a file with a single paragraph” This leaded me to the formulation of two acceptance criteria. Based on the acceptance criterion for a system functionality I will start with Agile Acceptance Testing. Agile Acceptance Testing revolves around five principles. They will guide me by defining the test statements for the automated acceptance tests.

A Shared Understanding

The primary role of acceptance tests is to facilitate knowledge transfer and help us build a shared understanding of the system under development. In a secondary role they also help with quality assurance (see [Adzic2009]). Some of my readers may out point now, that there is no team and therefore the primary role of acceptance tests will not be appropriate. They are right. Nevertheless, I will try to build a deep understanding of my problem domain.

The Principles of Agile Acceptance Testing

According to Gojko Adzic the Agile Acceptance Testing revolves around these principles (see [Adzic2009]):

  1. Use real world examples to build a shared understanding.
  2. Select a set of examples to be a specification and an acceptance test suite.
  3. Automate the verification of the acceptance tests.
  4. Focus development effort on the acceptance tests.
  5. Use the acceptance tests for future change requests, start the next cycle.

Examples are the important notion here. Therefore, I need to define an example, which will be used for the automated acceptance tests. As I am still going with persona Anton I am focusing on the topic NOSQL.

I copied my example text passage from the Wikipedia page for NoSQL (see [NoSQLWiki]):

“The central concept of a document store is the notion of a “document”. While each document-oriented database implementation differs on the details of this definition, in general, they all assume that documents encapsulate and encode data (or information) in some standard formats or encodings. Encodings in use include XML, YAML, and JSON as well as binary forms like BSON. Documents are addressed in the database via a unique key that represents that document. One of the other defining characteristics of a document-oriented database is that in addition to the key lookup performed by a key-value store, the database offers an API or query language that retrieves documents based on their contents”

In addition, I can define my acceptance tests based on the example text passage. In the last blog post, I defined two acceptance criteria, one for the UI and one for a system functionality. If a project strives for automated acceptance test, it always has to answer the question of whether to automate acceptance tests for the UI with a BDD test framework or not. Actually, for me to automate UI acceptance tests with a BDD framework is not an option. Last year I had some painful experiences with these kind of tests. They were fragile and very costly. But I will try to implement them as some kind of unit tests. Therefore, I will focus my efforts on automating the acceptance tests for the system functionality.

Formulating Acceptance Tests

My acceptance test criterion for the system functionality looks like this:

Given the user has selected a text file
When they start the import of the selected file
Then the file will be imported and the text is in the system available

In order to write automated tests for this functionality, I have to describe the test cases with test statements. I am going with the textual format proposed 2007 by Dan North (see [BDDWiki]). this is my draft on the test statements:

Scenario 1: a single text passage in a text file
Given a text file which contains a single text passage
When the user starts the import on the given file
Then the file will be imported and the text is in the system available

Scenario 2: an empty text file
Given a text file which has no content
When the user starts the import on the given file
Then the file will not be imported and the user will be notified

Scenario 3: an unreadable file
Given a text file which is not readable by the application
When the user starts the import on the given file
Then the file will not be imported and the system will display an error

Scenario 4: the file is not a text file
Given a file which is not a text file
When the user starts the import on the given file
Then the file will not be imported and the system will display an error

To be frank I am not sure if this is the right approach. Is it good to define a scenario for every file format which the system should support? Is it ok to be abstract in the Then-clause of the scenarios, like “the text is in the system available”?
I like to know your opinions, please send me some feedback on this post.

What’s next?

In the next blog post I will start some initial design considerations for the implementation of the system functionality and the automated test.

Resources

[Adzic2009] Gojko Adzic, Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing
(1st edn, Neuri Limited 2009)

[NoSQLWiki] Wikipedia, ‘NoSQL’, <https://en.wikipedia.org/wiki/NoSQL> accessed August 29th, 2016.

[BDDWiki] Wikipedia, ‘Behavior-driven development’, <https://en.wikipedia.org/wiki/Behavior-driven_development> accessed August 29th, 2016.

Leave a Reply