xUnit.net

xUnit.net RC1 Released Today

Brad Wilson — Tue, 18 Dec 2007 15:44:00 GMT

We (Jim Newkirk and myself) just shipped up the ZIP files for the first (and hopefully only) release candidate for xUnit.net today. This marks the first release where we've split the core of xUnit.net (which is xunit.dll and xunit.console.exe) from the rest of the xUnit.net extensions.

While there is a download available for the xUnit.net RC1 release, you probably want to download the December 2007 Extensions for xUnit.net RC1 release instead. It includes all the bits that are in the xUnit.net RC1 release, plus all the extension bits (such as the TD.NET runner, Resharper runner, etc.).

Our current plan, assuming there is no feedback about major bugs or missing functionality, is to release v1 in January.

What's new in xUnit.net RC1

Documentation! We've provided a .chm file with the xUnit.net API documentation, in both the xUnit.net binary download as well as a stand-alone download (for those evaluating xUnit.net).
Removed the "static" declaration from the Assert class. This won't change the usage of Assert, but does allow you to derive from Assert to create your own custom assertions.
Support static test methods, which makes xUnit.net easily usable from F# (see Harry Pierson's blog post for more information).
The console runner now runs in the STA so that xUnit.net can be used for web testing.
There are a few more... see the release for more information.

What's new in December 2007 Extensions

BREAKING CHANGE! The theory data attributes were renamed from DataViaXxx to XxxData (i.e., DataViaProperty is now called PropertyData). We also added InlineData, which works much like the RowTest attribute from MbUnit. A [Theory] method can have multiple Data attributes associated with it, and they are all utilized.
Added AssumeIdentity extension
Added FrozenClock extension
Added Trace extension
Updated to support Resharper 3.1 EAP and x64 machines

Class "static" Decorator: Unintended Consequences

Brad Wilson — Wed, 05 Dec 2007 07:51:00 GMT

If a class contains nothing but static members and methods, you can decorate the class with the "static" keyword. The purpose of the keyword is ostensibly as a form of documentation: this class has no instance data or methods, so therefore, you cannot "new" one of them up. Seems like an entirely reasonable thing to do. We did exactly that with the Assert class in xUnit.net.

Unfortunately, it also has two (IMO unnecessary) side-effects: a static class is always sealed, and cannot derive from another class.

What this means is: if you have a static class, it cannot extend, and it cannot be extended. And since the new extension methods feature in C# 3.0 can only add instance methods and not static methods, you're kinda stuck.

Just to be clear, this works fine:

public class StaticBase
{
    public static void This() { }
}

public class StaticDerived : StaticBase
{
    public static void That() { }
}

But this doesn't:

public static class StaticBase
{
    public static void This() { }
}

public static class StaticDerived : StaticBase
{
    public static void That() { }
}

Luckily, we caught this before we released xUnit.net 1.0. We're going to remove the static class decorator from Assert so that you can make your own Assert extensions class. The usage of Assert will not change, since the methods are all still static.

[FreezeClock] xUnit.net Extension

Brad Wilson — Sun, 11 Nov 2007 10:56:00 GMT

I've just checked in my [FreezeClock] extension into xUnit.net Extensions project, the source for which is available right now in source form in change set 7544. This is a simplified version of a similar Clock class that we use internally in the CodePlex code itself.

The idea behind [FreezeClock] is simple. Rather than using DateTime.Now, DateTime.UtcNow, or DateTime.Today, instead you use Clock.Now, Clock.UtcNow, and Clock.Today. During normal operation, these Clock operations are just simple forwards on to their DateTime counterparts. (The Clock class is provided as part of the extension, in the XunitExt namespace.)

You can freeze the clock by calling one of Clock's FreezeXxx() methods. Then, until you call Thaw(), all the calls to Clock.Now, Clock.UtcNow, and Clock.Local will use the frozen values. The reason here is for testing purposes: when you have a frozen and consistent time, it makes comparisons against expected values much simpler, because you don't have an introduce "slop" into the comparison to take into the account the execution time of the test code.

In addition to the Clock class, the extension introduces an AOP-style before/after attribute that you can apply to your tests to automatically freeze and thaw the clock for you. For example:

[Fact, FreezeClock]

public void FrozenWithCurrentTime()

    DateTime result1 = Clock.Now;

    Thread.Sleep(100);

    DateTime result2 = Clock.Now;

    Assert.Equal(result1, result2);

