Tim Scott's Blog

July 17, 2009

ShouldIt Gets More Fluent

Filed under: C#, Test Driven Development, Unit Testing — Tim Scott @ 3:26 am

ShouldIt now gives you the option to use a more fluent syntax.  For example, the following:

result.ShouldNotBeNull();

Can now be expressed as:

result.Should().Not.Be.Null();

You can still chain asserts as before.  So this:

personList
    .ShouldCount(1)
    .ShouldContainOne(x => x.Id == exptected.Id)
    .FirstName.ShouldEqual("Jim")

Can now alternatively be expressed as:

shouldList
    .Should().Count.Exactly(1)
    .Should().Contain.One(x => x.Id == exptected.Id)
    .FirstName.Should().Equal("Jim");

The new syntax can be found in the ShouldIt.Clr.Fluent namespace in the Should.Clr assembly.

Why the new syntax?  Whether it’s more or less readable is largely a matter of taste.  For me, words separated by dots are an improvement over Pascal cased phrases.    However, the extra parentheses surely do not help. (Anyone else wish that parens were optional for calls to methods with no parameters?)  Nonetheless, I think that the new syntax has some nice advantages.

  1. Better Intellisense. With the old style, Intellisense offers a long list of every possible assertion for the target type.  It’s annoying to scroll through the list and/or type the entire word “should” plus one more letter before the list shirinks.  Using the new style, only one extension method appears at first.   As you type each new node, the list remains very small until you narrow down to the assertion that you want.   Overall I believe that this will facilitate faster and more accurate coding.
  2. More Maintainable And Extensible. The original extension methods all live together in one big fat static class.  The new code is more object oriented and spreads responsibilities over more small classes.  While this does not immediately provide any value to the user, it will make it easier to add nice features over time.

Give it a try and let me know what you think.

Advertisements

4 Comments »

  1. I don’t like the fact that you have to use parenthesis in some cases but no in others (Should().Not.Be.Null() ), plus it gets too verbose

    for me, this is pushing it too far

    but that’s just me

    Comment by Eber Irigoyen — July 17, 2009 @ 4:42 pm

  2. Eber, I agree that having parens on some nodes is not ideal. This is due to constrains of the C# language. The first node “Should()” must be an extension method. Parens are reqiured for all methods in C#. The last node must also be a method. A property must be assigned to something, which we do not want to require. We make all nodes methods, but in my opinion that would be worse.

    If parens were optional on methods with no params in C#, this trouble would disappear.

    Comment by Tim Scott — July 17, 2009 @ 4:54 pm

  3. Got to check this out. I’m not sure that i want to use ShouldIt but fluent interface implementation SHOULD be worth checking out.

    Parenthesis are optional in VB – some interesting kind of bugs might appear because of this. 🙂

    Comment by Arnis L. — August 12, 2009 @ 8:56 am

  4. […] This will install Should as a package in the current solution.  You probably want to use either the fluent API or the normal API in any given test project – but not both.  Choosing one or the other will promote a consistent practice within your team.  Obviously, I prefer the fluent API. […]

    Pingback by Getting Started With Should Assertion Library « Tim Scott's Blog — October 9, 2010 @ 7:18 pm


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

Blog at WordPress.com.

%d bloggers like this: