Allow Background per feature, not just scenario

[jacek99]

We have some Background setups that are quite expensive in terms of time.

It is very slow to re-run them at the beginning of every scenario.

It would be great if there was a way to define Background, but at a Feature level, not a Scenario level.

e.g.

Feature Background:
...run this only once...

Background:
...run this before every scenario....

[ghost]

To be honest I'd rather stick to what cucumber is doing to avoid forking freshen too much (which allows us to re-use their knowledge and documentation). Have you tried discussing this with the cucumber community? I think it's quite possible they've discussed this already. I'd be interested in the outcome, too...

[jacek99]

Well, I would disagree :-)
We can do better than Cucumber if it is missing some real-life features. We are using Freshen for hard-core testing of enterprise Java server-side apps with large complex Background setups involving sometimes 20 DB entities...redoing this setup on every Scenario significantly increases test run time. I don't think Freshen should be limited just because Cucumber does something...it already offers multiline string support (which is amazing), something that I am not sure Cucumber offers.

[ghost]

The link to the ruby forum posted to #22 lays out cucumber's rationale for not supporting feature-specific fixtures so far.

[jacek99]

Sure, but it looks ugly. In Junit you have @BeforeClass, @before, @afterclass, @after and it works just great. I don't see what the big hoopla is. Somtimes I need to things before/after every scenario, sometimes before/after the entire feature.
Having two totally different ways of doing something very similar does not seem either clean or logical.

[ghost]

I agree that an (end user visible) feature background is not the same as a @Before/AfterFeature hook and I also see your point about advantages in consistency of hooks/feature background over cucumber's approach. jacek99, can you provide a patch for the feature background (this bug) and @Before/AfterFeature hook (#22) functionality for discussion and comment? I still think it would also be great to hear from the cucumber folks about this... Maybe we're just overlooking something? They're not fools, right?

[jacek99]

Hm, unfortunately I am not that familiar with the Freshen code (or nose). We're mostly a Java shop but have dropped all of our JUnit testing to use BDD with Freshen instead. The extend of my Python knowledge is the steps I defined in steps.py...probably not the ideal candidate for submitting patches (at least not yet).

[ghost]

Ok, let's wait for Ramon to take a stand wrt either #19 or #22. I might implement this if it's becoming useful for me, too.

[rlisagor]

I can definitely see the rationale behind Cucumber's reluctance to implement Feature-level hooks or backgrounds. Generally the idea is that tests are completely independent from each other. Having the ability to do some work before or after an entire set of tests can potentially break this independence.

That's the idealistic view. However, in real life, we run into situations like the one you describe above - re-doing setup on each scenario is too slow, etc. In addition, preventing users from doing this doesn't actually solve the problem because things can still become broken as a side effect of ANY step or the "World" code in Cucumber. In only very slightly encourages the user to do "the right thing".

I think we should implement this and #22, but perhaps warn users about these dangers - for example, by making the feature opt-in. Users would then have to be very careful to watch for the side effects of their actions in the feature backgrounds or @beforefeature/@afterfeature (just as they should already be doing in every other piece of test code they write).

I don't really see a big problem with deviating from Cucumber a bit, as long as it doesn't preclude us from implementing other Cucumber features in the future.

Comments / retorts welcome.

[jacek99]

Here's a good example from real-life: in 3 months between the Dev and QA department we have created 700+ BDD scenarios for a single app (!). In many of these features we have to start up mocks of external systems we talk to, written either in Flask (if REST only) or ZSI (if SOAP). There is an overhead to starting up each of these mocks, sometimes significant...for example with Flask we have to wait 1 second in order to ensure it is ready to accept HTTP requests. We have to do this on every scenario instead of just getting that hit once per feature file...which may have dozens of scenarios in it.

That's real life BDD :-)

[fromhtoz]

I agree that this is a valid (and needed feature). I have a script that has to restart services after every scenario, and it really just needs to be done at the end of the feature since my Given hook is handling setting up the Scenario.
This is adding several minutes to the run time.

[jacek99]

Hi, are there any updates on this? This is killing us in production right now...we have 7,000 BDDs in Freshen and the build is taking 2.5 hours to run...much of that spent in the endless Background sections which could have been easily reusable across the entire .feature file.

Please help with a new release, if possible....

[sureshPalla230393]

Hey @jacek99 why don't you tweak your setup code logic in a such way that if the setup is already there it won't run again.