Cucumber and SpecFlow are collaboration tools

Cucumber and SpecFlow are collaboration tools and not testing tools.

From "The Cucumber Book" “Cucumber might just seem like a testing tool, but at its heart it’s really a collaboration tool.”

With cucumber/specflow scenarios we are collaborating more because the story is told in a way that's accessible to all participants (Developers, Testers, Domain Experts and Product Owners). It also helps us to define a ubiquitous language for a requirement from a end user perspective.

The Given-When-Then scenarios becomes an executable documentation accessible to non-technical stakeholders as a means of seeing what the system can and can not do.

The tests system and regression tests tell the how we do it part of the story. In short the cucumber/specflow executable documentation will explain what the system can and can not do and the Tests that the testers will run will detail on how it is implemented.

ie the cucumber will explain the business requirement that is fulfiled and the testers test will be a script on how it is implemented in the system. Both are complementary to each other but are really seperate things.

Step definitions/Fixtures are the developers interpretation of the story. So they are not specifications nor tests rather a glue to the specification and tests and the reason they would change could be the story of the underlying tests changed due to one of the reasons below

1. The product owner changed the given when then scenario on what the system can do

2. Developers changed the way the interpreted the specification due to refactoring or reorganising of code.

Or in short the domain evolved and so the domain language evolved and new concepts were added and existing ones were better understood or changed.

The step definitions will be the developers telling the product owners that we thought this is what you meant. With a clean code base in addition to a consistent levels of abstraction and good naming developers and product owners can look at this and get a better understanding of what is being built.

Instead of relying on just scripted documentation from the testers and just Test driven tests from the developers the true value relatively comes from relating requirements to implementation in a way which is accessible to business stakeholders and encourages converstation and is executable at the same time.

* Given-When-Then (What)

* Step definitions ("...Thought you meant...")

* Tests (How)

Caution on testers using cucumber/specflow for writing tests

It is tempting for the testers to use specflow for writing scripted tests for the following reasons

1.Its easy to add new tests using existing step definitions

2.Can easily change the parameters to test edge cases which means opportunity to add many data scenarios

The problem we could get into in that approach is we may end up in

-too much details

-we may miss the big picture

-they will be a lot of repititions and we may end up in a lot of scenarios

scenarios in cucumber should be focused on the business user. The language should be kept very informal. It is encouraged to keep their words as much as possible. Business users will not be talking in terms of clicking a button or a popup etc. The code underneath will do whatever is necessary to make the business scenarios work.

If something is a given do whatever is necessary to make it work. ie setting up the data or mocking/hacking a model etc

The when is the event that causes the behavior you're interested in. You should do this from the highest level you can. This is the core of your scenario, so you shouldn't be hacking data in here.

Do not put UI concerns into feature files. Surfacing UI concerns on a feature can make it brittle to legitimate design changes, and also rather boring to read.

Be deliberate in your use of domain language

When writing your scenarios keep in mind that you are writing them for two audiences: the person the feature is for and the person implementing it. Check the wording to see if you can spot anything from neither the problem nor the solution domains. If you find you are using language from outside those domains, you might be over-specifying the implementation or specifying unnecessarily broad requirements that mix concerns.

If you really care about how the behaviour is implemented, you should probably be specifying that elsewhere in a more fine-grained story – in other words chunking down to provide more detail – that won’t be interesting to the audience of this one. If not, you might want to push the detail down into the implementation of the steps.

The most important thing about BDD/ATDD is to talk to people. Please try to do that and not let the tools prevent you from doing it.