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:
a) 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?
b) 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.
Source link https://sqa.stackexchange.com/questions/34939/organisation-of-acceptance-testsspecflow-cucumber