Organisation of Acceptance Tests(Specflow/Cucumber)


(Andrew) #1

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