Mock Objects

This time a posting from Mark Seemann has raised a slew of comments.

One of them is a note from Colin Jack about the annoyance of producing interface/implementation pairs all the time. My first response is that that sounds to me a bit like a problem with style. Maybe it's just wordplay, but usually I don't extract interfaces from classes, I implement interfaces that I've already discovered in some previous test.

My second response is to wonder how much this is a tools issue. I don't believe there's anything in the .Net world that yet matches the responsiveness of the usual Java IDE's. It makes a difference as to what's plausible. I remember the huge shift in perception when first VisualAge for Java and then JetBrains' Idea came out. In retrospect, I always spent more on time on rework than many people I worked with ¹ but it sure took a lot more time in emacs (and I was pretty good at it), even if I was working in a better language.

---

1) which is not to say who was right, I'm just wired that way...

Labels: design, ide, testability

Inspired by TestDox I discovered a trick when using Eclipse 3.2.2 with JUnit4. If you lay out your test methods like this

When you fold the test class, it looks like this

If you've written your method names appropriately, the result is a compact description of the features of the class under test.

Labels: eclipse, ide, junit4, tip