Strictly mocked operations rather than strictly mocked interfaces?

Recently I’ve been planning to contribute to the rhino mocks wiki. One of the topics I thought I would write about is when I would use the different types of mock (CreateMock, DynamicMock, Stub etc). To this end I was trying to think why you would want to use CreateMock; that is a mock that enforces strict replay semantics.

When would you want strict replay?

- When you don’t want your target (System Under Test) to make calls other than those that you have expressly defined. Usually I don’t think you care, but sometimes these calls will be ‘expensive’, in the sense that they do something like make a web service call, and so we don’t want to make the call un-necessarily. Or that they cause a change of state, that is where making the call would result in incorrect behaviour of the system (e.g. A method that called CreditCardService.TakePayment() twice instead of once would probably be a ‘bad thing’). In these examples what I am really bothered about is that certain mocked operations obey strict replay semantics, rather than the whole interface.

How to use strictly mocked operations in Rhino Mocks

So if we want a mocked operation that obeys strict replay semantics we can simply use a DynamicMock and set individual operations to be restricted using Repeat.Never() or Repeat.Times(), I would also argue that this will result in much more expressive tests as you are expressly saying what operations should not be called rather than hiding this in the type of mock created.

I am not saying that a strictly mocked interface is completely un-necessary, sometimes you know that an interface is full of methods we don’t want to call (such as a web service client), and we don’t want to have to enumerate every method. Rather you should probably think about what you want to restrict calls to.

Suggested rule of thumb:

• If the interface is to an ‘expensive’ class to call use a strictly mocked interface.
• If the interface contains methods which result in a change of state then certain methods should be strictly mocked.

TALC Driven Development

Recently I’ve been reading several blog posts about the effectiveness of Test Driven Development. Of particular interest is Jacob Proffit’s TDD or POUT

It seems to me that there is Plain Old Unit Testing, which I would argue implies “test at the end” unit testing at one of the spectrum, and then pure TDD at the other end. I see myself being near the TDD side, but not all the way; in fact I would categorise my approach as “Test After Little Code” Driven Development, or Pragmatic Unit Testing. What I tend to do is write a little bit of code first then write a test that exercises the code. From that point I’ll do one of two things, either write another little bit code and then test it, or sometimes write another test which deals with a slightly different case and then write the code to make it pass. Often different situations seem to lend themselves to a different approach.

I’m not sure exactly how Jacob does POUTing, but I’d imagine he doesn’t leave all the unit testing to the end. I think this is the real ‘enemy’ of unit testing, as by the end you are facing all the issues that TDD addresses such as code that isn’t testable, or no time left to test. These issues aren’t only solved by TDD, they can also be solved by incremental unit testing.

Missing ‘Test’ ‘Edit’ or ‘Properties’ buttons in Fitnesse

Today I’ve been trying to get my head around Fitnesse, so far it seems pretty cool. One thing that confused me, that I found a neat solution for, is that the help often says press the test button on the page, but there was no test button…

So to get a test button you can click on the Properties button and tick the Test checkbox. That’s great, but what if there is no Properties button either? The same problem sometime happens when the ‘Edit’ button is missing.

The solution relies on the fact that all the buttons do is link back to the same page with a Get query string so to test a page you can simply add ?test to the URL (e.g. http://localhost/page?test). This works but can get a bit tiresome, so you should use the properties page to add the required buttons to the page, so if the Properties button is missing simply add ?properties to the URL, tick the required functionalities and save! bob’s your uncle!