assertions on domain objects

In assertions on domain objects Alan Francis posts in some puzzlement on the coding practices of Chris Stevenson: In order to reduce duplication in his JUnit tests, Chris apparently now has JUnit assertions in methods on his domain objects.

Unless I’m very much mistaken, this means that those domain classes have a dependency on JUnit, which in turn means that JUnit must be on the classpath wherever his application is deployed. Now while that may be only a slight headache for deployments such as in-house or web-based projects, it would be a complete no-no for a shrink-wrapped or off-the-shelf product of any kind.

Looking at the examples on Alan’s blog, I do like the look and feel of Chris’s resulting code. But that dependency makes it hard to swallow, so I guess I’d vote for Alan’s own style as being a reasonable compromise.

On reflection, is this maybe a problem of the language? In Ruby, for example, the test suite can add shouldXXX() methods to class Object, and these methods won’t appear in deployed production code. The rSpec framework does this, for example. Yet another reason to switch to Ruby, if you haven’t already done so…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s