2

Suppose were testing line segment intersections, and the intersections consider parallel and collinear lines to never intersect. Which one would be more natural to write?

One case has more jammed into it and the scenario title seems broad, but prevents having to write a certain variable multiple times, but at the expense of the scenario test name not being more generic. Is this bad?

Very similar cases under one scenario (this is a C++ unit testing framework, so it's a bit different from say JUnit):

SCENARIO("A vertical line segment does not intersect another vertical line segment") {
    LineSegment segment = ...

    GIVEN("Two vertical line segments that are parallel") {
        LineSegment parallelSegment = ...

        // ... when, then
    }

    GIVEN("Two vertical line segments that are collinear") {
        LineSegment collinearSegment = ...

        // ... when, then
    }
}

or a single scenario for each case, even if it means the same:

SCENARIO("Parallel vertical line segments are classified do not intersect") {
    GIVEN("Two parallel vertical line segments") {
        LineSegment segment = ...
        LineSegment parallelSegment = ...

        // ... when, then
    }
}

SCENARIO("Collinear vertical line segments are classified do not intersect") {
    GIVEN("Two collinear vertical line segments") {
        LineSegment segment = ...
        LineSegment collinearSegment = ...

        // ... when, then
    }
}

Is it better to be as contained as possible with scenarios so that it's easy to read from the scenario name (if the test fails) what went wrong? Or is it okay to do multiple tests for a scenario if closely related? Or maybe better stated, should each scenario do exactly one thing and only that one thing?

  • 1
    each scenario should verify exactly one expectation about the behavior of the code under test. – Timothy Truckle Mar 31 '18 at 20:02
  • When a test fails how wild do you want the goose chase? – candied_orange Mar 31 '18 at 22:31
2

If you are asking about BDD one of the things you are trying to achieve is for the test wording to match the requirement wording.

The requirement wording can often be quite broad and cover more than one case.

However, If you are asking about unit testing, you want to make your tests test a single thing so when they fail you know exactly what fails.

You don't want to stray too far from the requirement wording, splitting up requirements into odd technical wording that the end user wont understand. But theres no harm in having extra unit tests for technical requirements where the requirement is broad

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.