Scenario Driven Tests
time to read 6 min | 1001 words

I originally titled this blog post: Separate the scenario under test from the asserts. I intentionally use the terminology scenario under test, instead of calling it class or method under test.

One of the main problem with unit testing is that we are torn between competing forces. One is the usual drive for abstraction and eradication of duplication, the second is clarity of the test itself. Karl Seguin does a good job covering that conflict.

I am dealing with the issue by the simple expedient of forbidding anything but asserts in the test method. And no, I don’t mean something like BDD, where the code under test is being setup in the constructor or the context initialization method.

I tend to divide my tests code into four distinct parts:

  • Scenario under test
  • Scenario executer
  • Test model, represent the state of the application
  • Test code itself, asserting the result of a specific scenario on the test model

The problem is that a single scenario in the application may very well have multiple things that we want to actually test. Let us take the example of authenticating a user, there are several things that happen during the process of authentication, such as the actual authentication, updating the last login date, resetting bad login attempts, updating usage statistics, etc.

I am going to write the code to test all of those scenarios first, and then discuss the roles of each item in the list. I think it will be clearer to discuss it when you have the code in front of you.

We will start with the scenarios:

public class LoginSuccessfully : IScenario
{
    public void Execute(ScenarioContext context)
    {
        context.Login("my-user","swordfish is a bad password");
    }
}

public class TryLoginWithBadPasswordTwice : IScenario
{
    public void Execute(ScenarioContext context)
    {
        context.Login("my-user","bad pass");
        context.Login("my-user","bad pass");
    }
}

public class TryLoginWithBadPasswordTwiceThenTryWithRealPassword : IScenario
{
    public void Execute(ScenarioContext context)
    {
        context.Login("my-user","bad pass");
        context.Login("my-user","bad pass");
        context.Login("my-user","swordfish is a bad password");
    }
}

And a few tests that would show the common usage:

public class AuthenticationTests : ScenarioTests
{
    [Fact]
    public void WillUpdateLoginDateOnSuccessfulLogin()
    {
        ExecuteScenario<LoginSuccessfully>();
        
        Assert.Equal(CurrentTime, model.CurrentUser.LastLogin);
    }
    

    [Fact]
    public void WillNotUpdateLoginDateOnFailedLogin()
    {
        ExecuteScenario<TryLoginWithBadPasswordTwice>();
        
        Assert.NotEqual(CurrentTime, model.CurrentUser.LastLogin);
    }

    [Fact]
    public void WillUpdateBadLoginCountOnFailedLogin()
    {
        ExecuteScenario<TryLoginWithBadPasswordTwice>();
        
        Assert.NotEqual(2, model.CurrentUser.BadLoginCount);
    }

    [Fact]
    public void CanSuccessfullyLoginAfterTwoFailedAttempts()
    {
        ExecuteScenario<TryLoginWithBadPasswordTwiceThenTryWithRealPassword>();
        
        Assert.True(model.CurrentUser.IsAuthenticated);
    }
}

As you can see, each of the tests is pretty short and to the point, there is a clear distinction between what we are testing and what is being tested.

Each scenario represent some action in the system which we want to verify behavior for. Those are usually written with the help of a scenario context (or something of the like) with gives the scenario access to the application services required to perform its work. An alternative to the scenario context is to use a container in the tests and supply the application service implementations from there.

The executer (ExecuteScenario<TScenario>() method) is responsible for setting the environment for the scenario, executing the scenario, and cleaning up afterward. It is also responsible for any updates necessary to get the test model up to date.

The test model represent the state of the application after the scenario was executed. It is meant for the tests to be able to assert against. In many cases, you can use the actual model from the application, but there are cases where you would want to augment that with test specific items, to allow easier testing.

And the tests, well, the tests simple execute a scenario and assert on the result.

By abstracting the execution of a scenario into the executer (which rarely change) and providing an easy way of building scenarios, you can get very rapid feedback into test cycle while maintaining testing at a high level.

Also, relating to my previous post, note what we are testing here isn’t a single class. We are testing the system behavior in a given scenario. Note also that we usually want to assert on various aspects of a single scenario as well (such as in the WillNotUpdateLoginDateOnFailedLogin and WillUpdateBadLoginCountOnFailedLogin tests).

Tweet Share Share 47 comments
Tags: