Skip to main content

The purpose of the MOCK

In response to a much nicer blog entry, that can be found here.

There are actually several distinct "tests" that make up usual unit tests, among them two that really do stand out:
  • one kind of testing to test method flows,
  • one to test some sort of computation.

Mock objects are for the purpose of testing method flows. A method flow is a series of message transmissions to dependent objects.

The control flow logic inside the method(the ifs and whiles) will alter the flow
  • in repsonse to the parameters of the method call parameters passed by calling the method under test,
  • depending on the state of the object that contains the method under test and
  • the return values of the external method calls(aka responses to the messages sent).
There should be one test method for every branch of an if statement, and usuale some sort of mock control objects in the mock framework will handle loop checking.

BTW: I partly use message transmission instead of method invocation to include other kinds of "not really method invocations" like "exceptions".

The author of the afore mentioned post is quite right with his observation, that his test resembles the method under test quite closely, except, of course, for the control flow code(loops, conditionals). And that is absolutely desired, as he is testing mainly the "method flow" - there is not much computation necessary in JDBC code like this anyway.

It is tempting to raise the objection that a change in the order of messages sent to another object inside the method under test will result in a failing test, but it is easy to perceive the fact that the order of messages send to ONE object SHOULD be relevant. If it is not, well then there is no point in changing the method under test, isn't there?

Even if the method under test send variuos messages to various distinct objects, the order will be relevant at some level of abstraction. Therefore mock-checking of the order of method invocations can be(and must be) adjusted, at least if multiple distinct objects are addressed by the method under test.

And nothing else is it, that the author proposes, although, a little more complicated, than necessary when using easymock, for what I know.


Matt McGill said…
Thanks for your response! Your thoughts line up well with a jMock paper I recently read.
Anonymous said…
An very nice introduction to testing in general and object orientated testing can be found in the german book "Objektorientiertes Testen und Testautomatisierung in der Praxis - Konzepte, Techniken und Verfahren" from Uwe Vigenschow (ISBN 3-89864-305-0). The publishing company is dpunkt verlag.

More information can be found at

Popular posts from this blog

Keys, Values and Rules: Three Important Shake Concepts

The title was a click-bait! This article will actually try to explain five instead of three important notions in Shake.

These are:
RulesKeysValuesThe Build DatabaseActions
This short blog post was inspired by the hurdles with my Shake based build, after the new Shake version was released, which had breaking API changes.

Jump to the next section if you are not interested in the why and how of this blog post.

Shake is rule based build system much like GNU make. Like make it is robust, unlike make, it is pretty fast and supports dynamic build dependencies.

But you knew all that already, if you are the target audience of this post, since this post is about me explaining to myself by explaining to you, how that build tool, I used for years, actually works.

Although I used it for years, I never read the paper or wrapped my head around it more than absolutely necessary to get the job done.

When Shake was updated to version 0.16.x, the internal API for custom rules was removed. Until then I w…

Lazy Evaluation(there be dragons and basement cats)

Lazy Evaluation and "undefined"
I am on the road to being a haskell programmer, and it still is a long way to go. Yesterday I had some nice guys from #haskell explain to me lazy evaluation.

Take a look at this code:

Prelude> let x = undefined in "hello world"
"hello world"

Because of Haskells lazyness, x will not be evaluated because it is not used, hence undefined will not be evaluated and no exception will occur.

The evaluation of "undefined" will result in a runtime exception:

Prelude> undefined
*** Exception: Prelude.undefined

Strictness means that the result of a function is undefined, if one of the arguments, the function is applied to, is undefined.
Classical programming languages are strict. The following example in Java will demonstrate this. When the programm is run, it will throw a RuntimeException, although the variable "evilX" is never actually used, strictness requires that all
arguments of a fu…

Erlang mock - erlymock

The project has evolved and can be found here: ErlyMock

Some features

Easy to use
Design based on easymock
Works together with otp: can be used even if the clut is called from another process, by invoking mock:verify_after_last_call(Mock,optional: timeout)
custom return functions
predefined return functions for returning values, receiving message, throwing exceptions, etc..
erlymock automatically purges all modules that were mocked, after verify()
Custom argument matchers:

%% Orderchecking types: in_order, out_of_order, stub;
%% Answering: {return, ...}|{error, ...}|{throw, ...}|{exit, ...}|{rec_msg, Pid}|{function, Fun(Args) -> RetVal}
expect(Mock, Type, Module, Function, Arguments, Answer = {AT, _}) when AT==return;AT==error;AT==throw;AT==exit;AT==rec_msg;AT==function ->
call(Mock, {expect, Type, Module, Function, length(Arguments), {Arguments, Answer}}).

%% this version of expect is suited for useing custom argument matchers
expect(Mock, Type, Module, Fun, …