Test arrangement using the system under test

Question

I have some integration tests around stored procs. Typically I do the test setup using Dapper. This is fine for simple cases, but in some cases to setup up the system correctly it would be far simpler to call the necessary stored procs. It would be simpler because some entities have many relationships and constraints and replicating that in Dapper is time consuming, plus if I change the system I have to then change my Dapper test setup code too.

Is it a good idea to use the system to setup the system to test or should I keep the setup of the system independent of the system?

I've added a simple code sample, below, (not representative of my actual system) to help clarify what I mean. In the first test I'm checking that CreatePerson actually adds an entity into the Person table. In the second test I use the method I just tested, CreatePerson, to setup the system and then test something else.

public class When_CreatePerson_is_called
{
    [Fact]
    public void It_should_create_entity()
    {
        // arrange
        var db = new Database();

        // act - testing CreatePerson does what is expected of it
        int id = db.CreatePerson();
        Person p = db.GetPerson(id);

        Assert.NotNull(p);
    }
}

public class When_UpdatePerson_is_called
{
    [Fact]
    public void It_should_update_untity()
    {
        // arrange
        var db = new Database();
        int id = db.CreatePerson(); // Should I use a different way to initialize the system or is it ok to use the system?

        // act
        db.UpdatePerson(id, "John Smith");
        Person p = db.GetPerson(id);

        Assert.Equal("John Smith", p.FullName);
    }
}

Answer 1

In any one test, this can be either a good or a bad thing. Most likely, it's a good thing that you can write this test at all, and it's a good thing to have a test that runs the real CreatePerson alongside the real UpdatePerson.

In general, the fact that you can use a piece of production code in tests at all is already a good thing. There absolutely should be tests which exercise all of your production code, but whether two pieces of production code should be tested together or separately is much harder to tell.

When you find it difficult to write a test that exercises only one method in the production code, without calling other methods around it, that usually means one of the following:

1. Because of how the API works, it makes no sense to call that method in isolation, so it's perfectly fine for none of the tests to call it in isolation. For example, almost every test on a dbConnection.executeQuery() method is going to have to call database.makeConnection(). That's just the way databases work.

2. Your methods are overly coupled to each other, and there's an opportunity to refactor things in a way that would make both the tests and the production code easier to write.

For the specific example you've given, #1 seems far more likely to me. It just doesn't make any sense to update a person that doesn't even exist yet, so in production code nobody's ever going to call UpdatePerson without first calling CreatePerson (or else they get an error...which you should have another test for).

One useful litmus test to help decide is to consider what these two different tests are saying about your public API. If you write a test that calls UpdatePerson on a mock prepopulated database, you're saying that UpdatePerson should always assume that particular database structure, even if it was created by some other API. If you write a test that calls UpdatePerson after calling CreatePerson, you're saying that UpdatePerson should always return whatever was passed into CreatePerson, no matter how it was stored. Which of those sounds more correct for your project?

Answer 2

It is perfectly ok to use production code for your tests as long as you don't shortcircuit the test. For instance, don't do this:

var expected = 4;
var actual = Calc.Subtract(Calc.Add(expected, 1));
Assert.AreEqual(expected, actual);

As long as you know the test fails when anything is wrong, I think it is even better to reuse production code for test setups.