This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Mock Objects at ot2004 Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general. Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Cincom Smalltalk Blog - Smalltalk with Rants

I've had people telling me for quite some time that I should be looking at Mock Objects - so I've decided to attend a morning session on the subject. I've done ad hoc mocks, of course; most Smalltalkers probably have. This talk is more specific though - there's an example to walk through

The example is a stock trading application. The presenters are using a TDD approach and a Mock framework for Java. One thing that falls out of this is that the Mock framework represents a code specification - an outline of the interfaces and API's that will need to be created. Interesting side point on the mock framework - it's a Java port of a Python port of a Ruby framework - both of which, according to the presenters, are simpler. Always the way...

One interesting fallout - more of TDD than of mocks, but having convenient mocks makes it easier - is that code smell is easier to detect early, when refactoring will be simpler.

Misconceptions about Mocks

• Mocks are just stubs
• Mocks should only be used at system boundaries
• They advise using the real (database, etc) at system bounds instead. Use mocks for internal systems (i.e., those which you have control over). So you would mock your interface to an external system rather than the external system.
• Gather state during the test for asserting at the end
• Testing with mocks duplicates code
• Mocks inhibit refactoring due to many tests failing together (countered by the example)
• Mocks should contain behavior that simulates the runtime environment
• Mocks should be a specification for what happens, not a specification for how it happens

Assertions - Lessons about Design

• Need-Driven, top-down design leads to a leaner system with higher business value
• ed - What?
• Create interfaces for the services an object requires, not to represent all the features an object provides
• Only mock objects you can change
• test how object references are passed around the system
• Getters are evil, setters less evil
• ed What?
• Visit, don't iterate
• ed - A Java issue :)
• Too many mocks?
• object is doing to much - refactor
• Cannot introduce a mock to an object?
• See above :)

Questions from the audience

• Where does architecture fit in?
• What about creation of objects