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.