Mike’s post last week about dynamic mock objects neatly coincided with new research into testing strategies. At first I couldn’t quite understand how the things were working. Mike’s example was fairly straightforward, but for some reason the relationship between the controller and the object you actually use in your tests didn’t click for a while. Maybe it’s because this functionality is merged into a single object in a Perl implementation (fun with AUTOLOAD…), I dunno. Maybe pair programming would have been useful for this, another set of eyes and all.
Anyway, eventually it clicked. Once I started writing a few tests -- using EasyMock instead of the dynamic implementation in the MockObjects framework -- it seemed very klunky at first. But it really forces you to decompose your interfaces and respect the authority of the Law of Demeter. I'm still playing, but it's starting to feel more natural.
I still need to write up how we translate scenarioed objects and diffs from XML hierarchies into an HSQL database for testing.