By the end of this course, you'll know how to use the open source Shouldly library to get more meaningful and easily-debuggable test failure messages and how Shouldly helps to improve the readability of unit tests due to the more "fluent-like" test code.
Introducing Shouldly Hi. I'm Jason Roberts from Pluralsight. Welcome to this course on Better Unit Test Assertions with Shouldly. In this course we're going to learn how the Shouldly Open Source Library helps us to write better assertions in our tests by giving us better failure messages and also improving the readability of our test code. In this first module we're going to start off by looking at some of the reasons why we might want to use Shouldly, so this includes the better test failure messages that Shouldly gives us, and also the improved readability of our test code. We'll learn about some of the additional features that Shouldly provides over and above basic asserts and we'll learn how to get started with Shouldly in both NUnit and Fixie based testing solutions. Finally, we'll see how we can gradually introduce Shouldly to an existing unit test project while starting to refactor individual tests rather than having to go and refactor the whole test suite.
Asserting Different Types of Test Results Hi. Welcome back. In the previous module we saw a glimpse of how we use the Shouldly assert methods. In this module we're going to dig into more detail and see how we can use Shouldly asserts against different types of test results. We're going to start off by seeing how we can assert for numeric equality and also numeric inequality and we'll see that when we're working with floating point values we can optionally specify a tolerance to account for any inaccuracies in the floating point value. We'll also learn how we can assert against string values and how we can optionally tell Shouldly to ignore any case differences. We'll also see how we can assert against the actual contents of strings, so for example, checking a string contains a substring or matches a regular expression. We'll learn how we can assert against null and Boolean values and how we can assert against the values of DateTime objects and optionally, as with floating point values, we can also specify a tolerance as a time span here. We'll learn how to assert that a value falls within an expected range, so for example, a number being greater than or equal to an expected value or falling within a specific upper end lower bound. We'll learn how to assert that the expected items exist within a collection and also how to do things, such as assert that the collection is not empty. Finally, we'll see how we can assert against dictionaries, and how we can write asserts to check the keys and values within a dictionary, so let's get started by looking at numeric equality.
Using the Additional Assertion Features of Shouldly Hi. Welcome back to this final module. In this module we're going to be learning some of the additional assertion features of Shouldly over and above the asserting of values that we learned about in the previous module. In this module we're going to start off by seeing how we can assert that exceptions are thrown by our production code when we expect them to be, so we'll learn how to assert that the exception is thrown, and we'll also see how we can go and make additional asserts against the properties of the thrown exception. Next we'll learn how we can get Shouldly to execute our code and check it executes in a timely fashion. If the code fails to execute in the expected amount of time our test will fail. We'll learn how we can use Shouldly to check that dynamic objects have the correct properties. We can use Shouldly to give us the information of all of the failing asserts in one go rather than having to keep fixing one assert, running the test again, and then moving onto the next assert. We'll learn how we can assert that objects are of the correct type and finally we'll see how we can specify custom assert messages when we're using Shouldly.