rMock 2.0
Planned features
We are currently working on rMock 2.0 which is soon to be released as alpha. In rMock 2.0 the JMock compatibility is discontinued and rMock will become self contained. RMock 2.0 is a complete rewrite and backwards compatibility has been sacrificed for ease of use.
The main goal of rMock 2.0 is to be able to generate a technical specification from the test cases. If this is at all possible this would have the following benefits:
- The documentation would always be up to date, no more "This document may not be completely up to date but..."
- The documentation would contain relevant, up to date, examples of how to use the components of the system.
- The value of written testcases would be even higher which would lessen the initial resistance of writing them. That writing tests saves time will be obvious if documentation can be generated from them.
Even without the self documenting features rMock 2.0 have quite a few interesting features in store:
Tested with rMock
rMock is tested according to the "Eat your own dog food principle" meaning that rMock is tested using rMock in order to verify that all the features we put in rMock are practically useable. This also leaves plenty of examples on how to use rMock in the test cases for rMock.
Self-describing condition model
In order to be self documenting, the condition model for invocations must be possible to desribe for an external part. To achieve this, rMock has a well defined model of condition components consisting of: constraints, expressions, mutiplicities and actions. All of them can be described adequately and consistently from their public attributes.
Dynamic JUnit test suites
Defining test suites can greatly improve the speed of nightly builds but what if you leave out an important test by mistake? With dynamic test suites you can create your test suite at runtime specifying only the conditions for a test to be included in your suite. The conditions are defined in the same way as for matching methods in mocks. rMock examines your classpath to find all available tests and inludes the ones matching your conditions in the suite.
Annotations
From java 1.5 (tiger) annotations are available. rMock makes annotations available for matching using constraints. This is especially useful when creating dynamic suites. If you do not want to use java 1.5, qDocs is available as a fallback. rMock does not require java 1.5 in order to run.
assertThat(<value>, <constraint>)
rMock replaces the traditional jUnit assertXxx with a single assertThat method. This model is more extendable and more expressive for state based testing and is consistent with the model used for interaction based testing.
Pluggable mock factory
rMock supports finding mock factories on the class path, meaning that you can use cglib, werks or any other runtime aspect framework to create your mocks. This makes rMock compatible with pre 1.3 versions of java, but you can of course use java 1.3 dynamic proxys if you prefer.
No jUnit lock in
rMock is completely free standing; the mock engine can be used with any mock test framework. jUnit is the most commonly used, but other interesting ones also exist such as test-ng. This also ensures future compatibility with the upcoming jUnit 4.0
Pluggable event model
rMock sends events for everything that rMock does. This is so that the runtime model of the tests can be documented using plugins.
Policy based testing
rMock will support policy based testing. This means that certain actions are globally checked by rMock and will result in assertion failures if violated. As an example policies can be setup for which classes are allowed to use System.out and System.err to make sure that all System out output is done via the logging framework of your choice. We will look into the possibility to test security policies in this way.