I want to write an acceptance test along the lines of
given the first test has run
when I do this new test
then this new test passes
This is be
yes you can do this in specflow, but with a slight caveat. this approach will not run one scenario, then run the other, it will run the first scenario on its own, then the dependent scenario will run the first scenario again followed by the second scenario. The order of these may not be deterministic. We have avoided this issue by @ignore
the first scenario once the dependent scenario is written. As the second scenario always runs the first scenario anyway it doesn't matter that its @ignore
d, as any failure in the first scenario will trigger a failure in the second scenario.
What we have done to achieve this is along these lines:
Scenario: Some base scenario
Given some condition
When some action
Then some result
then later in another feature:
Scenario: Some dependant scenario
Given some base scenario has happened
And some other condition
When some other action
Then some other result
The key is in the definition of the step Given some base scenario has happened
if you define this step like this:
[Given("some base scenario has happened")]
public void SomeBaseScenarioHasHappened()
{
Given("some condition");
When("some action");
Then("some result");
}
you need to ensure that your class which holds your step definitions derives from the base Steps
class in specflow to get access to the Given
, When
and Then
methods:
[Binding]
public class MyStepClass: Steps
you can find more information on this on the specflow wiki
As Sam says, you can do this with SpecFlow, however I would question whether this is a good thing for your tests.
If you look at Sam's link to the specflow wiki you can see that their example composes a Given
from multiple Given
s. This makes sense to me, as the Given
is getting the test into a very specific state so that assertions can be running against it. It also has no side effects, as in theory Given
s cannot fail.
However when we come to compose a Given
from When
s this introduces the possibility of the test being in the wrong state before we can then assert that everything is correct. I will admit, that if you are simply composing a Given
with the steps of another Scenario
this is mitigated as the original Scenario
will fail and you can therefore resolve that first, but you still have to find that failing test. Imagine that you build your tests up over several years and end up with several thousand composed in this manner. One simple breaking change to the base scenario and thousands of tests fail, making it much harder to find where the real problem is.