# Sunday, July 25, 2004
Download available at www.dotnetwiki.org download page.
posted on Sunday, July 25, 2004 9:24:00 AM (Pacific Daylight Time, UTC-07:00)  #    Comments [4]
# Saturday, July 24, 2004

Reflector.Graph has been recompiled for Reflector 4.0.15.0 along with some bug fixes (unit test generation is working again).

Download it in the www.dotnetwiki.org download section.

posted on Saturday, July 24, 2004 1:33:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [8]

This release brings more userfriendlyness to the GUI and generally it returns more information on what MbUnit is doing. See latest release page on this blog for the download links.

New features:

  • New progress bar displaying number of tests, successs, failures, ignore and test duration,
  • Status bar displaying more information,
  • Console application does pop report by default,
  • Added TestDox report type,
  • MbUnit gui can load and save projects (assemblies + treeview state is serialized)

Screenshot of the "new" gui

posted on Saturday, July 24, 2004 10:39:00 AM (Pacific Daylight Time, UTC-07:00)  #    Comments [0]
# Friday, July 23, 2004

MbUnit supports a new report type, similar to TestDox. This reports creates a simple text file, whith fixture and test case names more human readable.

For example, a Test fixture like

[TestFixture]
public class FooTest
{
    [Test]
    public void IsASingletonTest() {}
    [Test]
    public void AReallyLongNameIsAGoodThing() {}
}

MbUnit generates

-- MbUnit.Demo
MbUnit
MbUnit.Demo
    Foo
        - is a singleton
        - a really long name is a good thing

Available in 2.18.1

posted on Friday, July 23, 2004 1:04:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [0]

MbUnit now supports a simple way of running a single fixture (the one you are working on) without the need of a GUI or NUnitAddIn. The method is simple: tag your fixture class with the CurrentFixtureAttribute and launch it with the auto-runner:

Consider this little example:

[TestFixture]
public class MyFixture
{
   ...
}
  1. Tag MyFixture with CurrentFixtureAttribute:
  2. Convert the test assembly to a console application and add the following code to your main function:
    using System;
    namespace MbUnit.Tests
    {
        using MbUnit.Core;
        using MbUnit.Core.Filters;
        public class AutoRunTest
        {
            public static void Main(string[] args)
            {
                using(AutoRunner auto = new AutoRunner()) 
                {
                    auto.Domain.Filter = FixtureFilters.Current;
                    auto.Run();
                    auto.ReportToHtml();
                }
            }
        }
    }
    
  3. Launch the console. The fixture will be executed and a HTML report of the tests will pop-out automatically.
(available in 2.18.1)
posted on Friday, July 23, 2004 7:42:00 AM (Pacific Daylight Time, UTC-07:00)  #    Comments [0]
# Thursday, July 22, 2004

This is a question that I received a few times: Peli is my nickname, which was given to me by my parents. Their memory on the reason why is somehow vague:

  • It could comes from the pelican (the bird) because of the movie "Jonathan Livingstone the Seagul", which became a pelican,
  • because Pelican have a big mouth,
  • because my mom did not like "Jonathan"  with the french pronounciation

Cheers,

Peli...

posted on Thursday, July 22, 2004 8:31:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [2]

New features:

 See latest release page on this blog for the download links

posted on Thursday, July 22, 2004 9:02:00 AM (Pacific Daylight Time, UTC-07:00)  #    Comments [5]
# Wednesday, July 21, 2004

The API Design Guidelines encourage developers to check all their arguments and thereby avoid throwing a NullReferenceException.  If an argument is null and the contract of the method forbids null arguments an ArgumentNullException should be thrown. Brad Adams 

So you agree with Brad (I do) and you always check that arguments are not null before using them. This means a little bit more of code but it is worth it. But this means also a lot more of test code because, ideally, you should test that all your methods check all their arguments. This means writing hundreds of boring, repetitive test cases.... and you don't want to do that.

At least I don't so I added a new feature to MbUnit that does it for me.

Test for ArgumentNullException, first iteration:

 Let's see how it works with an example:

public class ArgumentNullDummyClass
{
    public object ClassicMethod(Object nullable, Object notNullable, int valueType)
    {
        if (notNullable == null)
            throw new ArgumentNullException("notNullable");
        return String.Format("{0}{1}{2}",nullable,notNullable,valueType);
    }
}

As one can see, the nullable parameter can be null, while the notNullable parameter is tested. Now, let's create a fixture that tests this method. We will be using the TestSuiteFixture because we will build a TestSuite:

[TestSuiteFixture]
public class MethodTestSuiteDemo
{
    public delegate object MultiArgumentDelegate(Object o,Object b, int i);
    
    [TestSuite]
    public ITestSuite AutomaticClassicMethodSuite()
    {
        ArgumentNullDummyClass dummy = new ArgumentNullDummyClass();

        MethodTester suite = new MethodTester(
            "ClassicMethod",
            new MultiArgumentDelegate(dummy.ClassicMethod),
            "hello",
            "world",
            1
            );
            suite.AddAllThrowArgumentNull();
        return suite.Suite;
    }
}

