# Friday, October 01, 2004

As you may have already understood it, MbUnit as well as QuickGraph, TestFu and Refly source code have been moved to the TestDriven.NET source control server. This means that the source in the Tigris CVS are outdated!

The reasons why...

There are 4 main reasons for moving to Jamie Cansdale servers. Subversion, TestDriven.NET integration and Continuous integration

1. Subversion

This is not a major reason for leaving tigris, but Subversion is much more handy to use that CVS.

2. TD.NET integration

When developing the MbUnit addin for TestDriven.NET, we faced problems of versioning. This usually meant loosing time synchronizing TD.NET and MbUnit source, etc... Having both sources in the same repository has considerably simplified things.

3. Continuous Integration

This is by far the most important reason for moving MbUnit. The build setup currently running on TD.NET servers uses CC.NET, MSBuild and Wix to compile, execute tests and produce an installer each build. As soon as Jamie fixes his ftp problems , the installer will be uploaded on the web server on each build.

This means that release time for MbUnit will considerably shorten while benefiting from the quality ensurance of continuous integration. Image that you file a bug, it is corrected and you have an updated installer within the day!

 

posted on Friday, October 01, 2004 10:55:00 AM (Pacific Daylight Time, UTC-07:00)  #    Comments [18]
# Thursday, September 30, 2004

MbUnit has been released as part of the new TestDriven.NET build. Please check Jamies blog for the links to the downloads. MbUnit is now compiled using a complex build setup that is described on Jamie's blog.

Change log

  • Assembly loading had problems in the previous version. All should be fixed now,
  • RollbackAttribute is back in a separate assembly (MbUnit.Framework.1.1.dll) compiled against .NET 1.1
  • Added Assembly Dependencies and Fixture dependencies
  • Better TD.NET integration

 

posted on Thursday, September 30, 2004 9:29:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [2]
I have stumbled on this web site: http://iv.slis.indiana.edu/index.html It has amazing examples of data visualization!
posted on Thursday, September 30, 2004 11:46:00 AM (Pacific Daylight Time, UTC-07:00)  #    Comments [1]
# Wednesday, September 29, 2004

FlexWiki is an evolved WikiWikiWeb implementation for .NET. It has an extensible internal language, called WikiTalk, that can be used to extend the framework with new behaviors. I'm currently exploring this framework with some nifty ideas... here's a first snapshot: a behavior that renders the graph of the pages (all the nodes are clickable)

 

posted on Wednesday, September 29, 2004 11:30:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [7]

Following the idea of Fixture dependency, I have added Assembly dependencies as well: execute tests from child assembly only if parents were successful.

Similarly, we use the AssemblyDependsOnAttribute to specify the parent assemblies:

[assembly: MbUnit.Core.Framework.AssemblyDependsOn("AnotherAssembly")]
posted on Wednesday, September 29, 2004 11:24:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [1]

MbUnit now supports setting dependencies between fixtures, similarly to NAnt/MSBuild task dependencies.

How-to

The logic is simple. You can tag a fixture with the DependsOnAttribute to specify a "parent" fixture that should be run before the current fixture. If the parent fixture fails, the current fixture is not run:

[TestFixture]
public class Parent
{...}

[TestFixture]
[DependsOn(typeof(Parent))]
public class Child
{...}

The Child fixture is executed if the Parent fixture executed successfully.

Why do we need dependencies between fixtures ?

Image that you are testing a database. At first, you create a fixture that tests that the connection is correct:

[TestFixture]
public class ConnectionTest
{ ... }

If one of the tests of ConnectionTest fails, then it is likely that all the tests that rely on a database connection will fail and, therefore, should not be executed. Using the DependsOnAttribute, you can specify the dependency of such fixture to the ConnectionFixture.

[TestFixture]
[DependsOn(typeof(Connection))]
public class DALTest
{...}

An example

The following example defines 4 fixture. Child depends on Parent and SickParent, GrandChild depends on Child. Since SickParent has a failed test, Child and GrandChild should not be executed...

[TestFixture]
[CurrentFixture]
public class Parent
{
    [Test]
    public void Success()
    {}
}

[TestFixture]
[CurrentFixture]
public class SickParent
{
    [Test]
    public void Failure()
    {
        throw new Exception("boom");
    }
}

[TestFixture]
[CurrentFixture]
[DependsOn(typeof(Parent))]
[DependsOn(typeof(SickParent))]
public class Child
{
    [Test]
    public void Success()
    {
    }
}

[TestFixture]
[CurrentFixture]
[DependsOn(typeof(Child))]
public class GrandChild
{
    [Test]
    public void Success()
    {}
}

The report result is shown below and one can see that Child and GrandChild fixture have failed without being executed.

posted on Wednesday, September 29, 2004 7:00:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [10]
After 4 years working in CESAME, I finally graduated as Doctor in Applied Mathematics :)
posted on Wednesday, September 29, 2004 10:42:00 AM (Pacific Daylight Time, UTC-07:00)  #    Comments [23]
# Friday, September 24, 2004

