After five weekly beta-releases we feel that rMock-2.0.0 is mature enough for a first release candidate.
When You download and start using rMock You will find several features that you recognize both from EasyMock and jMock. You record expectations like with easyMock, but modifications look more like JMock.
rMock differs from both JMock and EasyMock primarily by its stricter workflow. All mocks change state at once, always. All mocks are verified automatically, at the same time, without exceptions.While testing You need both interaction-based and state-based tests. rMock provides consistent tools for both, Your custom constraints can be used state-based with the assertThat method or interaction-based by modifying your expectations.
rMock always provides all the information available on failure, both state-based and interaction-based. Are you currently verifying or recording? Are there any unmatched expectations? Which expectations can match?
That is not all; rMock also provides an innovative feature called dynamic suites. Dynamic suites help you manage your tests consistently both in build time and development time, making sure that no tests are left out of the suite unintentionally. Again, the same familiar constraint model is used, this time to select tests for your suite.
Here are a few of the more interesting features of rMock:
* rMock is tested with rMock in java 1.3 and java 1.5
* Strict flow of your tests, in the name of clarity
– rMock has a strict record, modify and verify flow.
– All mocks automatically verify themselves in the post verification phase.
* Full support for mocking of classes
– Actions can be forwarded to the underlying implementation if desired.
* Interception of invocations to collaborating objects
– Expect certain calls: Has close() been called on your ByteArrayOutputStream?
– Forbid certain calls: The class under test is not supposed to call close()
– Fake exceptions and much more
* Consistent constraint model in both state-based and interaction-based testing.
– The assertThat(<actual>, <expression>) can be used in place of the traditional assertXxxx(<expected>, <actual>) methods.
– If an assertThat fails rMock tells you if you are still setting up or verifying.
– If an assertThat fails rMock reports which expectations are not yet fulfilled.
* Define structure with sections
– beginSection(<section>) and endSection() groups your expectations so that your intentions with the test become clearer.
– Enforce order with an ordered section
– Unordered and ordered sections can be nested to any level giving you the tools to express yourself.
* Convenient mock declaration
– if your method returns an interface, a mock is automatically created for you when it is invoked in the recording state.
– Classes that have a no argument constructor can be mocked the same way as interfaces.
– If your class needs constructor arguments, the constructor can be selected by explicitly specifying its parameter types, or you can let rMock figure out which constructor to use based on the parameters you pass.
rMock is the first step in our concept of Test Driven Documentation. We beleive that most of the relevant documenation in a project could, and should be generated from tests in order to keep it consistent, up to date and sufficiently detailed.
Being able to generate documentation from tests would further increase their value, leaving more time for refactoring and gaining even more benefit from writing clear, understandable code.
In our sister project rDoc we have already generated first sequence diagrams from tests. And following the "eat your own dog food" fashion, in which rMock has been developed, we are working hard to be able to generate all rMock documentation and examples from our tests.
Sounds interesting? Check out rMock for a start and stay tuned for the first release of rDoc.
Joakim Ohlrogge on behalf of The rMock team