# Friday, October 08, 2004

PDFizer: A XHTML to PDF converter: with this library, you can transform simple XHTML pages to nice and printable PDF files. This project is based on the excellent webzine article "Pdfizer, a dumb HTML to PDF converter, in C#" written by Jonathan de Halleux.

Cool, my PDFizer project has been resurected. If you are looking for an easy way to convert HTML pages into PDF, you might well be interrested by that one.

posted on Friday, October 08, 2004 9:12:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [3]
# Tuesday, October 05, 2004

MutantBuild is the back bone behind TestDriven.NET / MbUnit compilation. Jamie Cansdale has published an installer that will let you play with it. Anybody automating VS.NET solution should have a look at this.

posted on Tuesday, October 05, 2004 1:14:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [4]
# Monday, October 04, 2004

Sometimes, a unit test does not fail but does not succeed entirely: making it fail is too extreme and on the other hand, letting him succeed would make you miss the issue. Therefore, MbUnit now supports warnings:

  • A warning can be emited in any test case using Assert.Warning methods,
  • A warning does not make test fail,
  • Warnings are recorded in the test report (in the Html report, they are displayed right after the fixture summary),
  • Multiple warnings can be outputed per test

QuickStart

This fixture shows 2 tests with warnings:

using System;

using MbUnit.Core.Framework;

using MbUnit.Framework;

namespace MbUnit.Demo

{

[TestFixture]

public class WarningTest

{

[Test]

public void Warning()

{

Assert.Warning("Be wary");

}

[Test]

public void Warning2()

{

Assert.Warning("Something weird happened");

}

}

}

The corresponding html report looks like this:

posted on Monday, October 04, 2004 10:42:00 AM (Pacific Daylight Time, UTC-07:00)  #    Comments [3]
# Sunday, October 03, 2004

This is the last entry on my dev box before I pack it and send to the US Do not expect much responsivness during the 2 next weeks until I get it back.

posted on Sunday, October 03, 2004 1:29:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [3]
# 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]