Ready to set up your first test case?
First let's put some vocabulary in context:
The preconditions that you need to have in place to run a test and expect a particular outcome is called the text fixture (or context).
A set of tests that all share the same fixture is called a test suite.
A test runner is a program that runs implemented tests using a specific framework and reports the test results.
Now let's choose a framework:
NUnit
You can choose from several frameworks; however, the most widely used in the .NET world has historically been NUnit, which introduced its own set of libraries and UI tooling for running and integrating tests making unit tests easy to implement. As a downside, it required some additional configuration and special add-ons to make it easier to use inside Visual Studio.
xUnit
More recently, the xUnit framework is becoming the de facto framework used across .NET and .NET Core tooling. This open source, community-based .NET framework for testing applications serves to standardize the existing frameworks and test-driven approaches. Written by the original inventor of NUnit v2, it covers traditional unit testing in C#, F#, VB.NET and other .NET languages and platforms, including ASP.NET Core, Web API, Xamarin, and more.
Furthermore, xUnit.net allows you to work in a cross-platform way with TDD and BDD approaches and with tools like ReSharper, CodeRush, TestDriven.NET, and Xamarin.
xUnit is part of the .NET Foundation. It is actively used and supported by Visual Studio and included in default installation, templates, and tooling for creating, maintaining, debugging, and executing test suites.
Creating an xUnit test project
xUnit projects consist of a specialized project that contains references to your code that can be executed under an isolated test environment and under specific scenarios. Generally, you can create an xUnit project on your own or by using a Visual Studio template which ideally, should meet the following:
Creates the folder structure of your xUnit project
Contains the necessary xUnit assembly version
Creates one or more xUnit test class(es) (multiple classes together are called a test suite)
By having the basic structure for xUnit development, the next step is to have your unit tests run against your code. With the xUnit project in place, you can add a reference to your project which generally consists of a class library linked to your unit test project. By right-clicking your project or through the "Add references" section, you can link your unit test project and set up the dependencies from your code.
Understanding the xUnit class structure
The are three main components of an xUnit class:
The xUnit references in your code
The xUnit fact decorations with the [Fact] code attribute
Your test code
With these elements in place, you can start declarations of your classes, interfaces, and main routines under the scope of the unit tests.
In a [Fact] decorated method, you can ensure your code behaves as expected and assert against some specific values depending on the outputs or the state of your components in your code, like functions or properties.
In general, it is a good practice to have as many assertions as possible, depending on the expected results from your code.
You may sometimes find code that seems duplicated, which is normal, and as always you can improve your test code later or apply some code smells to improve the maintainability of your test code.
Additionally, xUnit incorporates a set of commonly used classes and methods. We will explore these later in this course as they will help you do the most common tasks of unit tests, like code assertions and handling the lifecycle of unit tests.
Running multiple test cases inside Visual Studio
The Visual Studio test runner is extremely useful when developing unit tests and is fully integrated with xUnit decorations. You can find it in the Test-\>Windows-\>Test Explorer menu in Visual Studio.
All methods marked as [Fact] in your xUnit testing class are tracked with the Test Explorer. In case you want to rename, delete, or add more [Fact] methods, they are automatically listed in the Test Explorer once you build the project. If more classes are added, they are organized by class, then by name. From Visual Studio, you can decide how they will be listed or grouped.
In case you have multiple components to be tested, you can have as many test classes as you need. You can declare and code separate classes that represent multiple test suites in your unit test project, and they can be compiled and run multiple times as you code. If your code runs successfully, your test case will be listed as GREEN. If you hit an error during the execution or run into an exception, the Test Explorer will list it in RED, indicating that it is something you might need to check, fix, and ideally make green again.
Within the Test Explorer, you can hit the Run button and execute your test cases immediately, and also debug them, place breakpoints, step over or into your code, pretty much like you were running your code from an ASP.NET application, console application, or GUI application with .NET.
Here are some recommendations for having one or more test classes (or test suites):
Consider the classes you have developed (one test suite per class is generally good).
Consider having multiple facts for a single component.
Drive your scenarios per area (accounting, human resources, etc.).
Using the command line as a test runner (MSBuild)
Most of the things you can do in Visual Studio can be done click by click, simplifying the process of building software. Alternatively, you can run your xUnit test cases outside of Visual Studio from the command line using the MSBuild tool. That is especially useful when you don't have your IDE opened or installed and want to do a quick check (sometimes known as a smoke-test) of your code in case you are working in one or more .NET and xUnit projects.
Also, your colleagues might be looking in your code, downloading it, trying it locally, and executing your tests on a daily basis.
There may be circumstances where you or your teammates can develop unit tests by using Visual Studio in addition to other IDEs, an operating systems (OS), or external tooling. For this reason, it is important to know the structure of an xUnit project in general, manually add test-cases to a test suite, and run them frequently.
The good news is that xUnit projects can be compiled and executed without the need of the Visual Studio in different environments, OS, and codebases, which makes it easy for other members of your team to take your code, introduce changes, break it into one or more xUnit projects, or simply break your test suite into smaller test classes. By doing so, the test code can be compiled locally, or in the cloud and you can check whether your code meets the scenarios that it is expected to support.
Let's recap!
Historically, NUnit has been the most popular framework for testing .NET applications.
More recently, xUnit has become the most recommended. It is supported by Microsoft open source initiatives and works with different technologies in a cross-platform way.
You can create your unit test project manually or by using an IDE like Visual Studio. This will help you understand the xUnit framework, its decorations, and the main structure of an xUnit project. You will then be able to follow along with any other IDE, OS, or development environment that will allow you to compile, run, and maintain testing codebases.
The Test Explorer in Visual Studio allows you to list, execute, and examine the status of your unit tests. This allows you to apply the red-green-refactor cycle, which will help you to keep test cases in place and codebase continuously tested.
