Mock Objects

There was a brief discussion on the JMock mailing list recently where we helped out a new user. In the process, we noticed that he was mocking Java Set, which we tend to avoid, because it's not a type that we own—it's not in the domain of the problem we're trying to solve. The way I put it was,

We see a lot of people using, for example, List<House> when what they actually mean is Street. We try to use types we own that represent concepts in the domain, rather than built-in or library types which we keep for implementing these domain types. If the domain types are defined in terms of roles, then they're often appropriate for mocking.

Isiah followed up with an old post of his own.

I think we have a satisfied customer:

Thank you Steve and Isiah, I think I just took a large step in the world of TDD.

It's nice when that happens...

Labels: design, explanation

Steve Freeman at 17:07  permalink 0 comments links to this post

I'm in a communcation quandry. I'm either missing a point or can't explain something, or both.

I really don't like mocking classes, except where I'm trying to cut a seam in some legacy code, but other people disagree.

Can someone post or send me an example of code where interaction-testing with interfaces doesn't work well? Thanks

Contact me at mockexample theAtSymbol m3p theDotCharacter co anotherDotHere uk

Labels: design, explanation, testability

Steve Freeman at 14:10  permalink 3 comments links to this post

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

Nat Pryce at 22:49  permalink 2 comments links to this post