Specs (BDDish) extension

[becdetat]

Extension method to add a BDDish specification syntax. Eg:

"Team should have 5 points".Spec(() => team.Points.ShouldBe(5));
"Team should be awesome".Spec(() => team.IsAwesome.ShouldBe(true));

I'm on VS2008 so I created a new solution (shouldly.sln). I don't have VS010 so I couldn't add this to the current sln, sorry!

[xerxesb]

hey ben - thanks for sending this patch!

I'm not sure though that I'm immediately comfortable putting this into Shouldly as it crosses the border from assertion tool to BDD framework, of which there are plenty of good ones.

For instance, if you're looking for a tool with similar expressive semantics, we use a project (built internally but published as open-source) called NSpec (https://github.com/nspec/NSpec , not to be confused with the OTHER nSpec ;)) but there are lots of others and Shouldly is intended to compliment all of them.

Also just IMO, in most instances when using BDD I don't find a textual description of the assertion any more helpful than having clean assertion syntax to begin with:
eg: totalAmountIncludingTax.ShouldBe(13.31) is pretty expressive enough without needing to stipulate the comment in the string. Refactoring the code just means any description string is now obsolete and requires manually changing.

The description is helpful if the reason for the assertion needs to be made clearer:
eg: specify("no tax charged on international purchases", () => totalAmountIncludingTax.ShouldBe(13.31))
but i find this situation arises fairly rarely.

That said, thanks again for helping to make Shouldly more awesome! I'm loving the fact that people want to help and extend it :)

Cheers,
Xerxes

[becdetat]

Xerces,

No worries, I understand not wanting to blur the intent of your baby.

Thanks for the pointer to NSpec, I didn't like the syntax of the other nSpec and heard something about NSpec but couldn't find it ;-). I also didn't want to drop another framework in when I can get pretty messages from Shouldly plus the BDD annontation. I was testing a DTO with 20 or so fields similar to your example so I wanted a bit more expressiveness than Shouldly could give by default.

If I keep my branch but add something else later on and give you another pull request, should I start a new branch? Is there git-fu so you wouldn't get the Shouldly.Specs extension as well? I'm very new to contributing and my git-fu is not strong ;-)

Ben

[xerxesb]

Yeah. It's all good. if you created it off the master branch that
would be easiest

Alternatively If you push up a new change on top of your specs branch
I can cherry pick the commit.

sent from my phone

On 07/08/2011, at 7:06 PM, belfryimages
reply@reply.github.com
wrote:

Xerces,

No worries, I understand not wanting to blur the intent of your baby.

Thanks for the pointer to NSpec, I didn't like the syntax of the other nSpec and heard something about NSpec but couldn't find it ;-). I also didn't want to drop another framework in when I can get pretty messages from Shouldly plus the BDD annontation. I was testing a DTO with 20 or so fields similar to your example so I wanted a bit more expressiveness than Shouldly could give by default.

If I keep my branch but add something else later on and give you another pull request, should I start a new branch? Is there git-fu so you wouldn't get the Shouldly.Specs extension as well? I'm very new to contributing and my git-fu is not strong ;-)

Ben

Reply to this email directly or view it on GitHub:
#29 (comment)