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.
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...
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- global test setup and teardown outside of the respective test/unit framework (useful for example to start a JEE server only once during a test run)
- checking the distributables (jars, wars, ears, ...) in order to not to forget license files, manuals or other artifacts a developer usually is minor aware of.
(A hint for the scala people: If I got it right, you're switching from sbaz to maven. Is this really necessary???)