ShouldIt now gives you the option to use a more fluent syntax. For example, the following:
Can now be expressed as:
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.
- 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.
- 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.