Shouldly is an open source library that aims to improve the assert phase of tests; it does this in two ways. The first is offering a more “fluent like” syntax that for the most part leverages extension methods and obviates the need to keep remembering which parameter is the expected or actual as with regular Assert.Xxxx(1,2) methods. The second benefit manifests itself when tests fail; Shouldly outputs more readable, easily digestible test failure messages.
Failure Message Examples
The following are three failure messages from tests that don’t use Shouldly and instead use the assert methods bundled with the testing framework (NUnit, xUnit.net, etc):
- “Expected: 9 But was: 5”
- “Assert.NotNull() Failure”
- “Not found: Monday In value: List<String> ["Tuesday", "Wednesday", "Thursday"]”
In each of the preceding failure messages, there is not much helpful context in the failure message.
Compare the above to the following equivalent Shouldly failure messages:
- “schedule.TotalHours should be 9 but was 5”
- “schedule.Title should not be null or empty”
- “schedule.Days should contain "Monday" but does not”
Notice the additional context in these failure messages. In each case here, Shouldly is telling us the name of the variable in the test code (“schedule”) and the name of the property/field being asserted (e.g. “Total Hours”).
Test Code Readability
For the preceding failure messages, the following test assert code is used (notice the use of the Shouldly extension methods):
- schedule.TotalHours.ShouldBe(9);
- schedule.Title.ShouldNotBeNullOrEmpty();
- schedule.Days.ShouldContain("Monday");
In these examples there is no mistaking an actual value parameter for an expected value parameter and the test code reads more “fluently” as well.
To find out more about Shouldly check out the project on GitHub, install via NuGet, or checkout my Better Unit Test Assertions with Shouldly Pluralsight course.
You can start watching with a Pluralsight free trial.
SHARE: