Using a feature with 2 identical scenarios but, different tags. How to do in a DRY way?

Question

Came across this scenario and wondered if there was a DRYer solution.

A feature with multiple scenarios. Each scenario has the same steps but, has different tags.

Tags are used in Before scenario setup to change configuration settings.

Example:

Feature: ABC

Tests for ABC

@tag1 @tag2 @tag3 @tag4
Scenario: Scenario for ABC
    Given step1
    When step2
    And step3
    And step4
    Then this condition matches

@tag1 @tag2 @tag3 @tag4 @tag5
Scenario: Scenario for ABC with diff config
    Given step1
    When step2
    And step3
    And step4
    Then this condition matches

Feels like too much duplication to me. I could use background and perhaps have 2 empty scenarios but, with different tags but, this feels a little dirty too.

Any recommendation as to a DRYer solution?

Note that in the real world example @tag5 actually causes the BeforeScenario in bindings to point at a different DB connection.

Answer 1

If the steps are exactly the same, consider a scenario outline where one of the parameters is some business-meaningful name that your step definition uses to configure the database connection:

Scenario Outline: Scenario for ABC
    Given the application is configured for "<customer>"
    And step1
    When step2
    And step3
    And step4
    Then this condition matches

Examples:
    | customer            |
    | City Auto Mechanics |
    | Flourists, Inc      |

And the step definition would look something like:

[Given(@"the application is configured ""(.+)""")]
public void GivenTheApplicationIsConfiguredFor(string customerName)
{
    switch (customerName)
    {
        case "City Auto Mechanics":
            // configure to connect to the database for City Auto Mechanics
            break;
        case "Flourists, Inc":
            // configure to connect to the database for Flourists, Inc
            break;
        default:
            throw new NotImplementedException($"Customer {{customerName}} has no database configuration");
    }
}

Basically, you make configuring the database one of the setup steps, i.e. a "Given". Just keep that step phrased using business language so it doesn't sound too technical, if you want to satisfy the BDD pedants.

And I don't mind saying that last part, because I'm one of those pedants... but that's my own cross to bear, not yours.