xUnit Introduction
Start course

Test-Driven Development (TDD) is a discipline that helps to create error-free, quality code, and drives productivity by reducing and eliminating errors as well as providing many other benefits.

This entry-level training course is designed to bring you quickly up to speed with the basic features and processes involved in performing C# based test-driven development using xUnit. It covers the key principles and practices of test-driven development, which you can then utilize within your own software engineering projects.

In this course, you'll be guided through an end-to-end sample project in which we use test-driven development to build, test, and package a .NET Core 3.1 C# based library that will provide an API to convert Bitcoins into foreign currency.

If you have any feedback relating to this course, please contact us at

Learning Objectives

  • Understand the fundamentals of TDD and xUnit
  • Use TDD to build, test, and package a .NET Core 3.1 C# based library
  • Perform TDD by performing Red-Green-Refactor iterations
  • Learn how to use TDD to build, test, and package a .NET Core 3.1 C# based library
  • Learn how to create unit tests using the xUnit testing framework

Intended Audience

  • Software developers interested in using TDD to build .NET Core applications using C#


To get the most out of this course, you should have a basic understanding of .NET Core and the C# programming language, as well as software development and the software development life cycle (SDLC).



Welcome back. In this lesson, I'll provide you with a quick introduction to xUnit, which is a super easy to use.Net focused unit testing framework. I'll be using xUnit later on in the provided test-driven development unit used in demonstrations.

I'll cover off the basics of installing xUnit in writing and executing xUnit best tips For starters, let's take a quick look at how you would go about setting up a brand new .Net core project. Pre-configured with the xUnit library available, thereby making the project really to contain xUnit based unit test.

For this part of the lesson, I'll use the example of a simple calculator class that provides a method which sums two numbers to give. When it comes to installation or project setup it says suppose we were running the following command with a new terminal.

This command will establish a new .Net core project which is set up to host each unit test classes. The -o parameter represents the name of the project, in this case calculator. Tests. The -- framework informs the project provisioning process that we are using the .Net core 3.1 framework. When you run this command, a new .Net C# project file will be generated containing the following configuration.

Here, we can see that the command has kindly configured in both the xUnit library used for creating xUnit unit test together with the xUnit test runner which enables us to execute all of our unit test using the .Net test command Interestingly, the .Net new xUnit command has sneaked done the MES test unit testing framework not required if we're just writing xUnit tests.

Finally, it also configures a fourth library. That being the bottom one, which is used to generate code coverage data reports which we'll leverage later on in the demonstrations Importantly, the final piece of the puzzle when setting up a new xUnit based unit testing project is to include a project reference to the project that is actually under test. With this in place, your unit is can then reference in, use the types declared within the project under test thereby exercising and testing the behaviors of the various types declared within their project.

Once a xUnit unit testing project has been established we can simply add new test classes too. And this xUnit unit test example we can see the following code paths which make up the unit test. They're using xUnit statement near the top imports the xUnit library, and provides us with the xUnit types fact and underscore.

Fact as an attribute type that is used to market a method is being a test method at runtime. The test runner will know to execute any and all methods marked this way. Facts are tests, which are always true. They test invariant conditions.

Later on, you'll also hear about an alternative form of marking methods for tests using the theory attribute. For now, I'll just state for comparison, that theories are tests which are only true for a particular set of data Internally, the add underscore two numbers underscore gives correct result test method is composed using the arrange at underscore pattern, which as we already know is a standard and best practice pattern for writing tests. Mostly this is how unit test are developed and structured using xUnit.

As you can see, writing xUnit is simple. xUnit provides a few other times they can be used to structure your unit test in other variations. When it comes to actually a suiting conditions about your code, and more importantly the run-time behavior of it, xUnit provides numerous types of assertions including those that can assert failure outcomes or runtime exceptions, et cetera.

The following list provided here highlights many of the different xUnit decision options. Note, this is not a comprehensive list but rather a list of the more commonly used ones. Most, if not all of these assertions are self-explanatory and terms of the names, et cetera. For the full list of the same methods, either consult the in built intelligences from within your Ida is you go about coding your unit test specifically on the assert type when using it or consider reviewing the xUnit online documentation found here.

The other key kind of unit test that can be created within an xUnit is the theory based unit test. Using the theory attribute type together with multiple end line data attribute types allows you to structure a unit test within associated set of inputs and expectations for those inputs.

As early I mentioned, theories are tests which are only true for a particular set of data. In this example, the test method signature has been updated and now takes three input parameters. The first two of which, other data inputs being tested with the third being the expected result xUnit calls the method once for each of the declared inline data attributes tagged on the method the data configured within the inline data attribute is passed into the test method when executed thus makes it clean and concise to construct as they operate on a set of related data.

Although discouraged, xUnit provides the ability to configure setup and tear down flows to run immediately before and after each and every test. Setup code allows you to setup and perform initializations of objects and all prepared tests, et cetera.

Setup code is placed inside the test classes constructor, the xUnit framework when called upon to run your unit test will call a constructor for each declared test method within the test class. At the other end of the test run xUnit can be instructed to perform tear downs. This is accomplished by configuring the test class to inherit from the system.IDisposable Interface, and then providing an implementation for the dispose method. The dispose method will be called after each and every test method declared within the test class.

Okay. That completes this lesson on the xUnit framework. In this lesson you learned about what xUnit is. You learn how to create and configure an xUnit, enabled unit testing project. You learned about how easy it is to write units test using the fact and theory xUnit provided attributes. You learned about the various assertions that can be called upon to test the run-time behavior of your classes. And finally, you learned that xUnit provides setup and tear down options for writing unit test if required.

Go ahead now and close this lesson and I'll see you shortly in the next one.

About the Author
Learning Paths

Jeremy is a Content Lead Architect and DevOps SME here at Cloud Academy where he specializes in developing DevOps technical training documentation.

He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 25+ years. In recent times, Jeremy has been focused on DevOps, Cloud (AWS, Azure, GCP), Security, Kubernetes, and Machine Learning.

Jeremy holds professional certifications for AWS, Azure, GCP, Terraform, Kubernetes (CKA, CKAD, CKS).