In the course of writing the code is already accustomed to this, that you should write tests in parallel. Approaches, when and how to write tests is much. The choice we have too few available test frameworks, but not what I wanted to write. In this article I want to touch on the test code coverage testing.When writing tests often there is a need to check, which pieces of code are covered by tests, and which are not. This information allows you to write additional tests, that will cover this piece of code covered prior tests. In the future this will avoid mistakes.
Те sentences sound good,, but the problem arises with the tools. Most of the instrument is payable. This causes the situation, that are not suitable for home use. Home user can not afford on it in many cases. Some kind of compromise is JetBrains program. In the case, that we create an application type OpenSource this can get their programs for free. If you meet this condition we can use the dotCover. If not, we are left to look for another solution.
One evening I spent for searching tool which enable:
- Code coverage testing,,
- shows, which lines are executed, and which are not,
- is free.
And I found it. This program is PartCover. When you first start to notice a very small interface.. But it is abundantly sufficient.
Before I managed to get the correct result of the testing I needed a little browse through the Internet. At first configuration looks easy. But you need to find some special settings that allows running it with MSTest as build platform.
In this window, we supplement:
- Executable File – Here we give the path to the testing framework, If ш MSTest.exe and Visual Studio 2010 it is: C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\MSTest.exe. During the search for information to properly configure application I found the information, that if you used a tool for Mocks (eg.. Typemock Isolator), which requires pre-launch, you need enter path here and path to test framework should be put as Working Arguments,
- Working Directory – path to the directory with compiled tests,,
- Working Arguments – should be given here dll file containing the test,
- Rules – this is where you define, which classes, namespaces will be checked, and which will not.
Require further comment need two fields: Working Arguments and Rules. The first choice of MSTest.exe as test engine resulted in, I had to spend some time to find out how to use that toll. In the case NUnita situation is better. After entering nUnit parameters everything works as it should. In the case MSTest.exe one line should be added /testcontainer before file with tests and /noisolation just after it. Additionally important is the order. In the case of order will be not keep, code coverage will be reported as 0%.
The other pole Rules allows you to define a kind of filtering. If you want, that some class was taken to coverage report, following notation should be used +filtr. Otherwise, you should use -filtr. To run the tool we need to define at least one filter. The simplest filter is +[*]*, which takes all the results to coverage report.
There is some inaccuracy compared to standard UI place where to save “project”. In most of the tool is done in the File menu. In this tool you can do this form windows level. The File menu does not have such option.
With provided configuration, we can finally lunch this tool. To do this, click button Start. At the time tests will be launched. After a while program will be able to provide the results of code coverage. To see, which lines of code are being executed during the tests, or which one are not you need to open menu View choose View Coverage Details. After selecting classes you are able to see which lines are executed (green), and which are not (red).
An additional advantage of this tool is that it can be run in the console. Thus it can be integrated with the system of automatic builds.
set partcover="C:\Program Files (x86)\Gubka Bob\PartCover .NET 2.3\partcover.exe" set nunit="C:\Program Files (x86)\NUnit 2.5.3\bin\net-2.0\nunit-console-x86.exe" set tests="Debug\YourTests.dll" %partcover% --target %nunit% --target-args %tests% --include [*]* --output PartCoverResults.xm
Another quite useful feature is counter of code line execution. Above main window you can find table with information how many times each part of code have been run. After clicking each lines you will be able to see corresponding part of code.
Analyzing the results, you should remember that 100% code coverage does not guarantee that code has been tested correctly. This means only that each line of code has been executed.