data and how to interpret the code coverage is quite sensitive to touch, but like condoms; It is preferable to have them at hand and not need them than to need them and not have them.
In Visual Studio 2012 and Team Foundation Server 2012 we have the opportunity to set up our definitions of compiling so take into account (or not) of code coverage.
For example, if edit a Team Build in the Team Foundation Service definition, we can see also similar to the following in the configuration window:
If we accede to details of the tests to run you can choose in the options of this sections, if we set aside the options enable code coverage or interpret more information through a configuration file.
For example, if we enable the CC option we will see the outcome of a compilation information similar to the following. In which we can see that we have only 21% CC, as much as our tests run a CC quite high on our code.
The problem is given, that within the definition by default “enable CC” also takes into account all the assembled of.NET that are used during the process. So, how to troubleshoot this scenario?
So very simple.
1 Add a file of type “test settings” to the solution in which we worked.
2. In these settings, we define the assembled that we want to analyze.
3 Configure this file to make it the to “lead” the execution of our tests.
4 We protect this file within our TFS
5 Edit the definition of our Team Build and access to the details of tests section.
6. In the test options, select the “custom” option and select the file “test settings” which we create and protegimos in previous steps.
7 Launched the build and…donate!
A detail, this scenario is also usable when working with customers of Visual Studio 2010 or in mixed scenarios.
Saludos @ Home