Don't forget that the implications of date/time management also extend beyond your code. For example, when using this system, if you need to test dates & times that are placed into your database that are based on the current date & time, those values need to come from your .NET code (specifically, calling Clock.Now and friends) rather than using the date/time functions built into your database to populate those field values.

Make sure to check out all the unit and acceptance tests to see how the classes work. For further discussion, please visit the corresponding Forum Post.

Calling All xUnit.net Extenders!

Brad Wilson — Sat, 10 Nov 2007 09:44:00 GMT

We're rapidly approaching the point where we want to finalize what's going into the 1.0 version of xUnit.net.

I know we made lots of big changes from Beta 1 to Beta 2. We felt like these changes, while somewhat disrupting, provided a better foundation for xUnit.net going forward. We're not planning any more big sweeping changes; our feature & issue list for the proposed Release Candidate 1 is still relatively small.

You may have also noticed that we removed much of the source code from the xUnit.net project itself. All that remains is the source to xunit.dll and xunit.console.exe (and the associated unit tests). The rest of the source code -- including the TestDriven.NET and Resharper runners -- has been moved to the xUnit.net Extensions project. The Extensions project will issue releases at the same time as the xUnit project, with the first release being extensions suitable for use with RC1.

By keeping a tight core with well-defined and well-used extension points, we're hoping that releases of xUnit.net itself will be very infrequent; ideally, we release 1.0 and never have to release again. Ideally. :)

We believe that most of the activity will move to the xUnit.net Extensions project, hopefully with many community contributions, both inside and outside of Microsoft. Yes, we are planning to accept community contributions!

The call to action today, then, is two-fold.

First, if you think there are any missing features and/or outstanding bugs in the core of xUnit.net itself (that is, in xunit.dll and the console runner xunit.console.exe), now is the time to speak up. If you haven't already, please start using Beta 2 and let us know what's missing from the core.

Second, there is an open issue for the Release Candidate titled Flesh out ITypeInfo, IMethodInfo, IAttributeInfo. These three interfaces are used within the runner infrastructure to determine which classes contain tests, which methods are tests, and which attributes they are decorated with.

These interfaces aren't nearly as full featured as their reflection counterparts. They contain just enough information for the xUnit.net runner infrastructure to be able to inspect and run our own test types (plus our NUnit extension, [RunWithNUnit]). Since these interfaces are defined in the core xunit.dll library, we'd like to know which things are missing from them that would be required by extenders.

Specifically:

People implementing ITestClassCommand (for [RunWith()] support) will likely be using all three
People implementing custom test types (deriving from [Fact] and/or implementing ITestCommand) will likely be using IMethodInfo and IAttributeInfo

If you're planning to do either of these activities, we'd love for feedback on these interfaces.

For existing implementations of these interfaces, there is a reflection wrapper inside of xunit.csproj (in Reflector.cs) and several Resharper wrappers in xunitext.runner.jetbrains.csproj (in TypeWrapper.cs, MethodWrapper.cs, and AttributeWrapper.cs).

If you have feedback on anything regarding the xUnit.net 1.0 RC1, and especially around these three interfaces, please use the xUnit.net forums for discussions. If you need to contact me directly, please use my CodePlex Contact Page.

Thanks, and happy extending!

xUnit.net Beta 2 Released

Brad Wilson — Thu, 25 Oct 2007 11:58:00 GMT

We just pushed the button to ship beta 2 of xUnit.net.

There are a lot of breaking changes enumerated in this forum post, so please read before upgrading. Most of the changes affect consumers of the xUnit SDK, but there are a few that affect users as well. The following issues and features were added or addresses in beta 2:

Technorati Tags: xUnit.net , Unit Testing

xUnit.net Changes for Beta 2

Brad Wilson — Sun, 21 Oct 2007 00:41:00 GMT

We just pushed up a lengthy forum post regarding the changes coming in Beta 2 for xUnit.net. There are quite a few high impact changes, so if you're using xUnit.net, it would be worth reviewing the post in preparation.

It is our hope to post the Beta 2 bits sometime in the next week. For those who are anxious to start looking at the changes, the trunk of the source tree has most of the changes in it already, including all those listed in the forum post.

