TestSuite are suites of test dynamically created. This is a feature that was requested long ago and it finally poped up on my todo list. A TestSuite provides a way of creating dynamically TestCases with tightly-controlled naming. For example, in data-driven testing, you might want to create test cases based on some external data source.

How-to in MbUnit

To use suites, tag your calss with the TestSuiteFixtureAttribute attribute. Each method who creates suite must be tagged with TestSuiteAttribute and return a TestSuite, there can be multiple methods returning suites.

using System;
using MbUnit.Core.Framework;
using MbUnit.Framework;
namespace MyNamespace
{
    [TestSuiteFixture]
    public class MyClass
    {
        public delegate void TestDelegate(Object context);
        [TestSuite] 
        public TestSuite GetSuite()
        {
            TestSuite suite = new TestSuite("Suite1");
            suite.Add( "Test1", new TestDelegate( this.Test ), "hello" );
            suite.Add( "Test2", new TestDelegate( this.AnotherTest), "another test" );
            return suite;
        }
        public void Test( object testContext )
        {
            Console.WriteLine("Test");
            Assert.AreEqual("hello", testContext);
        }
        public void AnotherTest( object testContext )
        {
            Console.WriteLine("AnotherTest");
            Assert.AreEqual("another test", testContext);
        }
    }
}

The resulting naming of the fixture will be as follows:

MyNamespace.MyClass.Suite1.Test1
MyNamespace.MyClass.Suite1.Test2

Not that the namespace name and the class name are used to create the test case name, the name of the method creating the suite is not used. The resulting output of the tests in MbUnit will look as follows:

MbUnit (2.16.1) has now the ability to load and run NUnit (and csUnit) assemblies without recompilation.

How it works

Jamie Cansdale (NUnitAddin) sent me some classes he was using in his Addin to execute NUnit assemblies. Thank you Jamie :). When a type is explored, it looks into the referenced assemblies for NUnit.Framework.dll or csUnit.Framework.dll. If found, it thens extracts the TestFixtureAttribute type and tests if the type is tagged with it. A couple more details and there you have NUnit tests run by MbUnit...

Sample:

The following sample fixture is a standard NUnit fixture:

using System;
using NUnit.Framework;
namespace MbUnit.Tests.Core.FrameworkBridges
{
    [TestFixture]
    public class NUnitFrameworkTest
    {
        [TestFixtureSetUp]
        public void TestFixtureSetUp()
        {
            Console.WriteLine("TestFixtureSetUp");
        }
        [SetUp]
        public void SetUp()
        {
            Console.WriteLine("SetUp");
        }
        [Test]
        public void Test()
        {
            Console.WriteLine("Test");
        }
        [Test]
        public void AnotherTest()
        {
            Console.WriteLine("Another test");
        }
        [Test]
        [ExpectedException(typeof(AssertionException))]
        public void ExpectedException()
        {
            Assert.Fail("Should be intercepted");
        }
        [Test]
        [Ignore("Testing ignore")]
        public void Ignored()
        {
            Assert.Fail("Must be ignored");
        }
        [TearDown]
        public void TearDown()
        {
            Console.WriteLine("TearDown");
        }
        [TestFixtureTearDown]
        public void TestFixtureTearDown()
        {
            Console.WriteLine("TestFixtureTearDown");
        }
    }
}

The  fixture is loaded and executed by MbUnit and the reports shows:

The MbUnit.Core.AutoRun class is a new lightweight class that explores and executes the tests contained in the entry assembly. This class can be used to create executable test assemblies that are self-contained.

public class AutoRunTest
{
    public static void Main(string[] args)
    {
        using(MbUnit.Core.AutoRunner auto = new MbUnit.Core.AutoRunner())
        {
            auto.Run();
            auto.ReportToHtml();
        }
    }
}

The AutoRunner class also supports filtering and will be available in 2.16.1.

At last, MbUnit loads the assemblies in separate AppDomain and do not lock them...

This release brings the "much awaited" shadow copying feature to MbUnit which means that you can do real TDD development with the GUI. This part of the code has been strongly inspired from the NUnit implementation. Copyright notice have been kept in the source code.

Release Details

• Separate AppDomain for each test assembly,
• Handling configuration files as in NUnit (test assembly name + ".config"),
• Test assembly monitoring and reloading when changes detected,
• Filtering in the console application,

Many other bugs have been also fixed...

Download MbUnit 2.16beta at www.dotnetwiki.org

More and more visualization of the coverage: ThreadTree and Xml:

The ThreadTree is a control available in the Data Visualization Components suite from Microsoft Research, it displays a tree where the nodes are sorted by a ranking. In this case, the tree is the Namespace / Type hierarchy and the ranking is the coverage. Not very useful, but very pretty.

