TDD and mocking

Question

First of all, I have to say, I'm new to mocking. So maybe I'm missing a point.

I'm also just starting to get used to the TDD approach.

So, in my actual project I'm working on a class in the business layer, while the data layer has yet to be deployed. I thought, this would be a good time to get started with mocking. I'm using Rhino Mocks, but I've come to the problem of needing to know the implementation details of a class before writing the class itself.

Rhino Mocks checks if alle the methods expected to be called are actually called. So I often need to know which mocked method is being called by the tested method first, even though they could be called in any order. Because of that I'm often writing complicated methods before I test them, because then I know already in which order the methods are being called.

simple example:

public void CreateAandB(bool arg1, bool arg2) {
    if(arg1)
        daoA.Create();
    else throw new exception;
    if(arg2)
        daoB.Create();
    else throw new exception;
}

if I want to test the error handling of this method, I'd have to know which method is being called first. But I don't want to be bugged about implementation details when writing the test first.

Am I missing something?

score 4 · Accepted Answer · edited May 23 '17 at 12:26

You have 2 choices. If the method should result in some change in your class the you can test the results of your method instead. So can you call CreateAandB(true,false) then then call some other method to see if the correct thing was created. In this situation your mock objects will probably be stubs which just provide some data.

If the doaA and doaB are objects which are injected into your class that actually create data in the DB or similar, which you can't verify the results of in the test, then you want to test the interaction with them, in which case you create the mocks and set the expectations, then call the method and verify that the expectations are met. In this situation your mock objects will be mocks and will verify the expected behaviour.

Yes you are testing implementation details, but your are testing the details of if your method is using its dependencies correctly, which is what you want to test, not how it is using them, which are the details you are not really interested in.

EDIT

IDao daoA = MockRepository.GenerateMock<IDao>(); //create mock
daoA.Expect(dao=>dao.Create); //set expectation

...

daoA.VerifyExpectations(); //check that the Create method was called

you can ensure that the expectations happen in a certain order, but not using the AAA syntax I believe (source from 2009, might have changed since,EDIT see here for an option which might work), but it seems someone has developed an approach which might allow this here. I've never used that and can't verify it.

As for needing to know which method was called first so you can verify the exception you have a couple of choices:

Have a different message in your exception and check that to determine which exception was raised.
Expect a call to daoA in addition to expecting the exception. If you don't get the call to daoA then the test fails as the exception must have been the first one.

daoA and daoB are being injected, and they are creating sth. in the database. So if I want to test the example above it would only make sense to test the exception handling? But the problem isn't solved by that. I'd have to know if arg1 is tested before arg2. — myAces, Apr 06 '11 at 13:19
Assuming that the doa's implement some interface then you could test that daoA had its `Create` method called and so did doaB. you would do this by setting an expectation on the mock. I'll add some detail to my answer. — Sam Holder, Apr 06 '11 at 13:35
I think I'm starting to getting the point. I'll read through your links an try what you mentioned. Thank you for the help — myAces, Apr 06 '11 at 14:01

score 3 · Answer 2 · answered Apr 06 '11 at 13:14

Often times you just need fake objects, not mocks. Mock objects are meant to test component interaction, and often you can avoid this by querying the state of SUT directly. Most practical uses of mocks are to test interaction with some external system (DB, file system, webservice, etc.), and for other things you should be able to query system state directly.

TDD and mocking

2 Answers2