Question

(C#, Rhino Mocks, MbUnit).

I have a class called AccountManager that has a RegisterUser() method. This method returns void but does throw an exception for any errors. AccountManager calls into an IDataRepository calling its AddUser() method to do a database insert.

I’m mocking the IDataRepository using a Rhino Mock and throwing and exception for a given set of arguments simulating the exception being raised in the repository.

[Test]
    public void RegisterKnownUser()
    {
        MockRepository mocks = new MockRepository();
        IDataRepository dataRepository = mocks.StrictMock<IDataRepository>();

        using (mocks.Record())
        {
            Expect.Call(() => dataRepository.AddUser("abc", "abc", "[e-mail]", "a", "bc")).Throw(
                new InvalidOperationException());
        }

        using (mocks.Playback())
        {
            AccountManager manager = new AccountManager(dataRepository);
            Assert.Throws(typeof (InvalidOperationException), () => manager.RegisterUser("abc", "abc", "[e-mail]", "a", "bc"));
        }
    }

This test works fine.

My question is what to do about the situation where the args supplied to RegisterUser are correct and valid. The real IDataRepository would not return anything nor would it thrown any exceptions. So in short AccountManager’s state would not have changed. Does this mean I don’t need to test AccountManager.RegisterUser when it would result in nothing I can observe directly in the class and method under test. Testing against state in the mock smells a bit to me. I think as long as I test IDataRepository.AddUser seperately then I shouldn’t need to test AccountManager.RegisterUser for inputs that would result in nothing observable in the class.

Thanks in advance.

Answer 1

If AccountManager calls into DataPrepository, then your test case still validates something. The record/playback here validates that a call is made into it. If the call is not made, the test case will fail. If it is made twice/with the wrong args, it will fail.

This may be a very basic test case, but it is still a good one, and doesn’t require you to place state in the mock object.