The Xml views shows the actual output of NCover.

Just added a Tree and the Microsoft TreeMap to visualize the coverage results:

I have freshened up the NCover project to build a simple Gui around it. Not much work, just some Category attributes to put there and there...

This blog presents an implementation of an Ant Colony Optimization (ACO) framework using Visual C# 2005 Express.

What is ACO ?

ACO is the evolution of the Ant Algorithms, algorithms that were based on observation on ants. It is a metaheuristic algorithm that is used to solve complex problems (NP-hard) such as the Travelling Salesman Problem(in this problem, a salesman has to travel across each city in a minimum distance). There is a lot of litterate on ACO and TSP on the web...

Where does it come from ?

My implementation is based on the book Ant Colony Optimization from Marco Dorigo. I must say that the authors have takened care of giving clear and well-detailled pseudo-code to make an implementation easy.

The first results

Here are some outputs of the TSP computation of burma14 using my framework. The red line represents the best-so-far solution, the other lines are colored with respect to their pheromone intensity.

• Iteration 1:
  
• Iteration 7:
  
• Iteration 28:
  
• Iteration 33:
  
• Iteration 54:
  

Download

The download called MetaHeuristics is available at http://www.codeplex.com/metaheuristics .

This tutorial shows the basic usage of NCover from GotDotNet. The tutorial starts by creating a toy solution, how to set-up NCover execution, analysis and improvements of the results.

A toy solution

1. Create a new solution,
2. Add a C# assembly project named UnderCover,
3. Add a class JamesBond defined as follows:

   using System;
   namespace UnderCover
   {
       public class JamesBond
       {
           public void Covered()
           {
               Console.WriteLine("Covered");
           }
           public void UnCovered()
           {
               Console.WriteLine("UnCovered");
           }
       }
   }

4. Add a C# console application project name UnderCover.Console.exe
5. Edit the Main entry method as follows:

   using System;
   namespace UnderCover.Cons
   {
       class Class1
       {
           [STAThread]
           static void Main(string[] args)
           {
               JamesBond james = new JamesBond();
               james.Covered();
           }
       }
   }

6. Compile in debug mode
   Note: NCover needs the symbol files (.mdb) in order to work, so you need to work with the debug version.

Our objective is now to compute the coverage of UnderCover.dll when UnderCover.Console.exe is executed. It is straightforward to see that JamesBond.Covered will be fully covered while JamesBond.UnCovered will be not covered.

Setting a NCover batch file

In this step, we create a simple batch file in the bin/debug directory to execute NCover.Console.exe with the command line. The NCover command line takes the command line to execute + the assembly to cover as parameters:

"C:\Program Files\NCover\NCover.Console.exe" /c "UnderCover.Cons.exe" "UnderCover.dll" /v

The output of NCover is as follows

"C:\Program Files\NCover\NCover.Console.exe" /c "UnderCover.Cons.exe" "Under
Cover.dll" /v
NCover.Console v1.3.3 - Code Coverage Analysis for .NET - http://ncover.org

Command: UnderCover.Cons.exe
Command Args: UnderCover.dll
Working Directory:
Assemblies:
Coverage File:
Coverage Log:
******************* Program Output *******************
Covered
***************** End Program Output *****************
Copied 'C:\Program Files\NCover\Coverage.xsl' to '...\Coverage.xsl'

If everything executed correctly, a Coverage.xml and Coverage.xsl has appeared in the directory.

First look at the results

Open Coverage.xml in your browser and you will get something like this:

The coverage has worked, we have the expected results.

Better XSLT template

Now, this works fine for a simple assembly but the files becomes huge if you have a normal project so we need a better XSLT template. MbUnit has it's own NCover Coverage.xsl template (that you can get here) that supportes expand/collapse and computes the percents of coverages. Let us copy the new coverage.xsl to the directory:

Now this looks much better :)

Results in Reflector

As I showed in a previous post, the Reflector Code Coverage Addin can help you visualize the coverage in a more intuitive way. The steps to follow are:

1. Add Reflector.TreeMap.dll as a Addin of Reflector,
2. Load UnderCover.dll,
3. Right-click on UnderCover assembly and choose Coverage TreeMap,
4. Right-click on the TreeMap and load the Coverage.xml file
5. Enjoy the results:

Downloads:

The solution of this tutorial is available in the download section of www.dotnetwiki.org .

Just loaded the MbUnit solution in Visual C# Express 2005 and.... it worked without a single problem! Looks like we will have MbUnit for .NET 2.0 in the next release :)