Is it valid to have specflow features depending on other features?

Question

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 because the first test will leave the data in a valid state to perform the next test

Can I do this in Specflow?

Huambo

Answer 1

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 @ignored, 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

Leningrad

I have run into a problem which I describe ~#25113266 – Huambo

Answer 2

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 Givens. 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 Givens cannot fail.

However when we come to compose a Given from Whens 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.

Solecism

surely if thousands of tests are failing looking at just a few of them will lead back to the original failure? – Huambo

@AISki makes a fair point that composing steps from other steps is a way of reducing the number of Givens in a scenario, by combining multiple smaller steps into a single step. We are testing transactions that rely on previous standalone transactions. A concrete example is getting a quote for insurance, which is a stand alone transaction, then buying an insurance policy which requires that you have first got a quote. A test for buying insurance calls the test for getting a quote in the Given step and we @ignore the test which just gets a quote, even thought we wrote the quote test first – Leningrad