Tim Scott's Blog

October 8, 2010

Goodbye ShouldIt, Hello Should Assertion Library

Filed under: Test Driven Development, Unit Testing — Tim Scott @ 7:00 pm

First There Was ShouldIt

Almost a year and a half ago I created ShouldIt.   Soon after I added a fluent API.  My goal was to create a test assertion library that would be portable across all major test frameworks.  This would allow me to move from project to project using the same nice test assertions without the sick feeling I was getting from copy-paste reuse.  So I created the API, sprinkled in a little MEF, stirred, and ShouldIt was born.  It felt really good.

My joy was dampened however by one nagging issue.  Although ShouldIt plugged nicely into any framework I might ever use, it carried with it a binary dependency to some particular version of each testing framework.  This made it really hard to distribute, and thus hard to achieve any kind of adoption.  This is probably why Eric Hexter yawned when I told him about ShouldIt.  He went looking for a better way.

Then Came Should

Recently he found it, and created Should Assertion Library (or “Should” for short) .  Whereas ShouldIt leveraged the assertion machinery of whatever test runner you might be using, Eric created a library with it’s own machinery, thus completely breaking any dependence on a testing framework.  On a side note, I had briefly considered doing this myself with ShouldIt.  I was cured of this notion by perusing the assertion source code in NUnit.  It is, uh, non-trivial.  So how did Eric pull it off?  Is he a more talented and dedicated programmer than I am?  Probably yes, but he did not create it either.  Rather, he forked the assertion machinery of xUnit (with the blessings of the xUnit folks).  Brilliant!

They Get Married

When I saw Should Assertion Library I knew immediately that this was the way to go.  My only complaint was that ItUsedVeryLongPascalCaseNamedAssertionMethods.  Okay, you either love the fluent style of assertions or you hate it.  I love it, and I refuse to go back.  So I decided to see how hard it would be to port ShouldIt’s fluent API bits into Eric’s project.  It turned out to be very easy, so I suggested to Eric that Should Assertion Library might support two styles: fluent and long name.  He agreed, and very soon the Should.Fluent assembly was created.

More: Getting Started With Should Assertion Library.

About these ads

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

The Shocking Blue Green Theme Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: