OliBye_blogentry_210405_2

xunitpatterns

• Write a little drunken history of MockObjects for http://groups.yahoo.com/group/xunitpatterns
• • Seems very slow to arrive on the server so I'll post it here too.

Re: Mock Object vs Stub

I think Nat defines mock most succinctly:

> A stub provides enough functionality to let the test run.

> A mock takes an active part in the test: it checks that it is being > invoked as expected, usually at the time each invocation occurs.

Why is it always Stub v Mock, does have to win? IMHO they're different and not in opposition.

I hope you'll excuse this trip down memory lane:

I tried to dig out the original MockObjects, but I seem to have removed it from my VisualAge repository, maybe Tim Mackinnon or Paul Simmons have them. I'll be green with Envy if they have.

VisualAge Java had a bug where you would stop your servlet container but the VisualAge win32 process wouldn't close the port 80 TCP server socket. This made the development cycle of our web application slow then we ran all the functional tests including hitting the servlet to check the returned HTML. In any normal process this would not be too much trouble, but it was 1999 and we really liked our radical XP idea of releasing every 15 minutes. You can only have so many cups of tea whilst VisualAges stops and starts.

The thought of fixing the bug, or VisualAge's runtime recompilation of classes (so that we wouldn't ever need to restart) didn't strike us as the simplest thing we could do in 15 minutes.

So we decided to implement as little of HttpServletRequest? and HttpServletRepsonse? as we could get away with so that we could do a simple string match on the response output stream. We passed the HTML expect in to our new response to check what was written to the stream, when we called verify. It took more than 15 minutes and Tim almost made me throw it away.

Tim had introduced me to Smalltalk and I'd picked up on the Alice in wonderland subliminal messages, so I suggested Mock would be good prefix for our classes.

We'd had problems refactoring tests. We noticed that a lot of our test code had lots of very anti Demeter like code for picking apart results and checking them (double dereferencing, calling methods on results). We had let ourselves get away with this for a while, but the cost of carry was growing. Mocks gave as a Demeter friendly layer to refactor the unpicking/verifying code. And wow we had readable tests, no need for evil getters and setters just for testing (they're bad enough in real code). The TestCase and the Mock constituted a trinity with the "unit". This was going to save the world!

It was a Tuesday and we need a drink, so went to the pub and Drank ale, Tim, Steve and Philip Craig (nUnit author) produced a paper. Steve, which his academic hat on pointed out that we should check if it had been done before. Tim and Ron had this same debate about Stubs v Mocks.

Initially we passed literals into the mock.expectSomeX(literal) and called verify at the end to check all the expected calls had been made. Call counters and clever expectation collections evolved inside the Mock, Demeter then made us pass them in. We found the expectations far more stable and being less brittle whilst refactoring. They also expressed the intent much better, so if you did have to refactor them, it was easier to preserve the intent of the test written 100 iterations ago.

Then our Mocks, were really that, empty sad husks, delegating to Expectations. We even auto generate them now, they hardly need at all. The MockObject was just a language limitation of Java, dynamic proxies (with DynaMock) then did away with the need for actual classes any more. In .NET we don't even need the interface anymore (another Java limitation).

Dale Emery's point is well made > In the world outside of coding, the word "mock" does not > convey the idea of verifying anything.

However we're forgetting Expectations, which, IMHO deserve the real credit It was expectations that were important all the time, as Tim pioneered at Connextra then Nat and Steve Freeman have extended (into the stratosphere) through DynaMock and jMock.

I coined the Mock name and I've helped refactor it to an empty shell. Let us consign the MockObject to the VisualAge of XP. I couldn't have got here without them, but now it often stands as a barrier to understanding when I'm trying to introduce DynaMock or jMock to a new team.

`Once,' said the Mock Object at last, with a deep sigh, `I was a real Object.'

Now they just make me laugh ;-)

Oli Bye