Visual Studio Unit Test

Posted on  by

Create a unit test project; Learning to use Test Explorer; Write your first tests; Write your first theory; Running tests against multiple target frameworks; Note: The examples were done with xUnit.net v2.4.1 and Visual Studio 2019. The version numbers, paths, and Visual Studio UI may differ for you, depending on which version you're using. This is an extension for Visual Studio 2017 and Visual Studio 2019 that extends the test functionality to allow you to create unit tests. It works for Visual Studio 2017 and Visual Studio 2019. The extension extends the built-in test generator functionality allowing developers to generate tests using xUnit.net 2.0. Trace.Write - The Visual Studio test harness will capture this and show it in the test output. Does appear in the Visual Studio Output (or Immediate) Window when debugging a unit test (but not when simply running the test without debugging). By default available in both Debug and Release builds (that is, when TRACE constant is defined). I have a unit test project in Visual Studio 2019. When I click Run All Tests, none of the tests run. I looked in the Tests output window and saw a message that says: Test project does not reference any.NET NuGet Adapter. Test discovery or execution might not work for this project.

Using .NET Framework with Visual Studio

In this article, we will demonstrate getting started with xUnit.net, showing you how to write and run your first set of unit tests.

Note: The examples were done with xUnit.net v2.4.1 and Visual Studio 2019. The version numbers, paths, and Visual Studio UI may differ for you, depending on which version you're using.

Create a unit test project

Start Visual Studio, which will bring you to the start splash screen. Under 'Get Started', click 'Create a new project'. This will bring you to the first step of the new project wizard, where you pick your project type:

