sharing about .NET and technology RSS 2.0
# Monday, July 13, 2009

Code coverage is used to determine how effectively your tests exercise the code in your application. This way you can identify sections of code that are covered, not covered or partially covered by your tests.

Visual Studio uses 2 different types of analysis, block-based statement coverage (C1 coverage) and line-based coverage.

  • Block-based statement coverage
    A block is defined as a sequence of instructions that have a single entry point and a single exit point. Exit points include branch instructions, a function call, a return instruction, or, for managed code, a throw instruction.
  • Line-based coverage
    For line-based coverage, the tools identify all of the blocks that make up a line and then use this information to determine the level of coverage for the line. If all of the blocks that make up the line are covered, then the tools report that the line is covered. If no blocks in the line are covered, then the tools report that the line is not covered. If some, but not all, of the blocks in the line are covered, then the tools report that the line is partially covered.

Take for example the following class that reside in MyProject.BusinessLogic assembly

public class Foo
{
    public int Calculate(int x, int y)
    {
        if (x > 0 && y < 0)
        {   
            return -1;
        }
        else
        {
            return 1;
        }
}

And a unit test that reside in MyProject.BusinessLogic.Test assembly

[TestClass]
public class FooTest
{
    [TestMethod]
    public void Calculate()
    {
        Foo foo = new Foo();
        Assert.AreEqual(1, foo.Calculate(3, 4));
    }
}

To enable code coverage you need to double-lick on the LocalTestRun.testrunconfig file that is located in the 'Solution Items' folder.

testrunconfig

Inside the 'Code Coverage' tab you select the assembly that you want to instrument. In this case we select MyProject.BusinessLogic.dll assembly.

codecoverage

Now you will need to run your unit tests again. Note that code coverage doesn't work when you debug your unit tests, so you will need to run your unit tests through the menu 'Test –> Run –> All Tests in Solution (CTRL+R, A)'. After that you can view a report about the code coverage results through the menu 'Test –> Windows –> Code Coverage Results'.

codecoverageresults

From the results we notice that we don't have 100% code coverage because our unit test only reached one part of the condition inside the Calculate method. If you open the Foo class and enable the code coloring you see the parts that are covered, not covered or partially covered.

CodeCoverageColoring

