I recently found myself being asked to write TDD Cucumber tests.

I thought about this for a minute, and came to the conclusion that it was possible, but only to a point.  Why only to a point?

Well, ideally Cucumber / Gherkin is used to describe your business logic.

So in this case,

Given I am in this state
When I perform this activity 
Then the outcome is <blah>.

This clearly states where you were, what you did, and where you went.  Everyone can read this – business analysts, developers, manual and automated testers.

In each of these given / when / then steps, I could implement the UI test at a later stage, once I knew how the app provided the functionality.

What I couldn’t do was describe the actual implementation of the app in advance.  Otherwise I would be in danger of constraining the developers.  i.e. what I wanted to avoid was a test that looked like

Given I am in this state
When I click on this button
And type <blah> in a field
And type <blah> in another field
And select <blah> from a dropdown
And click on the <save> button
And click on the <confirm> button
Etc.
 

You get the idea – where is the business logic in this?

Don’t get me wrong, if you’re aiming for a super-high-level of detail in your test, this could be done, but it’s a pain to write, read and maintain.  And… no easily readable business logic.

It is far better (in my opinion) to keep Cucumber / Gherkin tests as simple as possible.

For example

Given I have created a record
When I authorise it
Then the record is made available for public viewing 

Within each of the steps – now you can start saying “click this, select that, click the other…”.  But Cucumber / Gherkin should be kept for business logic.  This can be used for Behaviour Driven Development (BDD).

There is an excellent book about this on Amazon (Specification By Example, by Gojko Adzic):

https://www.amazon.co.uk/gp/product/1617290084

Test Driven Development seems to be better with very atomic functionality - e.g. for calculating tax. In this case, there is no query about how the feature works.

Given a sale of £100 my tax in UK should be £20.
Given a sale of £100 my tax in Switzerland should be £0.
Given a sale of £100 my tax in Germany should be £15.

Alternatively, you could write that as

Given I make a sale of "saleAmount" in "country"
When I calculate the tax
Then the tax for the country is calculated at "taxRate" to give a tax amount of "expectedTax"
Examples
|country     |saleAmount |taxRate |expectedTax |
|UK          |100        |20%     |20          |
|Switzerland |200        |0%      |0           |
|Germany     |300        |15%     |45          | 

etc.

This is more suited to API testing - expected inputs => expected outputs.

So how would I approach this in Jira?

One approach that I have found works well is:

• Create a parent task for Feature X.
• Create a subtask for each Acceptance Criteria for Feature X.
• Once each subtask has been manually tested (successfully), mark it as ready for automation testing.
• Once the subtask has been automated, attach the implemented version of the business logic (the implemented cucumber / gherkin steps) and proof of it running.

This will give instant visibility of the acceptance criteria for each Feature, providing good monitoring of progress.

Conclusion

Test Driven Development is good at low-level, for prescriptive definition of clearly defined functionality.  More suited to developers, or testers who are close to the code.  Easy to write these tests in advance of the code being written.

Behaviour Driven Development is good for describing business logic at a high level, before the fine details of how have been decided.  Easy to write the acceptance criteria for functionality in advance, but difficult to write the full implementation (linking them to the feature under test) until the feature has been defined and implemented.

Don't mix the two up, or you could be making a huge rod for your own back.