Agile

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.

Call for Presentations: Agile 2008

Brad Wilson — Sun, 11 Nov 2007 08:58:00 GMT

Mitch has posted the Call for Presentations for Agile 2008 in Toronto next summer.

I went to Agile 2006, mostly because I was presenting (and there, mostly because Mitch came in at the 11th hour and shepherded the process along). While I sincerely enjoyed presenting, many of us lamented that something seemed to be missing from the conference. Peter summed it up best by saying that the soul -- the Zen -- of agility seemed to be missing. Everybody was talking about the mechanics, but nobody was talking about the organics.

I didn't go to Agile 2007, partly because of that and partly because I was "saving" up my big trip for the PDC that never materialized. I'm thinking about trying to create a talk about agile philosophy for this year, but I'm not quite sure what I want to say. This blog post by Jonathan Edwards about Beautiful Code has been stewing in my brain for several months now...

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

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!

Going to ALT.NET

Brad Wilson — Sat, 22 Sep 2007 15:20:00 GMT

After the xUnit.net announcement, a few people asked me whether I'd be at ALT.NET. I had originally said "no", but plans have changed! I'll be there.

I'm staying in the recommended hotel (Holiday Inn Northwest Plaza). I'm hoping there will be plenty of impromptu beer-fueled discussions after hours. :)

Answering xUnit.net Questions

Brad Wilson — Fri, 21 Sep 2007 23:34:00 GMT

I have a feeling we're going to be spending a few days answering all the inevitable questions that come up about xUnit.net. :)

A common theme of comments comes about the simplicity of the framework, some seeing this as a positive and some as a negative. This is definitely a design criteria for us. We're not trying to replicate every single attribute and assertion that the existing frameworks have, but rather use 5 years of experience to help us design something slightly different and new.

The first set come from Roy Osherove. Here are his questions, along with our answers:

There is no Assert.Fail (overlooked? I find this very usable in some instances) We didn't overlook this, actually. I find Assert.Fail is a crutch which implies that there is probably an assertion missing. Sometimes it's just the way the test is structured, and sometimes it's because Assert could use another assertion. We've seen Assert grow over time in many of the unit testing frameworks, so rather than letting Assert.Fail be a crutch, it's better to hear about what those missing methods on Assert might be. I've used Assert.Fail a lot in NUnit, but I haven't missed it once in xUnit.net.

There is currently only a console runner. But there is already shipping TestDriven.NET support as part of the download! just run xunit.tdnet.installer.exe that is next to the xunit.framework.dll This, too, was a conscious decision. Those are the two runners we use most (console for automated builds, and in-Visual-Studio test runs with TD.NET during development). We have two open issues on the xUnit.net issue tracker about adding a GUI runner and a Resharper runner, to see how many votes they'll get. We'd also encourage people to open bugs for other runners that might be useful.

Assert.Equals is deprecated and ou are instructed to use a generic version of Assert.Equal (without the 's') / I think this is a problem because generics make the Assert code longer to write and read while giving little contribution to the developer of the tests. Actually, the "Equals" method is part of Object, and it's not an assertion. We added the deprecated attribute to it so nobody would accidentally call it. Plus, the generic version of Equal does not actually require you to provide the type if it can be inferred, as I talked about in my last post.

There is no built in Mocking framework There's really no reason to build in a mocking framework, as they shouldn't be tied to any specific unit testing framework. Myself, I prefer to hand write stubs (though I have used both RhinoMocks and NMock).

Assert.Equal on two strings, if it fails, does not add that nice little touch of visual that Nunit has that shwos you with an ascii arrow "----^" where the strings differ first Yep, we could add this. Write a feature request! :)

There is no Setup and teardown This is one of those controversial decisions that will probably really get people talking. You can use constructors and IDisposable.Dispose() where you would've used SetUp and TearDown, so it's not that the functionality is completely gone. However, we do feel strongly against using it (and instead using the cross-cutting concerns system that we've added for extensibility purposes instead for common things like auto-rollback on database tests).

There is still no solution for what happens if mutiple custom test attributes need to be run in a specific order. True, we don't address this, and we would prefer not to. The cross-cutting concerns attributes should operate independent of one another; if there is a dependency, then wrap up the combined behavior into a new, single attribute. The complexity involved with setting ordering is very unlikely to be worth the effort to understand and implement it.

No Expected exception attribute. use try-catch or Assert.Throws, I find that less readable. Experience has really borne this one out for me. Consider, for example, your typical mock framework which requires you to call things like "mocks.VerifyAllExpectations()". When using ExpectedException, it's very easy to overlook the fact that this method never gets called, and your mocks aren't necessarily providing you with the safety you think they are. In addition, Assert.Throws allows you to inspect the exception object and run further asserts on it, something that ExpectedException does not do.

From looking at the source code, it shoudl be able to also run NUnit tests (backwards compatible) We're working on separate Wiki content (and a blog post) which will address specifically how to migrate from NUnit to xUnit.net using the [RunWithNUnit] attribute.

Lots of great feedback so far. Keep it coming, everybody!

Implicit generics

Brad Wilson — Fri, 21 Sep 2007 22:45:00 GMT

One of the very first questions we've seen regarding xUnit.net's Assert.Equal<> syntax is regarding the necessity of the generics. I've seen people write things like:

Assert.Equal<string>("foo", someValue);

If someValue is a string (and we know "foo" is), the generic parameter is actually unnecessary. You can simply write:

Assert.Equal("foo", someValue);

The compiler can automatically determine the generic parameter type implicitly for you. In fact, if you run Resharper, it'll even help you out with the former line by marking the "<string>" bit in grey and offering to remove it for you, since it's redundant and unnecessary.