What would you think about a MIMOCK?

The use of mocking in [TB]DD allways makes me feel slightly bad. I just don't like the idea of using an object in my tests, that is potentially pretending a behaviour, that the implementation of the 'real thing' might not provide. And: I suspect not being the only one... But the alternative, i.e. using the real dependency, has several disadvantages:

Tests tend to be slow:
Often a dependent service, object, etc., requires some amount of time to be set up in regular test runs. This is particular bad, if you're commited to a test driven approach. This might not be significant while executing only a few tests, but very annoying for a large test suite.
Tracing errors is more difficult:
Mocking provides a natural way of decoupling tests. If for example a large service framework is represented by a mock object, a test failure clearly is not to be found in the dependency! If the real service framework is used instead, any kind of unpredictable errors could occur due to e.g. networking problems or any other thing.
So far about the disadvantages of not using mocks. So why hesitate? Now my problem with this is the following: A mock object is just another artifact created by a human being--a code snippet. And we all know, programmers introduce between one and three bugs every thousand lines of code. Thus a mock setup may be wrong, just with any other piece of code. Now what could be a solution to this? This evening I had a vision of a new approacht to mocking, I thought could be named:



Mimocking

Mimocking is a creation out of the word mimic and mocking. The basic idea is:

A mimock should use the 'real thing', e.g. the real service our artifact under test depends on, if executed for the first time. It may then generate a derived mock out of the used interface and store it as a cached value object. This object could then be reused over and over again, as long as it is used in the same manner AND the dependent object, library or service (the real thing ;-) stays the same--hence is not updated.

Please post your feedback, since I think this to be a feasible approach. Why not make an open source project out of this...

Posted at 00AM on 02/21/10 | 0 comments | Filed Under: | read on

Leaving Maven

Up until now I have tried maven a few times and I am convinced, the best way to push maven to work is to drop it. The deceptive simplicity of it's initial usage leads into continuous maintenance issues fairly quick. I made some more comments on this in an earlier article. The web is full of statements supporting this opinion. Just try to google for "maven hate" for example. Or take this citation of Matthieu Riou on the buidr homepage:

"The biggest mistake afterward was to migrate to Maven2. I could write pages of rants explaining all the problems we ran into and we still ended up with thousands of lines of XML."

Another drastic example may be found here. Unfortunately I do not have an evaluated recommendation for a different tool. Nevertheless buildr seems to be an interesting concept. They extend the popular ruby build tool rake with several features specific to the java world including support for other upcoming languages with increasing popularity as for example groovy or scala. Most interesting for people completely annoyed by maven is builder's support for dependency management and it's access to maven repositories. And finally there is a tempting reason, why I will give it a try: Buildr seems to have some useful testing features. There is support for I then will share my experiences with you : -) .

(A hint for the scala people: If I got it right, you're switching from sbaz to maven. Is this really necessary???)

Posted at 14PM on 11/17/09 | 0 comments | Filed Under: | read on

Is it about...

...the life of the fallen toad?

Is it about standing up again, tinkering your bones and jumping back into the mud?

Not really...

I'm back in the mud, finally. And I like it! So it's more about my sludgy thougths and experiences, anger sometimes, optimism and - most important - the beauty of life.