xUnit.net 2 is a modern, extensible, multi-platform testing framework for .NET. Currently being used by the Microsoft ASP.Net 5 development team, xUnit.net allows the creation, execution, and customization of automated tests such as unit, integration, and, when combined with other libraries, even automated UI tests. In this course, you'll learn about the features of xUnit.net 2 and learn how to write and run tests in Visual Studio Test Explorer, ReSharper, and from the command line. You'll learn to write test asserts against different types of objects, including how to assert against floating point values, collections, and how to check that exceptions are thrown when expected. The course also covers how to customize the test execution life cycle and how data driven tests can reduce the amount of test code that needs to be written and help reduce test maintenance costs.
Introducing xUnit.net Hi, I'm Jason Roberts from Pluralsight. Welcome to this course on Testing. NET Code with xUnit. net2. In this first module, we're going to be getting an introduction to xUnit. net. And we're going to start off by looking at the design goals and the features and adoption of xUnit. net's version 2. We'll look at the types of. NET platforms we can test when we're using xUnit. net2. We'll take a brief look at the adoption and the usage of xUnit. net. And then we'll get an overview of the NuGet packages that comprise the xUnit. net2 Framework. We'll perform a quick demo of how we get started in Visual Studio with xUnit. net2, and we'll write a simple test, and we'll also see how we can use xUnit. net2 to test Windows Universal Apps.
Asserting Test Results Hi, welcome back to module two. In this module, we're going to dig into how we can use the xUnit Asserts to assert that test results are as expected. So in this module, we're going to start by getting a quick overview of the Arrange, Act, and Assert phases of tests, and we're going to see that the xUnit Assert methods apply in the assert phase of our test. Next we're going to start digging in to details on the individual Assert methods themselves, so we're going to start off by seeing how we can assert numeric and string test results, and we'll also see when we're dealing with floating point double numeric types how we can optionally supply a tolerance. We're going to see how we can assert that a value is null or not null or true or false, and then we'll learn how we can assert on collection results. So, for example, to see if a specific item exists within the collection. We'll learn how we can assert that a value is within an expected range rather than being an exact match and also how we can assert that exceptions are thrown when we expect them to be. We'll learn that when we're working with objects, we can assert that a variable is of a given object type, and we can do this in a strict way on the exact type, or allow the assert to pass if it's also a derived type. If we're working with the INotifyPropertyChanged interface, for example, in a WPF or a Windows Universal App, we can see how we can assert that the PropertyChanged event is raised correctly when we execute certain parts of a test. So, for example, in a view model. So let's start off by looking at the Arrange, Act, Assert phases.
Controlling the Test Execution Lifecycle Hi, welcome back. In this module we're going to learn more about how xUnit executes our tests, and we're going to see how we can go about controlling this test execution lifecycle. So in this module, we're going to start off by seeing how we can group our tests into arbitrary categories, and once we've grouped our tests into our categories, we'll see how we can execute only those specific categories in Visual Studio. If we need to write diagnostic test output during our test execution, we'll see how we can do this in xUnit too. We'll then learn if we have common setup and clean-up code in each of our test methods in our test class, how rather than having this code duplication, we can instead refactor this and reuse it in one common place. Next we'll learn how we can run setup and clean-up code once per test class or once per multiple classes. So rather than running setup code before each test executes and after each test executes, we'll learn how to write code that executes before the first test executes, and after all of the tests have finished executing. If we want this shared code to run before executing multiple test classes, we'll also learn how to do this. Next we'll learn how xUnit. net handles parallel test execution, and we'll learn how we can configure this parallel execution. And finally, if we need to customize the execution order of our test classes, we'll learn how to do this, and we'll learn that by default xUnit. net considers each test class a separate test collection, and by default the execution order of our test collections is random. So let's get started seeing how we can group tests into our own categories.
Reduced Code and Improved Maintainability with Data Driven Tests Hi, welcome back. There's always pressure to deliver the next feature or the next release, so anything we can do to reduce the amount of code that we have to write whilst maintaining the amount of testing that we're doing, is going to be a benefit. In this module, we're going to see how we can reduce the amount of code we have to write and at the same time improve maintainability by using data driven tests. So in this module, we're going to start off by looking at an overview of data driven tests in xUnit. net, and also some of the benefits we can get from using data driven tests. We'll start off by seeing how we can take multiple test methods that contain a lot of duplication, and instead refactor them into one single test method that gets executed multiple times, each time using different test data. Next we'll see how we can take our test data and share it across multiple test methods, and even multiple test classes. We'll learn that in addition to using test data that's compiled into the test assembly itself, we can also get our test data from external sources. So this could be a database, a web service, or a local file, and we'll see a demo how we can load in test data cases from an external CSV file. We'll then see how we can take this concept of reading from a CSV file and actually create a custom data source attribute that allows us to quickly read in CSV data for any test method. Finally, we'll get a brief overview of how we can use xUnit. net with the AutoFixture open source library, and how this can further help us to reduce the amount of test code that we have to write.
Migrating to xUnit.net from NUnit and MSTest Hi, welcome back to the final module of this course. In this module, we'll be getting a brief overview of what's required to migrate from NUnit and MSTest. So we're going to start off with a test project that's using NUnit, and we'll go and refactor this to use xUnit. net instead. We'll then go and do the same thing for an MSTest project, and in both of these instances, we need to change the attributes, so we're going to be changing from either the NUnit or the MSTest attributes over to the xUnit. net attributes, and then we need to go and change the assert methods to use xUnit. net asserts.