05 June 2008
Public training courses?
We've had a couple of inquiries about whether we will be running our training course publicly. We hadn't planned to, but perhaps we should. We propose to run a two-day course priced at £1100 if booked less than 4 weeks ahead of the teach date, with a discount to £800 if booked earlier (plus UK VAT). The most obvious location is London (UK).
If you think you might be interested (no commitment implied), please drop us an email at public.course@mockobjects.com with this information:
Name: London is acceptable: Preferred other location: Preferred month for teach date: Possible number of attendees: Coding experience (years): TDD experience (years): Contact email: Contact phone:
We'll see if we can work something out
In case you're feeling nervous, whatever details we receive will be used only by us just to coordinate a course. We won't hassle you or pass them on to anyone else.
Labels: jmock, junit4, news, training
23 May 2008
Learn from the source!
Nat, Romilly Cocking, and I are now open for business for training. We have a course on Test-Driven Development that reflects nearly a decade of experience writing tests first (that's 30 years in parallel). We also have significant experience in training, Romilly has a couple of decades on his own, and Nat and I have taught commercially and at two of the top CS departments in the country.
The course teaches the practice of Test-Driven Development, based on a solid understanding of Object-Oriented design, and with a strong emphasis on making tests expressive and maintainable. We also make a point of exploring how unit tests can be used to drive the design of the code, not just protect it.
The content is modular, so we can adjust it to match the needs of the participants. The full-length course is three busy days, and we've taught versions that are a half-day and whole-day long.
We teach the course using jUnit4, Hamcrest, and (of course) jMock2. Talk to us if you want something different.
For more information, contact us at: training@mockobjects.com
Here's what some attendees liked about the course:
“The practical exposure to a better way of testing”
“Practical lab work, real-world concrete examples, Expert lecturers!”
“Chance to make mistakes and learn. Exposure to new technology.”
“A very good whole picture view of TDD and mocks”
“Interaction and explanation of course materials particularly through the exercises.”
Labels: jmock, junit4, news, training
16 October 2007
XpDay London 19/20 November
01 April 2007
Announcing the commons.testing and commons.mocking APIs
For many years years JUnit was the only framework that Java programmers could use for writing tests. However, Java now has a plethora of test frameworks to choose from, JUnit 3, JUnit 4 and TestNG being the three most popular. Likewise for mock objects developers can choose between jMock 1, jMock 2 or EasyMock.
This variety is a problem if you need to run tests that have been written for different frameworks or write tests that need to be run in different frameworks.
To solve this we will soon release two new projects, commons.testing and commons.mocking, which will provide a common, framework-agnostic API for writing tests and using mock objects. Developers will be able to write to a single API and then select a test framework and mock object library to execute the tests at runtime by annotating their tests with the commons.testing annotations, writing a few dozen lines of XML configuration, setting system property and calling the CommonsTestingDOMConfigurator in each test fixture set-up. The commons.testing and commons.mocking frameworks will run be able to run the tests with JUnit 3, JUnit 4 or TestNG and, if you use mock objects, jMock 1, jMock 2 or EasyMock, with no change to the test code at all! The APIs are extensible: by writing to the commons.testing SPI you can add support for more testing or mocking frameworks.
Furthermore, commons.testing can run tests that are defined entirely by XML configuration files instead of complex Java code. This will enable IT departments to greatly reduce the cost of pair programming and test driven development by having lower-cost, non-technical staff author the test cases that specify what the developers must implement in Java.
Watch this space for further annnouncements...
Update: Looks like similar things are happening in the .Net world. See this announcement of an Enterprise Mocking Block.To the person who posted a comment, we have to admit that this was an April Fools proposal
28 March 2007
jMock 2.0.0 RC1 released
23 January 2007
Cutting back the noise
public interface BlogWriter
public List blogEntriesFor(Date date);
public Reference updateBlogEntry(Blog blog, Entry entry)
looks like this
expects(new InAnyOrder() {{
allowing(mockBlogWriter).blogEntriesFor(aDate); will(returnValue(aListOfEntries));
one(mockBlogWriter).updateBlogEntry(aBlog, anEntry); will(returnValue(aReference));
}})
The details of how this works are left as an exercise for the reader, but it means that the test is expecting one call to updateBlogEntry with the given arguments and that we've stubbed blogEntriesFor to return a list of entries.
Using the original signature (as users of easymock have been telling us for ages) is really convenient when working with a refactoring IDE. Rename the method and the tests will change too. But I miss the brevity we could achieve with our old jMock approach. If I have a method I want to stub, I just want it to return a value whenever it's called, I could write
expects(new InAnyOrder() {{
allowing(mockBlogWriter).updateBlogEntry(aBlog, anEntry); will(returnValue(aReference));
}})
This will only respond if the arguments equal the objects aBlog and anEntry, which is too restrictive. More important, it's misleading because those arguments are not important in this particular test. I just want the value returned so I can get to the interesting stuff later in the test, but I haven't clearly expressed that. I can relax the constraints on the stub (as best as we can manage within the Java type system)
expects(new InAnyOrder() {{
allowing(mockBlogWriter).updateBlogEntry(with(anything()), with(anything());
will(returnValue(aReference));
}})
This is not bad, considering, but still rather noisy for a supporting line of code.
I'm emotionally attached to the terseness of
allowing(mockBlogWriter).method("updateBlogEntry"); will(returnValue(aReference));
(which is the jMock2 version of our jMock1 syntax). This says just what I need and no more.26 December 2006
Mock Objects is a Technique, Not a Technology
George Malamidis recently proposed an alternative to mock objects in Groovy. Instead of using mock objects you can just use Groovy's Expando class to make an object that behaves like another type and checks that it is being invoked as expected.
But... that is a mock object!
Mock objects are not a specific technology, such as jMock or EasyMock they are a technique for the test-driven development of object-oriented code that follows a Tell, Don't Ask design style.
You can write mock objects with a framework, by using the reflection and metaprogramming facilities of a dynamic language, by coding everything by hand, or by generating the code at compile time. Whatever floats your boat.
However, faking out the mocked type is only a small part of what a mock object framework like jMock does. In fact, of the 2487 lines of code that make up jMock 2 only 34 are required to perform what we whimsically call "imposterisation". The remainder provide syntactic sugar to ensure the test code clearly expresses the intent of the test, let the programmer precisely specify the expected interactions between objects and generate clear diagnostics when tests fail. This functionality is vital if tests are to be helpful during the ongoing development of the code.
Labels: domain-specific-language, explanation, jmock
© The authors
