CODEWITHSUNDEEP
cucumberbdd
berkes
berkes

Reputation: 27563

Write cucmber features just in time or beforehand

The Cucumber Book speaks about writing most features up-front, together with stakeholders and/or other team-members.

However, this means that at any given time before the release/iteration, there will be many failing tests; all the features are already there, yet failing.

The cucumber.yml, that comes with rails, uses the work-in-progress practice using @wip tags as discussed in The Rspec Book. This is where you write a scenario Just In Time, the moment you are going to develop it; not up-front, at once, at the start of a larger iteration or project.

These seem to contradict. Is there any documentation on what best to use? Are there usefull tricks, e.g. using tags, to write features up-front yet exclude them from the test? Or is this considered a bad practice?

Upvotes: 1

Views: 75

Answers (1)

Arti
Arti

Reputation: 26

We usually write features, upfront, with the Product Owner &/or Developers and tag them as @wip when we check them into the branch for the story we're working on. Our stories are small enough that we develop them within days, sometimes hours, so there are rarely features lying around unimplemented. I have worked in the past at places where we wrote the features upfront for large projects and that just didn't work too well - requirements changed and made the cucumber features redundant/out of date.

This isn't a black or white answer - just what's worked and what's not worked for me. Hope this helps.

Upvotes: 1

Related Questions