Code Coverage based on NUnit tests in Visual Studio
Without further ado, suppose you are in the following situation:
The above situation will be considered for simplicity on a small example. Let's create in Visual Studio (in our case, this is Visual Studio 2010 Ultimate) a new project of the type Class Library and name it for obvious evidence TestedAssembly. In the above mentioned project we will add a single TestedClass class, which will consist of a single simplest method GetSomeString.
')
Now let's do a project with tests. Add another Class Library to the solution, which we call TestAssembly. In this assembly, we will also have only one TestedClassTest class with the only method GetSomeStringTest.
Well, now it’s time to discuss the most interesting thing: how to make Visual Studio collect data on code coverage for tests that it doesn’t want to run. Well, if he does not want to, then he will not, let the professional of the business, namely NUnit himself, take care of this. Let's add one more project to our long-suffering solution, this time of type Test Project, and let's call it, say, NUnitProxy. The studio will automatically put the UnitTest1.cs file in it, which we will delete with a clear conscience, and instead add the Generic Test. In the first test settings field, we need to specify the full path to nunit-console-x86.exe (note that x86 is important), and in the second field we will write the full path to the assembly with tests (in our case, this is the TestAssembly project). The main thing - do not forget the quotes.
Now let's go to the Solution Items folder, which magically materialized in the solution after adding the NUnitProxy project, and perform a double-click on the Local.testsettings file.
The Test Settings dialog opens in which we need to proceed to the Data and Diagnostics tab, tick the Code Coverage box and click the Configure button. The Code Coverage Detail window will appear to your gaze to select the assemblies for which Visual Studio will collect code coverage data. There is another small nuance here: if you build an assembly that lies in the \ bin \ Debug \ folder of the project under test, then the result of the analysis will be the charming emptiness of the universe. Click the Add Assembly ... button and specify the path to the assembly under test, which lies in the \ bin \ Debug \ folder of the project with tests (in our case, TestAssembly). Make sure that the Instrument assemblies in place is checked, and with OK, click OK, Apply and Close.
That's all. Visual Studio sees our proxy test, run it, observe the NUnit console that opens and, after the test run is completed, head to the Code Coverage tab, where we see quite expressive results.
And lastly two spoons of tar in a barrel of honey. Firstly, Visual Studio does not know how to tool x64 builds with all the consequences: you want Code Coverage - recompile under x86 (Any CPU also works). Secondly, if the code in the assembly is not covered at all, then this assembly will not be included in the final report (you can experiment by commenting on the body of the GetSomeStringTest method), which, as you understand, in certain situations may lead to an incorrect value of the final coverage (when data for multiple assemblies).
- you have some .NET project;
- for this project you have written NUnit tests (or they have already been written);
- you were solemnly handed a Visual Studio 2008 Team System (or higher) or Visual Studio 2010 Premium (or higher) and commissioned to analyze the code coverage of the tests (aka code coverage).
The above situation will be considered for simplicity on a small example. Let's create in Visual Studio (in our case, this is Visual Studio 2010 Ultimate) a new project of the type Class Library and name it for obvious evidence TestedAssembly. In the above mentioned project we will add a single TestedClass class, which will consist of a single simplest method GetSomeString.
')
Now let's do a project with tests. Add another Class Library to the solution, which we call TestAssembly. In this assembly, we will also have only one TestedClassTest class with the only method GetSomeStringTest.
Well, now it’s time to discuss the most interesting thing: how to make Visual Studio collect data on code coverage for tests that it doesn’t want to run. Well, if he does not want to, then he will not, let the professional of the business, namely NUnit himself, take care of this. Let's add one more project to our long-suffering solution, this time of type Test Project, and let's call it, say, NUnitProxy. The studio will automatically put the UnitTest1.cs file in it, which we will delete with a clear conscience, and instead add the Generic Test. In the first test settings field, we need to specify the full path to nunit-console-x86.exe (note that x86 is important), and in the second field we will write the full path to the assembly with tests (in our case, this is the TestAssembly project). The main thing - do not forget the quotes.
Now let's go to the Solution Items folder, which magically materialized in the solution after adding the NUnitProxy project, and perform a double-click on the Local.testsettings file.
The Test Settings dialog opens in which we need to proceed to the Data and Diagnostics tab, tick the Code Coverage box and click the Configure button. The Code Coverage Detail window will appear to your gaze to select the assemblies for which Visual Studio will collect code coverage data. There is another small nuance here: if you build an assembly that lies in the \ bin \ Debug \ folder of the project under test, then the result of the analysis will be the charming emptiness of the universe. Click the Add Assembly ... button and specify the path to the assembly under test, which lies in the \ bin \ Debug \ folder of the project with tests (in our case, TestAssembly). Make sure that the Instrument assemblies in place is checked, and with OK, click OK, Apply and Close.
That's all. Visual Studio sees our proxy test, run it, observe the NUnit console that opens and, after the test run is completed, head to the Code Coverage tab, where we see quite expressive results.
And lastly two spoons of tar in a barrel of honey. Firstly, Visual Studio does not know how to tool x64 builds with all the consequences: you want Code Coverage - recompile under x86 (Any CPU also works). Secondly, if the code in the assembly is not covered at all, then this assembly will not be included in the final report (you can experiment by commenting on the body of the GetSomeStringTest method), which, as you understand, in certain situations may lead to an incorrect value of the final coverage (when data for multiple assemblies).
Source: https://habr.com/ru/post/129722/
All Articles