October 31, 2005

Brian Marick understands Mock Objects

Brian's blog entry on A thought on mocking filesystems shows that he understands the point. One of the potential risks with mock-based testing is of simply reproducing the implementation of the Code Under Test, but that only really gets in the way if you can't change the collaborators you're mocking. The point of the exercise is to discover the interfaces of collaborating objects from the point of the view of the client, the CUT. This leads to a coding style with small, focussed interfaces which might be implemented by larger classes. Each object gets just what it needs from its neighbours. Posted by stevef at October 31, 2005 10:30 PM
Comments

Small focused interfaces definitely provide more flexibility than wide interfaces, but I am finding it increasingly time-consuming and difficult to come up with good names for small focused interfaces. Do you have any tips?

Posted by: David Peterson at October 31, 2005 11:00 PM

Naming is important and sometimes tricky. Ward recommends keeping a thesaurus handy, although I find the discussion it raises more useful than the book itself. Sometimes, it helps to give a type an obviously wrong name (Thing) until you see what it does.

Have you got an example of a difficult type to name?

Posted by: Steve Freeman at November 2, 2005 12:53 AM