MbUnit has now the ability of re-executing the failed tests cases and ignoring the successful tests.  A test case filter loads the previous XML result from a file and filters all the fixture that have not failed.

QuickStart example

This is the main function of MbUnit.Demo. We use the AutoRunner to make an assembly that is self-executable and we set the special filter (FailureRunPipeFilter). This filter will try to load the previous report. If it finds it, it will use the information to ignore successfull tests.

public static void Main(string[] args)

{

using (AutoRunner auto = new AutoRunner())

{

// creating the report name

string reportName = Path.GetFullPath(String.Format("{0}.xml", auto.GetReportName()));

 

FailureRunPipeFilter filter = new FailureRunPipeFilter(reportName);

auto.Domain.RunPipeFilter = filter;

 

auto.Run();

auto.ReportToHtml();

auto.ReportToXml(false);

}

}

Results:

I have executed twice MbUnit.Demo (don't be afraid about the number of failures, they are intentional, it's a demo!) The first report shows the first run result and second shows the second run report... Abracadadra, only failed tests remain

posted on Friday, September 24, 2004 2:31:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [1]
# Thursday, September 23, 2004

This is a preview of a new language for Reflector that outputs to Refly (Refly is wraps up and simplifies the use of CodeDom).

What does the language do ?

The language creates Refly code. If the Refly code is executed it will generate the original code. This is particularly usefull to rapidely design CodeDom template: write the expected output, Reflectorize-it and get the Refly code. In the figure below, we see the code "cycle of life" with a decompiler and how it is modified if we add the "Refly" language.

A preview example

There is still a lot of work to do on the language but it can already generate the outline of classes. Let's see that on a simple class:

public class Original

{

private string name;

public Original()

{}

public string Name

{

get { return this.name;}

set { this.name = value;}

}

public void Run(string someParamter)

{

Console.WriteLine("{0}: someParameter");

}

public event EventHandler Click;

protected virtual void OnClick(EventArgs e)

{

if (this.Click != null)

this.Click(this, e);

}

}

After compiling and  loading in Reflector, the Refly language is outputting:

NamespaceDeclaration _dragAndDropUnitTesting = new NamespaceDeclaration("Original");

 

ClassDeclaration _original = _dragAndDropUnitTesting.AddClass("Original");

 

// Fields

FieldDeclaration name = _original.AddField(typeof(System.String), "name");

FieldDeclaration Click = _original.AddField(typeof(System.EventHandler), "Click");

 

// Events

EventDeclaration _click = _original.AddEvent(typeof(System.EventHandler), "Click");

 

// Constructor and Methods

ConstructorDeclaration ctor0 = _original.AddConstructor();

ctor0.Attributes |= System.CodeDom.MemberAttributes.Assembly;

ctor0.Attributes |= System.CodeDom.MemberAttributes.Family;

MethodDeclaration _run = _original.AddMethod("Run");

_run.Attributes |= System.CodeDom.MemberAttributes.Assembly;

_run.Attributes |= System.CodeDom.MemberAttributes.Family;

ParameterDeclaration _runsomeParamter = _run.Signature.Parameters.Add(typeof(System.String), "someParamter");

MethodDeclaration _onClick = _original.AddMethod("OnClick");

_onClick.Attributes |= System.CodeDom.MemberAttributes.Family;

ParameterDeclaration _onClicke = _onClick.Signature.Parameters.Add(typeof(System.EventArgs), "e");

 

// Properties

PropertyDeclaration _name = _original.AddProperty(typeof(System.String), "Name");

 

That's pretty ugly but not as much if you had to write CodeDom for that. We can compile and generate the code using the following instruction:

CodeGenerator gen = new CodeGenerator();
gen.GenerateCode(".", _dragAndDropUnitTesting);

Finally, the output of the execution is as follows:

using System;

/// <summary />

/// <remarks />

public class Original

{

/// <summary />

/// <remarks />

private string _name;

/// <summary />

/// <remarks />

private System.EventHandler _click;

/// <summary />

/// <remarks />

Original()

{

}

/// <summary />

/// <remarks />

public virtual string Name

{

}

/// <summary />

/// <remarks />

public event System.EventHandler Click;

/// <summary />

/// <remarks />

void Run(string someParamter)

{

}

/// <summary />

/// <remarks />

void OnClick(System.EventArgs e)

{

}

}

Of course, the result is far from behing perfect. Visibility handling sucks, statements are not reflected, etc... But sounds very promising to me :)

posted on Thursday, September 23, 2004 12:30:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [11]
Just sent the manuscript of the my thesis to the printer... One last step (public presentation) and I'm free!
posted on Thursday, September 23, 2004 8:17:00 AM (Pacific Daylight Time, UTC-07:00)  #    Comments [6]