re: TDD and mocks

Emil Gustafsson — Wed, 15 Oct 2008 22:28:21 GMT

By stub I basically mean "a mock without knowledge of usage expectations", mor on that here: http://blogs.msdn.com/cellfish/archive/2008/04/22/mocks-are-not-stubs.aspx

I agree that the use of mocks where we only verify number of calls and not the order is a much better use of the mock object than testing for order too.

Reading the example I also see how you probably missunderstood what I meant. The code in the example is part of a method used for transfering money so the behavior being tested is actually "transfer money". Assuming we can tell the method what transaction and what accounts to use we can mock them all if we want. Since the behavior we're testing is "transfer money" and that is the public interface the only thing we can say from that perspective is that the transaction should complete and the accounts should have their balance change correctly. If we use mocks to verify that the transaction object gets commit called once and each account object have add/remove called once we are not only verifying the behavior of the interface, we're also verifying the internals of that interface. And the whole point with an interface (IMHO) is to hide the internals since they are not important. If I wanna do something like for(int i=0; i<ammount;i++) { accountFrom.remove(1); accountTo.add(1); } that should be my choice of implementation and should not be something I can't change because the mocks think otherwise.

That is why I think mocks should be used as little as possible when you're TDD/BDD:ing. When you write your test/spec you should concentrate on what behavior the interface should have - not how the interface is implemented internally. The exception from this rule is when you want to verify a protocol os some sort where there are rules of the protocol to make calls in a certain order.

And last, I agree that if you decide to use mocks you should not assert on state but rather on the (internal) behavior the mocks define. But that is something I personally don't think you should do for reasons described above.

re: TDD and mocks

Keith Braithwaite — Tue, 14 Oct 2008 10:44:17 GMT

Maybe I don't understand what you mean by a "stub" here. I don't see any return values, so what can be asserted over?

With mocks, a test for commit would say only and exactly what it needed: that two different accounts are given two different commands with the same value. Note that we do not have to say anything about the order of those commands. In this way we go in the direction of decoupling, because now we don't need to check that accounts work properly as part of our check that commit works properly (or even that accounts are simulated properly with a stub).

The use of mocks lets us say: assuming that accounts work properly, commit will work properly because this is how it uses accounts. Really good mocked tests don't have any assertions, which also gets us away from (writing tests about) managing state. Which is a win.