James Gregory's Blog - All Comments

Git Resources – Blue Cog Blog

Git Resources – Blue Cog Blog — Tue, 02 Mar 2010 17:27:32 GMT

Pingback from Git Resources – Blue Cog Blog

re: Git E-VAN recording

Rusty — Fri, 19 Feb 2010 23:13:22 GMT

Great git intro. Enjoyed the goats, too!

.Net Pulse 2/15/2010

Cadred (dotNET) — Mon, 15 Feb 2010 17:41:29 GMT

.Net Pulse 2/15/2010

re: Git: Remotes, contributions, and the letter N

James Gregory — Mon, 15 Feb 2010 10:30:24 GMT

Well spotted! Fixed, thanks.

re: Git: Remotes, contributions, and the letter N

Professor Rotwang — Mon, 15 Feb 2010 10:21:31 GMT

Nice article - I like the V and N aide memoires. One minor point, you've tagged this as "git github" so it doesn't appear under "git" alone. Since this isn't really github specific - we use the same process for our own repos on a private central server - I wonder if this was a mistake.

re: Behaviours in MSpec

James Gregory — Thu, 28 Jan 2010 09:06:51 GMT

Sorry, jumped on you a bit there. :)

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.

re: Behaviours in MSpec

Aaron Jensen — Thu, 28 Jan 2010 03:04:30 GMT

Hi James,

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.

re: Behaviours in MSpec

James Gregory — Wed, 27 Jan 2010 23:30:04 GMT

I agree that you should use with care, definitely.

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.

re: Behaviours in MSpec

Aaron Jensen — Wed, 27 Jan 2010 23:13:13 GMT

Behaviors are actually not documented or mentioned on my blog on purpose. I figured someone would find it eventually, but I didn’t want to promote it. I actually considered removing it.

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.

re: Behaviours in MSpec

CraigCav — Wed, 27 Jan 2010 13:43:08 GMT

James,

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:

craigcav.wordpress.com/.../behaviours-in-mspec

Craig

Behaviours in MSpec « Cav’s Weblog

Behaviours in MSpec « Cav’s Weblog — Wed, 27 Jan 2010 13:31:47 GMT

Pingback from Behaviours in MSpec « Cav’s Weblog

re: Behaviours in MSpec

James Gregory — Fri, 22 Jan 2010 11:04:09 GMT

@alex: That makes sense. I wouldn't really want the behaviours to be exposed in the reports, as it's just clouding the output; however, it is quite a nice touch in the R# runner. As you can (and I frequently do) use the R# runner to navigate around your specs, hiding away that certain ones are from a behaviour could easily lead to confusion.

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

re: Behaviours in MSpec

Alexander Groß — Fri, 22 Jan 2010 10:44:40 GMT

James,

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

James Gregory - Behaviours in MSpec

James Gregory - Behaviours in MSpec — Fri, 22 Jan 2010 10:25:10 GMT

Pingback from James Gregory - Behaviours in MSpec

James Gregory - Git’s guts: Merging and rebasing

James Gregory - Git’s guts: Merging and rebasing — Fri, 22 Jan 2010 10:15:20 GMT

Pingback from James Gregory - Git’s guts: Merging and rebasing