Monday, July 19, 2004

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:

posted on Tuesday, July 20, 2004 4:43:00 AM UTC  #    Comments [6]
Monday, June 06, 2005 5:48:09 PM UTC
... And a great tool gets even better! Thank you.
<br>
<br>How about adding a category attribute to the Mix?
<br>
<br>Something lile
<br>
<br>[Test, Category(&quot;ParameterValidation&quot;)
<br>public void Parm1Check()
<br>{
<br>}
<br>
<br>[Test, Category(&quot;ParameterValidation&quot;)
<br>public void Parm2Check()
<br>{
<br>}
<br>
<br>Then in the trees, add one more level so the tests are grouped.
<br>
<br>This would allow Design-By-Contract tests to be viewed and reported on as far as how the contract is enforced (or not); but also could lend itself to being an enducational tool for a development staff to help identify areas that need improvement in their coding practices; for example if xx% of the test case failures are because of Boundary conditions, the team would know that their coding technique needs to be adjusted.
<br>
<br>It would also help those who perform code reviews to identify problem spots that can be examined in new code as it is written to help raise quailty.
<br>
<br>
John Bergman
Monday, June 06, 2005 5:48:09 PM UTC
There is already category at the fixture level. Now, putting it at the &quot;Test&quot; level is somehow a little bit more involved.
<br>
<br>Please, post this suggestion on the <a title="MbUnit, Generating Unit Testing and Model Based Testing Framework for .NET Framework" href="http://mbunit.tigris.org" target="_blank">MbUnit</a> issue tracking or on www.dotnetwiki.org forums so that I can keep track of it :)
Jonathan de Halleux
Monday, June 06, 2005 5:48:10 PM UTC
Peli's Blog
Monday, June 06, 2005 5:48:10 PM UTC
Peli's Blog
Monday, June 06, 2005 5:48:11 PM UTC
Peli's Blog
Monday, June 06, 2005 5:48:11 PM UTC
Trey's Brain Dump
Comments are closed.