In the drop down boxes, chooses your language (C#), your platform (All platforms), and your project type (Test). Scroll through the list if necessary until you find the item titled 'xUnit Test Project (.NET Core)'. Select it, then click 'Next'.

We're picking .NET Core even though we're planning to make a .NET Framework test project, because Visual Studio doesn't contain a test project template for xUnit.net for .NET Framework. We'll fix that in just a moment.

This leads you to the second part of the new project wizard:

Type a name into the 'Project name' box (like 'MyFirstUnitTests'). Click 'Create'.

After a moment, Visual Studio will launch with your newly created project.

Find the project in the Solution Explorer (it will be titled 'MyFirstUnitTests'), right click it, then click 'Edit Project File'. This will launch the text editor for your project file. It should look something like this:

We need to make one quick change: use a target framework that indicates .NET Framework support. For example, if you want to support .NET Framework 4.8, change the TargetFramework element like so:

Let's quickly review what's in this project file:

  • TargetFramework specifies the target framework for your test project. We've already changed this to net48 for .NET Framework 4.8. Later in this article, we will discuss running tests against multiple target frameworks.
  • IsPackable is here, though it is redundant (unit test projects cannot be packed by default). You can safely remove this line if you wish.
  • The xunit package brings in three child packages which include functionality that most developers want: xunit.core (the testing framework itself), xunit.assert (the library which contains the Assert class), and xunit.analyzers (which enables Roslyn analyzers to detect common issues with unit tests and xUnit.net extensibility).
  • The packages xunit.runner.visualstudio and Microsoft.NET.Test.Sdk are required for being able to run your test project inside Visual Studio as well as with dotnet test.
  • The coverlet.collector package allows collecting code coverage. If you don't intend to collect code coverage, you should remove this package reference.

A single empty unit test was also generated into UnitTest1.cs:

Let's make sure everything builds. Choose Build > Build Solution from the main menu. Your project should build without issue, as shown in the output window:

Learning to use Test Explorer

Test Explorer is the name of the window that lets you browse and run your tests from within Visual Studio. Open it by choosing Test > Test Explorer from the main menu. You should be greeted with a window that contains a hierarchy of the tests in your project, which should look something like this:

The toolbar of Test Explorer has buttons in several groups:

  • The first group contains buttons that are used for running tests, including the ability to run all tests, run selected tests, re-run the last tests, and re-run only the failed tests.
  • The second group contains buttons which allow filtering the list of tests based on current state (which includes 'passed', 'failed', and 'not run').
  • The third group contains buttons which configure Test Explorer, including advanced options like changing processor architecture (x86, x64, or Auto) and automatically running tests after every successful build.

The main window of Test Explorer is split into two panes:

  • The left pane contains a tree view of the tests in your project (grouping criteria can be changed as you see fit). Columns can be configured to show details about the test, including things like the current state, how long the test took to run, metadata (traits) related to the test, and more.
  • As you select items in the tree view on the left pane, the right pane will provide information about your current selection, including test counts, outcomes, links to the source of the test, test output, and exception messages and stack traces for failed tests.

Click the left-most button on the Test Explorer toolbar (it looks like a double green arrow, titled 'Run All Tests In View'. This will run the single empty test, and the result should be success:

Now that we've ensured everything is working, it's time to write our first real tests.

Write your first tests

Edit UnitTest1.cs and replace the default file contents with this:

Now let's go run the tests again and see what happens:

We purposefully wrote both a passing and failing test, and we can see that the results reflect that. By clicking on the failed test, we can see a link both to the top of the unit test (at line 14), but also the failure message (we expected 5 but got 4) as well as a link to the exact line where the failure occurred (line 16).

When you edit the source file, also take note of the fact that CodeLens decorations show up which indicate not only test status (passed/failed) on the test themselves, but also on functions that are called by the code, indicating how often the code is called in tests, and a count of which of those tests have passed or failed:

Visual

Now that we've gotten your first unit tests to run, let's introduce one more way to write tests: using theories.

Write your first theory

You may have wondered why your first unit tests use an attribute named [Fact] rather than one with a more traditional name like Test. xUnit.net includes support for two different major types of unit tests: facts and theories. When describing the difference between facts and theories, we like to say:

Facts are tests which are always true. They test invariant conditions.

Theories are tests which are only true for a particular set of data.

A good example of this is testing numeric algorithms. Let's say you want to test an algorithm which determines whether a number is odd or not. If you're writing the positive-side tests (odd numbers), then feeding even numbers into the test would cause it fail, and not because the test or algorithm is wrong.

Let's add a theory to our existing facts (including a bit of bad data, so we can see it fail):

This time when we run our tests, we see a second failure, for our theory that was given 6:

Although we've only written 3 test methods, the test runner actually ran 5 tests; that's because each theory with its data set is a separate test. Note also that the runner tells you exactly which set of data failed, because it includes the parameter values in the name of the test. The Test Explorer UI even shows a new level in the tree, as each row of data becomes a test result underneath its test method.

Running tests against multiple target frameworks

Sometimes, you want to write tests and ensure they run against several target application platforms. The xUnit.net test runner that we've been using supports .NET Core 1.0 or later, .NET 5.0 or later, and .NET Framework 4.5.2 or later. With a single test project, we can have our tests run against multiple target frameworks. Open the .csproj file and make the following change.

Change TargetFramework:

To TargetFrameworks:

When you change a project file from TargetFramework to TargetFrameworks (or back), Visual Studio might show you a yellow 'alert bar' which indicates that you have to reload the project for your changes to take effect. It's best to make this kind of change from a clean environment with no dirty text editors, to prevent the possibility of losing any changes.

Test Explorer supports any combination of .NET Core (including .NET 5+) and .NET Framework targets. You can even include multiple versions of the same target framework (for example, it's legal to have something like <TargetFrameworks>net452;net461;net48;netcoreapp2.1;netcoreapp3.1;net5.0</TargetFrameworks>). Application authors will typically only use a single target framework, related to the target framework the application is intended to run on. Library authors are more likely to use several target frameworks, to ensure their tests run successfully on all supported target frameworks.

The Test Explorer tree view will now show your test project multiple times, once for each target framework. You can run individual tests from individual frameworks, or you can simply run all tests for all frameworks.

Copyright © .NET Foundation. Contributions welcomed at https://github.com/xunit/xunit/tree/gh-pages.


This topic describes a step-by-step process of creating the simplest unit test in Microsoft Visual Studio 2010 (C++) for a CLR Console Application. Using this example, you can learn to create your own Unit-tests. The example also demonstrates the use of the Assert class for testing the work functions.

Contents

  • Instructions
    • 4. Creating a test
      • 4.5. Connection of the “MaxApp.cpp” module of the MaxApp project to the TestMaxApp project

Search other websites:

The task

For a CLR Console Application, develop a Unit-test that tests the Max3() function, which defines the maximum element of three numbers. For the Max3() function, set the TestMax() test method. Check the function.

Visual Studio Unit Test Project

Instructions

1. Create a CLR Console Application

After starting Microsoft Visual Studio, you must select

As a result, the New Project window opens (Figure 1), in which you need to select template

Project name set as MaxApp (or, if desired, another). In our case, the project folder is set to “E:Test” (the “Location:” field).

Figure 1. Creating an application using the CLR Console Application template

After selecting OK, an application of the CLR Console Application type will be created.

After creating the application, the Microsoft Visual Studio text box will have an approximate view, as shown in Figure 2.

Figure 2. Application view after creating

As you can see in Figure 2, the MyApp.cpp module contains the connection of the module “stdafx.h” and the main() function, which is the entry point to the program (this function is associated with the C++ program).

2. Implementation of function Max()

Before the declaration of the main() function, the text of the Max() function is entered, which looks like this:

This function will need to be tested using Unit-test in Microsoft Visual Studio.

3. The text of the program, which must be tested

At the moment, the text of the program you want to test is as follows:

Because this program will be tested from another testing module, then nothing needs to be entered in the main() function. Since, according to the condition of the task, you need to test the operation of the Max() function. But this will already be done from the testing module. At the moment our program is ready for testing.

4. Creating a test

The test is created by a separate project in the Solution. The program, which will be tested does not know about it. The test program that will test calls the functions of the program under test. In our case, the test program will call the function

4.1. Adding a new project to the solution

To create a test, you need to create a new project in the Solution. To do this, a sequence of commands is called in Visual Studio

This will open the “Add New Project” window, shown in Figure 3.

Figure 3. The “Add New Project” window

In the window a templates group of Visual C ++ – Test is selected. From the proposed templates, the project template “Test Project” is selected. The “Name” field indicates the name of the project that will test our program. You need to set, for example, TestMaxApp. The project is located in a separate folder “E:TestMaxApp”. After selecting OK, the system creates new project files that will be tested, as shown in Figure 4. A file (module) is created with the name “UnitTest1.cpp”. In this file, you need to enter the code that will test the Max() function from the MaxApp.cpp module.

Figure 4. The text of UnitTest1.cpp file. The Solution Explorer window with the displayed projects TestMaxApp and MaxApp

4.2. The structure of solution

As you can see in Figure 4, Solution Explorer displays the Solution Items structure, which contains two projects:

  • the MaxApp project. This is a project created using the CLR Console Application template with the Max() function, which to be tested;
  • the TestMaxApp project. This project is designed to test the functions of the MaxApp project. The program code that will test the Max() function will be added to the project file UnitTest1 of the TestMaxApp project.

Both projects can be executed independently of each other.


4.3. The text of the test file “UnitTest1.cpp”. Attributes [TestMethod] and [TestClass]

In the TestMaxApp project, the UnitTest1.cpp test file is the main test file. This file contains methods that will test the functions of the project “MaxApp.cpp”. The TestMaxApp project can contain any number of files that contain tests (for example, UnitTest2.cpp, UnitTest3.cpp, etc.).

Listing of the UnitTest1.cpp file generated by MS Visual Studio is as follows:

As you can see from the above code, the file contains a class named UnitTest1. The class has a public method named TestMethod1().Before implementation of TestMethod1() method, the [TestMethod] attribute is placed. This means that in the body of the method, you need to enter code that will test the functions of the MaxApp project.

In the class, you can enter any number of methods that will test different functions from different modules. The main thing is that these methods are marked with the attribute [TestMethod]. For example, if you want to add a second test method named MySecondTestMethod(), you need to enter approximately the following code into the class body:

Similarly, the [TestClass] attribute is placed before the UnitTest1 class. This means that there are testing methods in the class.

4.4. Making changes in the text of UnitTest1

You can change the method names and add new methods that are marked with the [TestMethod] attribute in the UnitTest1.cpp module. With this in mind, in the UnitTest1.cpp text, the TestMethod1() method must be renamed to TestMax().

After the changes have been made, the abbreviated text of UnitTest1.cpp file module will look like:

4.5. Connection of the “MaxApp.cpp” module of the MaxApp project to the TestMaxApp project

To access the Max() function of the “MaxApp.cpp” module of the MaxApp project from the TestMaxApp project, you need to call this module using the #include directive.

There are 2 methods of this connection:

  • connect the file “MaxApp.cpp”, specifying its full name on the disk (or on another source);
  • in the references to the Microsoft Visual Studio assemblies, configure the folder with the MaxApp project so that it is automatically connected.

After this, you can access the “MaxApp.cpp” file by its abbreviated name. In this topic, both methods are described.

4.5.1. Method 1. Connection with a full name request

This method is more simplified. It is convenient when you need to connect a small number of files to the project for testing.

In the TestMaxApp project, in the “UnitTest1.cpp” file, after connecting namespaces, you need to set the following line:

This specifies the full name of the MaxApp.cpp file on the disk, in which the Max() function is located, which you need to test.

4.5.2. Method 2. Connection with an abbreviated name

This method is effective when you need to test several modules of different projects. A whole directory (folder) is connected with the files of the tested project. In our case, it is needed to use the folder:

in the list of references to assemblies (projects) that automatically connect to the TestMaxApp project. After that, you can connect the MaxApp.cpp module by abbreviated name

avoiding the use of a long name as shown in section 4.5.1.

First of all, the “References …” command is called from the TestMaxApp context menu as shown in Figure 5. Another way to call – the command Project-> References … (previously need to be select TestMaxApp project).

Figure 5. Calling the default references viewer window for assemblies that are used in the TestMaxApp project

This opens the “TestMaxApp Property Pages” window which is shown in Figure 6.

Figure 6. The “TestMaxApp Property Pages” window, command “Add New Reference …”

In the “TestMaxApp Property Pages” window, you first need to activate the “Common Properties” -> “Framework and References” tab.

Then you need to select the command “Add New Reference …”. This command allows adding new folders with modules to the project, methods (functions, resources) of which can then be included in the project by the #include directive. After selecting the command, the Add Reference window, shown in Figure 7, opens.

Figure 7. The “Add Reference” window with the displayed projects in the current solution

In the “Add Reference” window, the Project tab displays the project folders that are used in this solution. In our case, only one MaxApp project is displayed, which is located in the folder

After selecting OK, you return to the previous window, in which the reference to the MaxApp project will be displayed in the list of references to the assemblies.

Figure 8. The “TestMaxApp Property Pages” window after adding the MaxApp project to the list of public assemblies

That’s not all! The next step is to connect the MaxTest project folder to the “Include Directories” list.

To do this, you must first activate the line

as shown in Figure 9.

Figure 9. The “TestMaxApp Property Pages” window, line “Include Directories”

In the “General” list, “Include Directories” is selected. As a result, a dropdown list is opened, in which you need to select the command “<Edit …>”. After that, the “Include Directories” window shown in Figure 10 opens.

Figure 10. The “New Line” command and the folder selection button with the files that connect

In the “Include Directories” window, add a new line with the “New Line” command and select the folder with the MaxApp project, as shown in Figure 10. After selecting the “…” button, the standard Windows window opens to select the desired folder. In our case, you need to select a folder

After selecting, the Include Directories window will have the appearance as shown in Figure 11.

Figure 11. The Include Directories window after selecting the folder E:TestMaxAppMaxApp

To go to the previous window, select OK.

Figure 12. The TextMaxApp Property Pages window after configuring the line “Include Directories”

To proceed to writing the program test code, select OK.

After the performed actions, all files from the folder

can be connected by abbreviated name, for example:

4.6. Writing code in the TestMax() method

The code that tests the Max() function fits into the body of the TestMax() method of the “UnitTest1.cpp” module. The code fragment of the TestMax() method looks like this:

The above code calls the function AreEqual() from the Assert class. This function compares the value that was returned from the Max() function and the value 6. In this case, the number 7 (maximum) is compared with the number 6. For this way, the test will not be passed, since 7 is not equal to 6. As a result, the Assert::AreEqual() function throws an exception, which will be displayed in a special window (see paragraph 5).

5. Running the test and checking the test results

In Microsoft Visual Studio, a special menu of commands, called Test, is implemented to work with Unit-tests. To run the test, you must select one of the commands

or

as shown in Figure 13.

Visual Studio Unit Test Ignore Attribute

Figure 13. Calling the test command and viewing the result

After starting the test, the result can be viewed at the bottom of the “Test Results” window. As you can see, the test is failed. This is logical, because in the function Assert::AreEqual() we compare the numbers 6 and 7, which are different from each other. Here the number 6 is specially introduced instead of the number 7.

If instead of 6 you enter the correct answer – the number 7 (maximum between 5, 6, 7), then the test will be passed. In this case, the text of the TestMax() method will be as follows:

The result window is shown in Figure 14.

Figure 14. The test result for the case if you enter the correct checking

Visual Studio Unit Test Console Output

Now we can conclude that the function Max() was developed correctly.

6. The code of UnitTest1 module

Below is the text of UnitTest1.cpp, which tests the Max() function from the module “MaxApp.cpp”:

7. Conclusion. Interaction between projects

In this topic, two projects are developed in the solution. One MaxApp project contains the Max() function to be tested. The second project TestMaxApp contains methods that test.

In Microsoft Visual Studio, each project is run using various menu commands. For example, the MaxApp project is launched in the standard way from the Run menu. And the test project TestMaxApp is run from the special menu “Test”.

Visual Studio Unit Testing

Related topics