A little while ago I was working on an example that demonstrates the TestDriven.NET extensibility model. It was an example of how to use the TestDriven.Framework.ITestRunner interface which enables native support for different unit testing engines. This is what NUnit, MbUnit and (soon) Zanebug use allow their test types to executed using TestDriven.NET. The Visual Studio Test Tools (VSTT) support uses a deeper extensibility interface which I'll discuss in a future post.
I started off by writing a minimal unit testing framework and enabling support for that. In the end I decided this was too boring and I should enable support for something a little different. This was when DuckUnit was hatched (sorry). DuckUnit allows you to mark methods as being tests using a simple XML documentation element. It also allows you to specify multiple rows of arguments and expected return results.
Remember it is just a sample at the moment. Simply open the project and run the example tests. It uses [assembly: CustomTestRunner(typeof(DuckUnit))] so that it knows to use a custom test runner (rather than one of the plug-in ones). This is an easy way to develop custom runners without having to worry about installing anything in the registry. I'll mention the registry entries another time.
Anders Norås discovered DuckUnit in my 'TestDriven' shared folder. Rather than duplicate what he said, you can read a little more about it and where he found it here.