posted on Wednesday, December 07, 2005 6:29 PM
by
anoras
DuckUnit
Some weeks ago I downloaded the new beta of Test Driven .NET. As you might know the beta is available through Folder Share, which basically is a peer to peer network. Trying to support Jamie’s excellent tool I kept the share open to help distribute Test Driven .NET. A cool side-effect from this is that I automatically get all the latest files downloaded to my computer. I’ve got my shared folder in a sub folder beneath My Documents, and my information client of choice; Jet Brains’ excellent Omea Pro keeps track of changes to files in My Documents. Earlier today I noticed that a mysterious, new folder named DuckUnit had appeared. When I opened the folder to take a closer look at what it was I discovered the creator of Test Driven .NET, Jamie Cansdale was up to something again. DuckUnit is a testing framework that let’s you specify units test by applying a custom XML code comment named test to your methods. For example:
/// <test x="1" y="2" z="3">6</test>
public int Sum(int x, int y, int z)
{
return x + y + z;
}
The attributes correspond to the arguments of the method, and the inner text of the element to the expected result. The framework also lets you define your test data in separate XML documents, using the standard include directive:
/// <include file="PrimeTests.xml" path="tests/test/" />
static bool IsPrime(int num)
{
int max = (int)Math.Sqrt(num) + 1;
for (int count = 2; count < max; count++)
{
if (num % count == 0) return false;
}
return true;
}The need to have some arbitrary test data to use within your unit tests is common. Usually I’ve restored to having DataSets with test data or serialized mock objects stored as XML within my test projects. I really like the idea of being able to inject test data into my unit tests in a declarative fashion. Especially when you can use the include statement to separate the test data from the actual test. I’d really like to see some examples of how to use more complex types as arguments for the test methods, but a primitives only solution is a good start. Maybe parameterless unit test soon will be a relic of days gone by?