The MethodTester class takes the following argument: a name, a delegate  and valid parameters of the delegate. By valid I mean parameters that should not make the delegate invokation fail. The AddAllThrowArgumentNull looks for nullable parameters and create a TestCase that will invoke the delegate with the corresponding parameter nulled. In the example, this means that ClassicMethod will be called with:

  • null, "world", 1
  • "hello", null, 1

Test for ArgumentNullException, second iteration:

There are things I don't like in the example above:

  • you need to create a delegate (tedious),
  • you need to create 1 method tester per method (tedious),

Ok, so let's build a ClassTester class that does that for us... The test code now looks as follows:

[TestSuiteFixture]
public class ClassTesterDemo
{
    [TestSuite]
    public ITestSuite AutomaticClassSuite()
    {
        ArgumentNullDummyClass dummy = new ArgumentNullDummyClass();
        ClassTester suite = new ClassTester("DummyClassTest",dummy);
        suite.Add("ClassicMethod","hello","world",1);
        return suite.Suite;
    }
}

That's much better: delegate is gone and we could add more methods to be tested in a single call.

Test for ArgumentNullException, third iteration:

There is still one problem with this technique: there is no way to tell that an argument is authorized to be nulled! In the example, the nullable parameter can be null and the TestCase will always fail because it does not throw ArgumentNullException.

The solution of this problem is done in two steps: first, you, the developper, tag the parameters that can be nulled with a NullableAttribute attribute (could be any of your attributes). In the example, we add a SmartMethod method and the MyNullableAttribute:

[AttributeUsage(AttributeTargets.Parameter,AllowMultiple=false,Inherited=true)]
public class MyNullableAttribute : Attribute
{}

public class ArgumentNullDummyClass
{
    public object ClassicMethod(Object nullable, Object notNullable, int valueType)
    {...}
    public object SmartMethod([MyNullable]Object nullable, Object notNullable, int valueType)
    {...}
}

Next, you must tell MbUnit which attribute is used to tag nullable parameters. This is done with the NullableAttributeAttribute at the assembly level:

[assembly: NullableAttribute(typeof(MbUnit.Demo.MyNullableAttribute))]

Ok, now we just need to update our test case to load the SmartMethod:

[TestSuite]
public ITestSuite AutomaticClassSuite()
{
    ArgumentNullDummyClass dummy = new ArgumentNullDummyClass();
    ClassTester suite = new ClassTester("DummyClassTest",dummy);

    suite.Add("ClassicMethod","hello","world",1);
    suite.Add("SmartMethod","hello","world",1);

    return suite.Suite;
}

The result in MbUnit GUI is as follows: the parameters of ClassicMethod were all tested, nullable included which we want to avoid. The parameters of SmartMethod were all tested excluded nullable because it was tagged. :)

Test for ArgumentNullException, fourth iteration:

 

The more I think about this problem, the more I think FxCop should do that for us...

posted on Wednesday, July 21, 2004 10:37:00 AM (Pacific Daylight Time, UTC-07:00)  #    Comments [0]

The API Design Guidelines encourage developers to check all their arguments and thereby avoid throwing a NullReferenceException.  If an argument is null and the contract of the method forbids null arguments an ArgumentNullException should be thrown. Brad Adams 

So you agree with Brad (I do) and you always check that arguments are not null before using them. This means a little bit more of code but it is worth it. But this means also a lot more of test code because, ideally, you should test that all your methods check all their arguments. This means writing hundreds of boring, repetitive test cases.... and you don't want to do that.

At least I don't so I added a new feature to MbUnit that does it for me.

Test for ArgumentNullException, first iteration:

 Let's see how it works with an example:

public class ArgumentNullDummyClass
{
    public object ClassicMethod(Object nullable, Object notNullable, int valueType)
    {
        if (notNullable == null)
            throw new ArgumentNullException("notNullable");
        return String.Format("{0}{1}{2}",nullable,notNullable,valueType);
    }
}

As one can see, the nullable parameter can be null, while the notNullable parameter is tested. Now, let's create a fixture that tests this method. We will be using the TestSuiteFixture because we will build a TestSuite:

[TestSuiteFixture]
public class MethodTestSuiteDemo
{
    public delegate object MultiArgumentDelegate(Object o,Object b, int i);
    
    [TestSuite]
    public ITestSuite AutomaticClassicMethodSuite()
    {
        ArgumentNullDummyClass dummy = new ArgumentNullDummyClass();

        MethodTester suite = new MethodTester(
            "ClassicMethod",
            new MultiArgumentDelegate(dummy.ClassicMethod),
            "hello",
            "world",
            1
            );
            suite.AddAllThrowArgumentNull();
        return suite.Suite;
    }
}

The MethodTester class takes the following argument: a name, a delegate  and valid parameters of the delegate. By valid I mean parameters that should not make the delegate invokation fail. The AddAllThrowArgumentNull looks for nullable parameters and create a TestCase that will invoke the delegate with the corresponding parameter nulled. In the example, this means that ClassicMethod will be called with:

  • null, "world", 1
  • "hello", null, 1

