Agree with everything you said. If you are using behaves_like, there’s a very good chance your class is doing too much; in most cases I wouldn’t encourage it’s use for this exact reason.

In FNH’s case, ClassMap is doing too much, but as the public API that’s it’s job; no matter how I slice it up underneath, ClassMap is always going to have to expose all these methods and thus always need testing. I could compose the ClassMap from various smaller classes and test those individually, but in the end I’d still need to test everything on ClassMap, because that’s what the public uses. So it’s specs galore no matter how I slice it.

Thanks again for MSpec, keep up the good work.

It sounds like you’ve got a good use case for the feature. It also sounds like you understand the tradeoffs. That’s all I was really trying to point out. The feature is still there to be used, but people should understand the downsides. I did not say never, nor would I ever

Another thing to consider when being tempted to use this feature is that maybe this behavior should be broken into something separate that is testable once. It could be an indication that your class is doing too much and it’s time for composition rather than inheritance or some other refactoring. It doesn’t seem like this applies to your scenario, I just wanted to point that out as well–another thing to be aware of.

I’m glad you’re enjoying MSpec and the behaves like feature, thanks for sharing your experiences.

As for DRY in tests, well, never is a strong word (although I don’t think you actually said never, but it was implied). It’s all about trade-offs. Readability over maintainability.

Lets take an example that sparked this post. Fluent NHibernate exposes a Map method on ClassMap for mapping properties, this method is also available on the following: Components, DynamicComponents, CompositeElements, Subclasses, JoinedSubclasses, Joins, and probably others that I’m forgetting. I’ve got a few specs that cover the particular behaviour that method exposes, those specs are then repeated for each of those classes I just listed; technically they share the same implementation, but that’s an assumption that shouldn’t be made in my specs.

Assuming I’ve got 5 specs for the Map method, that’s 35 specs for those classes listed. If I add a new piece of functionality that is spread across the many classes like Map is, I have to go through and create another 35+ specs; if I create another class similar to ClassMap, I have to recreate those 35 specs for the new implementation. Take that experience and multiply it by the 30+ methods and properties we expose on each of our classes, and you’ve got some serious spec explosion and a pending maintenance nightmare.

In that scenario I’m much more willing to sacrifice a bit of readability in my specifications (and after all, it only affects the _code_, not the spec output) for the simplification of testing any additions/modifications that may be made to the interface. Without this functionality MSpec would be just as inadequate as any of the other testing frameworks, I’m happy it’s in there.

One of the biggest goals of mspec and context/spec in general is to make the tests easily scannable. Behaviors breaks this. It plays to our (being geeks) need to apply tools and methods we know without considering context.

DRY does *not* apply to tests the same way it applies to code. DRYing up your tests is local optimization at its finest. By doing it, you reduce the lines of code but you also reduce the ease of understanding and ability to scan the test files. Don’t get me wrong, some cruft still should be abstracted/hidden, but the *core* of your specs is the specifications themselves. Behaviors hide those behind another class making full understanding from the code an extremely jarring experience.

Use with care.

I really like how behaviours can keep our code DRY, but I have a few reservations regarding the API – primarily that the Behaves_like field has/needs no value.

I’ve written up my thoughts on my blog:
http://craigcav.wordpress.com/2010/01/27/behaviours-in-mspec/

Craig

It’s a great feature, and I’m glad it’s there. It’s potentially open for abuse, but as are most great features.

Referring to your tweet, that post totally makes sense!

Let me explain one technical detail: As you stated above the behavior specifications (VehicleThatHasBeenStartedBehaviors’ It fields) get injected into the respective context. From the console/TD.NET/HTML report you won’t be able to tell that “should have a running engine” came from a behavior, these are unaware of behaviors.
The only place that is really aware of behavior specifications is the ReSharper runner that will show a sub-tree for each behavior that was injected into a context.

Alex