I personally want to thank everybody who helped contribute with feedback on Beta 1 (there are too many to list). Please keep the feedback coming!

p&p Summit, Redmond WA, Nov 5-9

Brad Wilson — Sat, 20 Oct 2007 18:27:00 GMT

It's hard to believe that another p&p Summit is almost here... the time has really flown by. This year I'll be co-presenting twice. The line-up of keynote talks looks positively awesome this year! (Despite Scott Hansleman's protestations to the contrary, he does belong in that group of intelligent and talented people. ;)

The first talk, "Yet another agile talk on agility", is one where Peter and I will answer questions from the audience about our experiences running agile teams, inside and outside of Microsoft. We run the talk just like an agile project, a technique that I first saw used by Brian Button. You start by creating an initial backlog (i.e., people ask questions and you write them down), then you go through an iterative stack-ranking and execution (i.e., answer them) process with time-boxed iterations (i.e., 5 minutes). It's pretty interesting process and never yields the same talk twice. It's also awesome in its ability to require no prepartion. ;)

The second talk, "Dependency Injection Frameworks", is one where Scott and I will talk about the work we've done evolving ObjectBuilder 2.0, as well as some sample containers that we have on the ObjectBuilder CodePlex project space. A lot of the work there has come from real container needs in the wild, and some of the concerns about the complicated architecture of ObjectBuilder 1.0 have been addressed. In addition to our new containers and new architecture, we'll show off some of the new core features we've added, including a lightweight version of the CAB EventBroker and a method-interception system modeled after Enterprise Library's Policy Injection App Block.

I'm trying to make a commitment to be there all through the first 3 days so that people can sideline me both before and after the talks. Unfortunately, I won't be able to be there for the last 2 days. If you're going to be there, and want to talk about any of the projects I've got going on right now (CodePlex, ObjectBuilder, xUnit.net, etc.) please don't hesitate to find me. You can also use the Contact page here on the blog if you want to make sure I find time for you.

Hope to see you there!

Seattle Code Camp v3.0 - Nov 17 & 18

Brad Wilson — Mon, 15 Oct 2007 20:20:00 GMT

Seattle Code Camp is back! More information.

Update: Looks like it's been pushed back a couple weeks due to conflicts, and is now November 17 & 18.

The Irony of ALT.NET

Brad Wilson — Tue, 09 Oct 2007 18:57:00 GMT

I spent this past weekend at the inaugural ALT.NET conference in Austin. It was a great time, and I loved hanging out with everybody.

I can't help but point out an irony, though: for a group of people who revel in alternatives, they seemed to be questioning our alternative unit testing framework an awful lot. ;)

Weaving with xUnit.net

Brad Wilson — Thu, 27 Sep 2007 07:09:00 GMT

One of the more interesting features we added to xUnit.net was support for "before/after test" code in the form of an attribute. It feels a bit like method weaving in AOP. Our first example of this was the [AutoRollback] attribute that we shipped in xunit.extensions.dll.

Another one we'll do for CodePlex is one I call [FreezeClock], which uses our internal Clock class (a testable replacement for DateTime) which supports the concept of freezing the clock at a moment in time, and then unfreezing when the test is over. This is useful to ensure, for example, that some code under test is calling "Clock.Now", so that you can actually test the value they pushed in some arbitrary amount of time later by simply calling "Clock.Now" again. When we get around to doing that one, I'll make a blog post which shows the Clock class as well as our attribute.

This morning I woke up to find Casper had blogged a third one: [AssumeIdentity]. This little gem will override the principal on the current thread with a generic identity with the name you give it. Sweet and simple.

public class AssumeIdentityAttribute : BeforeAfterTestAttribute
{
    public AssumeIdentityAttribute(string name)
    {
        this.name = name;
    }

    public override void Before(MethodInfo methodUnderTest)
    {
        originalPrincipal = Thread.CurrentPrincipal;
        GenericIdentity identity = new GenericIdentity("boo");
        GenericPrincipal principal =
                new GenericPrincipal(identity, new string[] { name });
        Thread.CurrentPrincipal = principal;
    }

    public override void After(MethodInfo methodUnderTest)
    {
        Thread.CurrentPrincipal = originalPrincipal;
    }

    readonly string name;
    IPrincipal originalPrincipal;
}

I suspect there are a lot of these little cross-cutting concern attributes waiting to be written (and shared). :)