Several reasons convinced me to move cintoo Messages from jMock to EasyMock 2. The main reason is that jMock has no static importable methods for mock creation and verification. The way to do this in jMock is to extend a jMock TestCase class. Unfortunately this class depends on JUnit, so when moving to TestNG I still had to keep the JUnit jar around. Also TestNG promotes a no-inheritance test structure where jMock just doesn't fit in. The second reason is that I was bitten by method name refactorings several times. As some methods were equal in different classes, IDEA wrongfully replaced the methods strings in jMock which broke lots of tests. Another minor reason is that jMock doesn't seem to move very fast.
The transition has been made easier by EasyMock as that framework adopted a lot of ideas from jMock in version 2.x (I think :-). I still hope to use the jMock spinoff assertion DSL though with assertThat( eq(5), ...).
In the last years since the first jMock release I've been convincing clients to use jMock for their unit testing. I still think jMock is great for JUnit, but it just doesn't work with TestNG in the current version.
The funniest quote I've read for some time is "Lower-level languages that don't support associative arrays (such as C++ or Java) are not as good for implementing tag clouds, because you will end up writing considerably more code." on an ORA site. Later on in the comments the author says he really meant syntax support with "don't support", but well I can't see why a language is not suited for a problem because it has no syntax support for maps. It's nice to have, see Groovy, but 95% of the time when I use syntax sugar to create maps is when writing unit test. I very very rarely construct maps not dynamically in my applications.
Due to the help by Alex with TestNG I finalized the Messages 1.0 release.
Messages is a free framework to make internationalization easier for Java
applications. It adds several features compared to default Java internation-
alization and support locales for threads and different bundles for different
packages. This allows the usage of different bundles for different parts of
the application like plugins, the installer or logging.
- a lot less code than standard internationalization in Java
- easier to use for developers
- supports bundle refactorings
- bundles associated with Java packages
- hierarchies of bundles,
e.g. one bundle for com.corp and one for com.corp.accounting
- Low intrusive code, e.g. $(this, "FILE_NOT_FOUND", fileName)
- Locales per thread or global
- Apache license
Thanks to the help from Alex (from the TestNG project, great support) I managed to move Messages from JUnit 3 to TestNG. TestNG is more flexible and seems to move faster. JUnit 4 was released after I started moving projects to TestNG, so my default now is TestNG and I only use JUnit 4 on demand from customers. Also works great with pulse integration server, just point pulse to the xml file generated by TestNG and use the JUnit task in pulse.