Continue from the last post. Remember the JMock example I used? It’s a simple add() operation:
one (calculator).add(2, 2); will(returnValue(5));
Now, what if, just for fun, I used my own class called MyInteger instead of primitive int as the parameter for add() method? The expectation will be written like this:
one (calculator).add(new MyInteger(2), new MyInteger(2)); will(returnValue(5));
So I expect one single call to add() method with two parameters of type MyInteger. This simple expectation will fail miserably with JMock because it compare the expected parameters with the actual parameters using the equals() method. The persistence layer I’m using, like a lot of other similar products, prevents me from overriding the equals() method. So JMock is actually comparing the reference. I won’t be surprised if there is a workaround for it. But since I had SevenMock set up and running in ten minutes, I won’t spend my effort looking for those workarounds.
In jMock you use a parameter Matcher. Two minutes of reading the cookbook would give you the answer.
If it sounds as if you have not understood how your persistence layer works. A value type (like an integer) should always implement equals and hashCode. An entity should not, and should only be compared by reference. So jMock does the right thing and, by failing the test, is showing you that there is a problem in the code.
Glad to hear that you found SevenMock useful
I’d certainly be interested to know if you or anyone else has thoughts on whether/how SevenMock could be extended. I’m keen to keep it simple, but a couple of ideas that I’ve been working on are a test recorder and flexible sequencing.
I’m using the project wiki to push some ideas about: http://seven-mock.wiki.sourceforge.net/Features+and+Improvements
@James: I guess I was just not patient enough to read through the tutorial. I understood SevenMock the moment I read its example.
@Colin: I’ve been writing more tests with SevenMock. I’ll sure post my findings on the Wiki.