Multiple asserts single detailed response

gistfile1.txt

That's not really a pattern and more a tooling thing.

Sometimes scenarios have behaviour that has multiple aspects, which individually are worthless but together have worth.

So contrived scenario ahead

Given a Spline
When it's Retriculated
Then it beeps
And it flashes

For a business user this is a good scenario since "working" means both beeping and flashing.
However from the dev point of view this is irritating since test runner will stop at the first failure, which makes it harder to identify if the behaviour was broken at the Spline code, the sound code or at the light code.

So in an ideal world a test runner would be able to show:

Given a Spline
When it's Retriculated
Then it beeps   <-- Failed!
And it flashes  <-- Passed!

Pseudo code but you'll get the idea, I was more thinking:

void FixtureSetup(){
result = target.Execute();
}

[Test]
void test1(){
Assert.That(result.one, Is.EqualTo("one");
}

[Test]
void test2() {
Assert.That(result.two, Is.EqualTo("two")
}

A possible enhancement to xbehave is the ability to specify that the failure of a certain step does not prevent execution of subsequent steps

E.g.

"Given a Spline"
    .f(() => ...);

"When it's Retriculated"
    .f(() => ...);

"Then it beeps"
    .f(() => ...)
    .ContinueOnFailure();

"And it flashes"
    .f(() => ...);

In xbehave 1.1, you can fudge this using backgrounds, e.g.

[Background]
public void Background()
{
    "Given a Spline"
        .f(() => ...);

    "When it's Retriculated"
        .f(() => ...);
}

[Scenario]
public void Beeping()
{
    "Then it beeps"
        .f(() => ...);
}

[Scenario]
public void Flashing()
{
    "Then it flashes"
        .f(() => ...);
}

But the test output won't really convey the right semantics.

Breaking news: ContinueOnFailure is coming in 2.0 - https://github.com/xbehave/xbehave.net/wiki/Changes-in-version-2.0

See adamralph/xbehave.net#247