How to test that objects get updated using a fake repository

Question

Say I have the following business logic:

    foreach (var item in repository.GetAll())
    {
        if (SomeConditition)
        {
            item.Status = Status.Completed;
            repository.Update(item);
        }
    }

Now I write the following unit test:

    public void Test()
    {
        var repository = new FakeRepository();
        repository.Add(new Item());

        RunBusinessLogic(repository);

        Assert.AreEqual(Status.Completed, repository[0].Status);
    }

FakeRepository is implemented over a List, and GetAll() simply returns the list.

While I can test most of the logic involved using this approach, I cannot verify that I have remembered to call repository.Update() in the business code. Because FakeRepository.GetAll() returns the actual objects, the repository objects will already have been modified by business code before I call Update(). In fact, FakeRepository.Update() does nothing.

I realize I can use FakeRepository.Update to record that it has been called, an Assert that in the test. But if I forget to call Update, I cannot be trusted to remember to Assert the Update either, right? I would prefer the test to simply fail if the Update call was omitted.

Any ideas?

Answer 1

A mocking framework might be useful here as it allows you to verify which methods are actually called. To name a few:

• Rhino Mocks
• NSubstitute
• moq

And here's a nice comparison between those three popular frameworks.

Answer 2

I realize I can use FakeRepository.Update to record that it has been called, an Assert that in the test. But if I forget to call Update, I cannot be trusted to remember to Assert the Update either, right? I would prefer the test to simply fail if the Update call was omitted.

When you notice that you're not testing that Update is called, or you notice that Update isn't called, that's when you write a test that Update is called. Not that the item in the repository is completed, but that Update is called (it's a different test). You've decided that it's important to you that Update be called, so you need to test that. The way to go about it is exactly as you outline - record the call to update in your FakeRepository, and test against that.

Answer 3

There are several things that can be unit-tested separately here: the Repository.getAll() and the Repository.update() methods, and the evaluation of the completion condition for each item, or each kind of item. I'm not sure I will use a FakeRepository here.

As suggested, another option would be to have the FakeRepository.update() method recording and/or counting the number of updates.

But if I forget to call Update, I cannot be trusted to remember to Assert the Update either, right?

Correct, but when you follows the TDD process, you will fail your test first - red - then you write the code to make it pass - green. You will write the assertion first, causing the test to fail, and then invoke the update() method, making the test pass.