Discussions

News: jMock 1.0 released

Bookmark and Share Get thread feed

  1. jMock 1.0 released (21 messages)

    • Posted by: Joe Walnes
    • Posted on: June 02 2004 05:52 EDT
    jMock 1.0 final has been released. jMock is a library for testing Java code using mock objects.

    Mock objects help you design and test the interactions between the objects in your programs.

    jMock provides an API that allows you to specify the expected interactions on your objects in a readable and flexible manner.

    The jMock package:

     - makes it quick and easy to define mock objects, so you don't break the rhythm of programming.
     - lets you define flexible constraints over object interactions, reducing the brittleness of your tests.
     - is easy to extend.

    jMock supercedes the DynaMock library.

    http://jmock.org/
    Reply to this

    Threaded Messages (21)

  2. Not impressed[ Go to top ]

    I tried to use JMock about a month back. Frankly, I wasn't impressed by it a whole lot.

    The way you set your expectations starts getting very clunky. Also, while setting expectations, we need to pass all the method names as string and there is no type check involved there. for example,

    mockSubscriber.expects(once()).method("receive").with( same(message) );

    So if we name "receive" as "Recieve".. test case will fail.

    IMHO, Easy Mock is still the best dyanamic mock objects implementation around.
    Reply to this Reply to original

  3. Not impressed[ Go to top ]

    I tried to use JMock about a month back. Frankly, I wasn't impressed by it a whole lot. The way you set your expectations starts getting very clunky. Also, while setting expectations, we need to pass all the method names as string and there is no type check involved there. for example,mockSubscriber.expects(once()).method("receive").with( same(message) );So if we name "receive" as "Recieve".. test case will fail.IMHO, Easy Mock is still the best dyanamic mock objects implementation around.
    I also have a very good experience with easymock: it's simple and intuitive in a pretty unbeatable way (as for setting expectations). Don't know if there are features in jmock that are in easymock, though.
    Reply to this Reply to original

  4. Not impressed[ Go to top ]

    I tried to use JMock about a month back. Frankly, I wasn't impressed by it a whole lot. The way you set your expectations starts getting very clunky. Also, while setting expectations, we need to pass all the method names as string and there is no type check involved there. for example,mockSubscriber.expects(once()).method("receive").with( same(message) );So if we name "receive" as "Recieve".. test case will fail.IMHO, Easy Mock is still the best dyanamic mock objects implementation around.
    I also have a very good experience with easymock: it's simple and intuitive in a pretty unbeatable way (as for setting expectations). Don't know if there are features in jmock that are not in easymock, though.
    Reply to this Reply to original

  5. Not impressed[ Go to top ]

    You may be interested in keeping an eye out for "JMocks" (jmocks.sourceforge.net).
    Its not there yet - but i'll hopefully be uploading it in the next couple of weeks.
    Its built on top of BCEL, and provides the following:

    * Mocks for (non-final) classes (including abstract classes) and interfaces
    * Intuitive "entry facade" providing the ability to "record" expectations in terms of method invocations on the mock object (similar to EasyMock I believe)
    * Support for "Method Filters" to provide control over the methods which are actually mocked at run time (e.g, to facilitate easy testing of template methods)
    * Support for custom validation and invocation listeners to enable more flexible validation if required
    * Access to full method call history

    and probably a couple of other things I forgot about.

    Dave
    Reply to this Reply to original

  6. try it[ Go to top ]

    two months ago i converted the unit test suite of my portal server from easymock to jmock, and now my tests have much better readability, and are also much shorter. the idea of easymock is nice, but in practise the jmock api offer better options to specify exactly what you expect. I would encourage all easymock fans to convert one of their unit tests to jmock, and then compare the code.

    regards
     chris
    Reply to this Reply to original

  7. What about refactoring?[ Go to top ]

    The key thing with test-driven development is constant refactoring. Until I used EasyMock's "record" capability, this was always a major source of pain. JMock appears to have the same problem many of the mock packages do: they specify method calls via Strings.

    EasyMock is different in that you put the mock object in record state and then replay state. By doing this, when you refactor your code it is automatically updated. This is by far the most important feature that any mock framework can havev as far as I'm concerned.

    Once you've done TDD with a record-playback mock library (like EasyMock) you won't go back.

    Patrick
    Reply to this Reply to original

  8. What about refactoring?[ Go to top ]

    Not having the IDE automatically rename your method in your mock is a small price to pay.

    jMock will always check the method name you pass to it actually exists in the object (and the parameter types) and fail immediately if they do not match. So if you ever rename a method and miss a test, your unit tests will immediately point this out.

    With a record/playback approach you often end up having to specify implementation specific issues within your unit test. Apart from the fact that it reduces the usefulness of TDD (as you have duplication) it also makes it *harder* to refactor as a change in the implementation will break the tests.

    The jMock model encourages you to test behavior rather than implementation.
     
    I refactor mercilessly, and I find the cost of having to fix the occasional test minimal compared to the cost of fixing tests that test too much.
    Reply to this Reply to original

  9. re:What about refactoring?[ Go to top ]

    Once you've done TDD with a record-playback mock library (like EasyMock) you won't go back.Patrick
    thats exactly what i did. I started tdd with easymock and now i use jmock for it. I add the methods manually to the interfaces while i construct my stubs and expectations. And about renaming: idea can search strings too when renaming methods, and while this sounds a bit scary it worked very well for me. And if it doesnt i have a failing test, easily fixable in seconds.
    Reply to this Reply to original

  10. jMock has different strengths to EasyMock[ Go to top ]

    EasyMock is a very nice library - I used it for a long time before getting involved with jMock (as well as many other mock libraries).

    EasyMock provides an intuitive mechanism for defining expectations by reusing the interface you are mocking. For simple expectations where you are testing all the parameters passed in, the usage is very clean and elegant.

    The jMock API uses a builder style pattern for defining expectations. The advantage to this is it allows much more flexible expectations and constraints to be specified. This leads to a more expressive unit tests that specify what they are testing (and no more) and reduces the brittleness of tests as your code evolves.

    Through jMock, it is easy to setup very precise expectations (and stubs) on your mock without ever needing to overspecify. For example, you could easily specify expectations such as:

     - "Stub the getStuff() method to return X or Y when parameters A or B are passed in respectively, otherwise throw a NoSuchStuffException"
     - "Expect eatStuff() to be passed with a second parameter that's less than 20 (and I don't care about the other parameters".
     - "Expect eatStuff() to be called 3 times with these parameters (a, b, c, d) - I don't care about the order, so long as they all happend before throwUp() is called."
     - "Stub any getter that returns an int to return 99, and expect no setters to be called."

    This flexibility improves the quality and usefulness of unit tests, and reduces the amount of needless setup required not relevant to your test 'just to make the mock work'.

    Once you become familiar with the jMock API, the syntax becomes readable so you can easily understand the intention of the test when you visit it again later.

    Of course you do have the downside that because method names are specified in strings, you don't get the features of a strongly typed API. This is annoying, but given a choice, I find flexibility much more important (besides your tests will start failing if you mess up a method rename). It would be nice to get the best of both worlds, that combines the ease of use of EasyMock and flexibility expressiveness of jMock.
    Reply to this Reply to original

  11. jMock has different strengths to EasyMock[ Go to top ]

    It would be nice to get the best of both worlds, that combines the ease of use of EasyMock and flexibility expressiveness of jMock.
    I do not recall the details but a couple of months ago there was a chain of discussion on jMock forums where an opinion suggested that jMock has a core api which would could form the basis on which other mock testing frameworks similar to easymock / virtual mock could be built. I am not sure if that would allow one to create something that would support what you desire. Maybe someone from the jMock team could respond to this.
    Reply to this Reply to original

  12. jMock has different strengths to EasyMock[ Go to top ]

    This is true. The jMock API is split into three parts.

    1) The invocation matching library. This is a low level engine for specifing the behaviors of stubs and expectations in a mock object.

    2) The front end. This is used to mimmick the object to be mocked. The standard front end is to use a dynamic proxy to implement an interface.

    3) The syntactic sugar API. This is the higher level builder style API designed to be used from unit tests for building the lower level invocation matching objects.

    It is easy to create another high-level API for the library so you could use something like the EasyMock style record/playback mechanism, or the DynaMock front-end, or a parsed domain specific language.

    Likewise, you can also create alternate front-ends. For example, there's an add-on package that uses CGLib instead of dynamic proxies to generate mocks, which is faster and supports mocking of concrete classes. These can also be used in a static-mock based framework.
    Reply to this Reply to original

  13. jMock has different strengths to EasyMock[ Go to top ]

    It would be nice to get the best of both worlds, that combines the ease of use of EasyMock and flexibility expressiveness of jMock.
    From a previous posting it appears that such solution exists: "JMocks" (jmocks.sourceforge.net). This sounds like it provides fairly fine-grained control of mock objects if desired, in additional to the simple record/playback mechanism.

    Maybe someone from the sourceforge JMocks project can elaborate on this?
    Reply to this Reply to original

  14. jMock and EasyMock Comparison Article[ Go to top ]

    I've written a comparison of the jMock and EasyMock APIs and added it to the jMock website at http://www.jmock.org/easymock-comparison.html.

    Obviously, as the lead jMock developer I'm somewhat biased in favour of jMock but I've tried to present a balanced view of what is good about the two APIs and why we designed jMock the way we did.
    Reply to this Reply to original

  15. How about grammars, like doA {0,3} doB doA* ?[ Go to top ]

    While plaing with mocks I came to the conclusion that it would be nice
    to have a grammar specifying legitimate sequences of events. That is
        doA {0,3} doB doA*
    would mean:
        from 0 to 3 invocations of doA
        exactly one invocation of doB
        any number of invocations of doA
    a bit similar to regular expressions which are grammars too.

    Did any testing framework in general and mock objects framework in particular work in this direction?
    Reply to this Reply to original

  16. Is it safe to say that mockobjects.com is out of competition?[ Go to top ]

    Still have to explore the wonderland of JMock.
    A quick question about mockobjects.com -- are they out of business?
    Does anybody know what is happening in their land?
    Reply to this Reply to original

  17. Is it safe to say that mockobjects.com is out of competition?[ Go to top ]

    Most of the team behind the original mockobjects.com expectation library and the DynaMock package are also the team behind jMock.

    We are changing the focus slightly...

    www.mockobjects.com is becoming a general site to find out information on mockobjects. This will include: tutorials, patterns, best practices, news, community discussions and a directory of other mock object libraries. This site will not be Java specific. It shall be getting a face lift in the near future and filled with more content.

    www.jmock.org is the home of the Java mock objects library that started out on mockobjects.com. The library has evolved based on experiences, feedback and further understanding of effective usage of mocks.

    The old libraries on mockobjects.com will have very little further development as we encourage people to move to jMock. However, they will still be supported as there is already an existing userbase.
    Reply to this Reply to original

  18. Is it safe to say that mockobjects.com is out of competition?[ Go to top ]

    Oh, it's totally fine! Everything changes and new designs take over the old ones.

    I only wish the was clearly denoted somewhere on the mockobjects site!
    This would have saved me the time of learning mockobjects 0.9 if I knew
    that I was encouraged to migrate to JMock. I wish that you (the developers)
    would find a way to clearly pass this message: "there will be no
    mockobjects 1.0, please slowly migrate to JMock if you can!"

    And also as I have clearly written in Bugzilla there is a bad need
    for mockobjects 0.9.1 to fix a couple of the flawes which are trivial
    to fix for thouse still using the old libraries.

    Have great success on your paths!
    Reply to this Reply to original

  19. Doesn't scale up. Cannot create good error messages[ Go to top ]

    I've implemented a library that does that, although not quite with that syntax.

    The problem is that the number of states becomes huge when you have to specify partial ordering of method calls.

    Also it is very hard to generate good error messages. A test tool that cannot tell you why a test failed is not much use. If you have to run a test in a debugger, the test tool has not done it's job, so good error messages are vital.
    Reply to this Reply to original

  20. Oops. I meant to reply to the post about using a grammar. [eom][ Go to top ]

    e o m
    Reply to this Reply to original

  21. Fear for JavaDoc ?[ Go to top ]

    I've tried to use the JMock, but the effort stranded when I started struggeling and tried to look at the JavaDoc to find answers. Isn't 'cool' enough to write sensible JavaDoc ?
    Reply to this Reply to original

  22. Fear for JavaDoc ?[ Go to top ]

    Okay, the JavaDoc isn't ideal, but it's getting better. However there are a fair number of tutorials on the site to get across the basics. There is a lot more documentation in the pipeline, including articles, best practices and JavaDoc.
    Reply to this Reply to original