  • Light Blue: Indicates that the entire line of code was exercised in the test run.
  • Beige: Indicates that only a portion of the code blocks within the line of code were exercised in the test run.
  • Reddish Brown: Indicates that the line was not exercised in the test run.

Code coverage inside Visual Studio uses statement coverage and in this case the number of IL instructions reached is taken into account. If we add some statements in the Foo class and run again our code coverage we notice that the coverage has been raised form 71,43% to 92,59%. It's important to notice, that when you refactor your class it influences the code coverage even when the contract of the class is the same! This is very different from Branch coverage where each control structure is evaluated to true and false. In this case we would have 50% code coverage.

public class Foo
{
    public int Calculate(int x, int y)
    {
        if (x > 0 && y < 0)
        {   
            return -1;
        }
        else
        {
            Console.WriteLine(x.ToString());
            Console.WriteLine(x.ToString());
            Console.WriteLine(x.ToString());
            Console.WriteLine(x.ToString());
            Console.WriteLine(x.ToString());
            Console.WriteLine(x.ToString());
            Console.WriteLine(x.ToString());
            Console.WriteLine(x.ToString());
            Console.WriteLine(x.ToString());
            Console.WriteLine(x.ToString());

            return 1;
        }
    }
}
Monday, July 13, 2009 11:51:03 PM (Romance Daylight Time, UTC+02:00) -  # -  Comments [2] -
.NET | Unit Testing | Visual Studio
# Thursday, October 16, 2008

In some cases it can be useful to quickly run your Microsoft unit tests on a machine where Visual Studio is not installed. For example on an end-user machine and/or during acceptance testing. Microsoft unit tests have a great integration with Visual Studio and Team Foundation Server, but unfortunately the unit tests cannot be run as a standalone application.

I saw there was an open-source adapter for NUnit, called Microsoft Team System NUnit Adapter from Exact Magic Software that can run Microsoft unit tests inside NAnt. For my unit tests I had some problems with the ExpectedException attribute. Then I noticed there is a project called Gallio and it worked like a charm and it can do a lot more! I noticed that today a new version has been released, namely Gallio v3.0.4.

Gallio is a extensible , open and neutral test automation platform. It provides tools and services needed to run and manipulate tests written using a wide range of other frameworks. Gallio can run tests from

and it can integrate with the following tools

To run the the tests there is a command-line runner, called ‘Echo’ and a graphical user-interface, called ‘Icarus’.

image

Thursday, October 16, 2008 3:25:48 PM (Romance Daylight Time, UTC+02:00) -  # -  Comments [3] -
Unit Testing | Visual Studio
# Wednesday, March 01, 2006

Continuous integration is the process that continuously build, analyze and test your sources. In many cases the process is triggered when changes are notified in the version control system, like VSS, CVS, etc. Martin Fowler has a good article about continuous integration.

In the .NET world, the most famous tool is CruiseControl.NET in combination with NAnt & NUnit. Getting an e-mail or popup from CruiseControl.NET is nice when a build is broken, but notifying the build status through traffic lights is much cooler.

Michael Swanson integrated CC.NET with the Ambient Orb. I think that the Ambient Orb is not an option for Europe, but you can integrate by using the X10 home automation technology. A good article about integrating X10 with .NET can be found on Coding4Fun and is called Controlling Lights with .NET.

Here are some (other) implementations:

 
 

I am going for a walk this evening, and I think that tomorrow a traffic light will be missing :-D

Wednesday, March 01, 2006 11:58:46 PM (Romance Standard Time, UTC+01:00) -  # -  Comments [1] -
.NET | Internet | Unit Testing
# Tuesday, November 15, 2005

On my current project we are developing a windows forms application in Visual Studio 2005.
We are still using CruiseControl.NET for continuous integration and unit testing, because
setting up a team foundation server would give an overhead right now.

For unit testing we like to have the nice debug and built-in features of MSUnit and the unit tests
automatically tested by CruiseControl.NET through NUnit. The good thing about the two libraries, is that
they work through attributes and the common Assert methods are the same.

The template we use for our unit tests, looks like:

#if NUnit
   using NUnit.Framework;
#else
   using Microsoft.VisualStudio.QualityTools.UnitTesting.Framework;
#endif

namespace MyUnitTests
{
   [NUnit.Framework.TestFixture]
   [Microsoft.VisualStudio.QualityTools.UnitTesting.Framework.TestClass]
   public class MyTestClass
   {
      [NUnit.Framework.Test]
      [Microsoft.VisualStudio.QualityTools.UnitTesting.Framework.TestMethod]
      public void MyTestMethod()
      {
      }
   }
}

We migrated our project to the new Composite UI. Yes, today a new release of the cab has been released. In the unit tests of CAB I noticed they did the same trick, but with aliases:

#if !NUNIT
   using Microsoft.VisualStudio.TestTools.UnitTesting;
#else
   using NUnit.Framework;
   using TestClass = NUnit.Framework.TestFixtureAttribute;
   using TestMethod = NUnit.Framework.TestAttribute;
   using TestInitialize = NUnit.Framework.SetUpAttribute;
   using TestCleanup = NUnit.Framework.TearDownAttribute;
#endif

namespace MyUnitTests
{
    [TestClass]
    public class MyTestClass
    {        
        [TestMethod]
        public void MyTestMethod()
        {        
        }
    }
}
Tuesday, November 15, 2005 2:13:47 PM (Romance Standard Time, UTC+01:00) -  # -  Comments [4] -
.NET | Unit Testing
Navigation
Archive
<September 2010>
SunMonTueWedThuFriSat
2930311234
567891011
12131415161718
19202122232425
262728293012
3456789
About the author/Disclaimer

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2010
Christoph De Baene
Sign In
Statistics
Total Posts: 176
This Year: 2
This Month: 0
This Week: 0
Comments: 283
All Content © 2010, Christoph De Baene
DasBlog theme 'Business' created by Christoph De Baene