Test for ArgumentNullException, second iteration:

There are things I don't like in the example above:

  • you need to create a delegate (tedious),
  • you need to create 1 method tester per method (tedious),

Ok, so let's build a ClassTester class that does that for us... The test code now looks as follows:

[TestSuiteFixture]
public class ClassTesterDemo
{
    [TestSuite]
    public ITestSuite AutomaticClassSuite()
    {
        ArgumentNullDummyClass dummy = new ArgumentNullDummyClass();
        ClassTester suite = new ClassTester("DummyClassTest",dummy);
        suite.Add("ClassicMethod","hello","world",1);
        return suite.Suite;
    }
}

That's much better: delegate is gone and we could add more methods to be tested in a single call.

Test for ArgumentNullException, third iteration:

There is still one problem with this technique: there is no way to tell that an argument is authorized to be nulled! In the example, the nullable parameter can be null and the TestCase will always fail because it does not throw ArgumentNullException.

The solution of this problem is done in two steps: first, you, the developper, tag the parameters that can be nulled with a NullableAttribute attribute (could be any of your attributes). In the example, we add a SmartMethod method and the MyNullableAttribute:

[AttributeUsage(AttributeTargets.Parameter,AllowMultiple=false,Inherited=true)]
public class MyNullableAttribute : Attribute
{}

public class ArgumentNullDummyClass
{
    public object ClassicMethod(Object nullable, Object notNullable, int valueType)
    {...}
    public object SmartMethod([MyNullable]Object nullable, Object notNullable, int valueType)
    {...}
}

Next, you must tell MbUnit which attribute is used to tag nullable parameters. This is done with the NullableAttributeAttribute at the assembly level:

[assembly: NullableAttribute(typeof(MbUnit.Demo.MyNullableAttribute))]

Ok, now we just need to update our test case to load the SmartMethod:

[TestSuite]
public ITestSuite AutomaticClassSuite()
{
    ArgumentNullDummyClass dummy = new ArgumentNullDummyClass();
    ClassTester suite = new ClassTester("DummyClassTest",dummy);

    suite.Add("ClassicMethod","hello","world",1);
    suite.Add("SmartMethod","hello","world",1);

    return suite.Suite;
}

The result in MbUnit GUI is as follows: the parameters of ClassicMethod were all tested, nullable included which we want to avoid. The parameters of SmartMethod were all tested excluded nullable because it was tagged. :)

Test for ArgumentNullException, fourth iteration:

 

The more I think about this problem, the more I think FxCop should do that for us...

posted on Wednesday, July 21, 2004 10:37:00 AM (Pacific Daylight Time, UTC-07:00)  #    Comments [4]
# Tuesday, July 20, 2004

MbUnit now supports the new attributes for Roy Osherove (ISerializable) to solve the database Rollback problem:

  • SqlRestoreInfoAttribute contains the information necessary to perform database restore (connection string, etc...),
  • RollBackAttribute uses EnterpriseServices to roll back the transactions done in the test case, (Note that this attribute does not rely on SqlRestoreInfo and can live on its own)
  • RestoreDatabaseFirstAttribute, restores the database before starting the test (using DbAdministrator from TestFu).

I will assume that you have read the article from Roy so I can skip explanation and show an example. Consider the following test fixture:

[TestFixture]
[SqlRestoreInfo("connectionstring","databasename",@"c:\backups\nw.mbk")]
public class NorthWindTest
{
    [Test, RollBack]
    public void TestWithRollBack()
    {...}

    [Test, RestoreDatabaseFirst]
    public void TestWithRestoreFirst()
    {...}
}

This example, which runs in MbUnit,  is similar to what Roy has proposed: SqlRestoreInfo gives information that can be used to restore the db. TestWithRollBack is rolled back using Enterprise services, the database is restored before TestWithRestoreFirst is executed.

What about data abstraction ?

We would like to create a fixture and apply it to different Db provider (Oracle, MySql,etc..). Is this possible ? This is (will**) possible in a minimum of work, it is just a matter of changing SqlRestoreInfo to OracleRestoreInfo:

[TestFixture]
public abstract class DbNorthwindTest
{
    [Test, RollBack]
    public void TestWithRollBack()
    {...}

    [Test, RestoreDatabaseFirst]
    public void TestWithRestoreFirst()
    {...}
}

[SqlRestoreInfo("connectionstring","databasename",@"c:\backups\nw.mbk")]
public class SqlNorthwindTest : DbNorthwindTest
{}

[OracleRestoreInfo("connectionstring","databasename",@"c:\backups\nwporacle.mbk")]
public class OracleNorthwindTest : DbNorthwindTest
{}

This example is quite neat and self-explenatory: SqlNorthwindTest will apply the fixture against a MsSql server using System.Data.SqlClient classes, while OracleNorthwindTest will test against Oracle.

**Currently, only SqlRestoreInfoAttribute is implemented.

posted on Tuesday, July 20, 2004 1:51:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [22]