Organisation of Acceptance Tests(Specflow/Cucumber)

Hi there,

now Im starting to work more and more with BDD techniques(spec flow and Cucumber), I’m starting to think about the organisation of
the projects/solutions I create and ensuring that I future proof it in some way.

For example, Sprint 1 starts and we decide to write our acceptance tests using specflow/c#. As a result we build up a series of feature
files which together encompass all the user stories in Sprint 1 and from that point on they can run in an automated fashion. The questions
I have are:

  1. What happens when sprint 2 starts? Would we just keep adding new feature files and code to the solution we build in Sprint 1, and
    just create new sub-folders so as to separate the features in each sprint? Or is there an alternative way of doing this…potentially,
    we could have sub-folders in the solution for each area of our system and we add to the automation suite that way?

  2. In terms of naming conventions:

  • what is the recommended naming convention for the solution/project, given that over time it could have a huge amount of features
    within it, each looking at different areas of a system?
  • for features, should the name of these corespond with the user story title or id?
  1. What’s a good way of being able to refer back to these acceptance tests, say in 6 months? Obviously, a business user wouldn’t want
    to trawl through Visual Studio projects, so could these acceptance tests be exportable to a html webpage?

Appreciate any advice people may have.

Kind regards

1 Like


Sorry quite late in on this but thought I would comment as nobody else has. I hope you’ve managed to pick a strategy going forward that seems to be working for you.

Feature files shouldn’t be named after a sprint or story but should be named according to the feature it is delivering. For example imagine we had features to look for addresses. You may have a feature file for postcode only search, a feature file for postcode and house number etc so I’d propose to split it up that way.

Above scenarios or at the top of the feature file you can @yourstorynumber or @yoursprintnumber to identify what links to what story/sprint.

When you run the tests you can specify one of the above tags and get it to generate a html report for you also, have a look at the specflow documentation for outputting a report.

Hope that helps though I appreciate it may be a bit late.


For anyone else following this topic, I second the above however we name our stories by TestRail test cases. This means we have a really easy way to track things between the project and an intuitive testing software.

I think automation is a bit of a free-for-all. Yes there are frameworks but ultimately it’s about what suits your team the most.