Brad Wilson

xUnit.net Moving to Git

Just a quick note: the xUnit.net source control repository is switching from Mercurial to Git on Friday the 13th of April. If you have outstanding forks or pull requests, please read this page for how this change will affect you.

http://xunit.codeplex.com/discussions/351482

Shipped: xUnit.net 1.9

On January 2nd, Jim and I shipped xUnit.net 1.9. We updated NuGet with the 1.9 build binaries, and for the first time, we're including the MSBuild runner inside the "xunit" NuGet package.

There are a few big new features that are worth calling out.

Prototype xUnit.net Visual Studio 11 Unit Testing Plugin

Update: Visual Studio 11 Beta is now available to the public. We've released the runner for xUnit.net for VS11 Beta in the Extension Gallery.

Update: Visual Studio 11 Developer Preview is now available to the public.

Earlier this week at the //build/ windows conference, Jason Zander announced the availability of a new "developer-focused" unit test runner in Visual Studio 11. They shipped the first Developer Preview of Visual Studio 11, and it includes this new unit test runner. Peter Provost demonstrated the pluggability of this new unit test runner by showing (and writing) tests written in xUnit.net. We collaborated with Peter and wrote the prototype runner that he used on stage during his demos.

Full Throttle TDD

I got a chance to sit down (virtually) with Rob Conery and do my TekPub production, which aimed to show what a real-world TDD session might look like. Rob gave me some vague requirements and then set me off to coding. I know the title says "Full Throttle", but it feels a little three-quarters-throttle to me, mostly because the business area was new to me, and I (purposefully) didn't spend much time thinking ahead about the problem. We wanted this to just be a fresh stab in the dark at implementing something that I knew next to nothing about ahead of time. So, if you're hoping for one of those super-speed katas, then this isn't quite the video for you.

Professional ASP.NET MVC 3

A few months ago, I finished writing part of a book on ASP.NET MVC 3. I was honored to be asked to write the third edition of the book with fellow co-workers Phil Haack and Jon Galloway, and incredibly smart dude K. Scott Allen. This is very good company to be in for a first-time author. :)

The first edition of this book was written by some very impressive people, and it got terrific reviews. The second edition was mostly the same as the first. We took the feedback from the 2nd edition and decided that potential customers would appreciate it if we re-examined the structure of the book and provide as much new content as possible.

The "Testable Object" Pattern

This is a republished blog post from 2007. You can tell it's old because the tests were in NUnit instead of xUnit.net. :)

I've demonstrated this a few times in presentations, and someone will inevitably ask for more information. Truth is, I don't remember when I came up with it, or where I might've been inspired for it. I should say up front that I don't believe in mock object frameworks (because they encourage white-box protocols), and I don't believe in [SetUp] and [TearDown] (because they hide intention and force the use of fields in test fixtures, which should be strongly discouraged).

Testing Routing and URL Generation in ASP.NET MVC

In ASP.NET MVC, getting your routes setup properly can be tricky if you have a lot of routes. Whenever something is tricky, and might be touched often, having a set of unit tests around it can very helpful to ensure you aren't breaking it when you make changes. Lots of routes can definitely qualify; your users rely on unbroken links and stable URLs for a good experience.

The techniques shown here not only work for unit testing, but can also be used outside of the ASP.NET pipeline when you need to interact with the routing system (for example, to generate URLs from a service). The routing system used by ASP.NET MVC uses the abstraction classes, so the actual running ASP.NET pipline isn't required.

What's New in xUnit.net 1.6

Yesterday we pushed the shiny red button to send you all the bits for xUnit.net 1.6. It turns out there were some interesting technical challenges behind the scenes, so after I do the obligatory feature list, I'll talk about all the work we did (and sometimes undid) along the way.

Working Around Build Error MSB3454

We recently moved the xUnit.net source over to Visual Studio 2010 (still targeting .NET 2.0, though). We do automated builds with TeamCity (the server is generously provided by CodeBetter and JetBrains for open source projects).

When we switched to VS 2010, we noticed that our automated build was failing with the following error:

C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1835, 9):
error MSB3454: Tracker.exe is required to correctly incrementally generate resources
in some circumstances, such as when building on a 64-bit OS using 32-bit MSBuild.
This build requires Tracker.exe, but it could not be found. The task is looking for
Tracker.exe beneath the InstallationFolder value of the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A. To solve the
problem, either: 1) Install the Microsoft Windows SDK v7.0A or later. 2) Install
Microsoft Visual Studio 2010. 3) Manually set the above registry key to the correct
location. Alternatively, you can turn off incremental resource generation by setting
the "TrackFileAccess" property to "false".

This error didn't occur on our development machines, because we have Visual Studio 2010 installed, but the CI machine only has the .NET Framework installed. While some people disagree, we are of the opinion (as are the CodeBetter guys) that Visual Studio is not something you should install on your CI machines.

We use an MSBuild file for our CI builds. We needed to make a simple change to the MSBuild file, where it calls the MSBuild task for our solution, to pass this new flag:

<MSBuild
    Projects="xunit.sln"
    Targets="Build"
    Properties="Configuration=$(Configuration);TrackFileAccess=false"/>

This made our build succeed (which solved our immediate problem), but I was curious what was going on. Luckily, some fellow Microsofties were able to clue me into exactly what was going on.

The resource compiler performance is dramatically improved by tracking files changes to your .resx files between builds; it's like incremental compilation from the C++ days, but for your resources. Getting this to work requires a tracker application to watch the file access, which is normally only part of the Windows SDK or Visual Studio.

Unfortunately, the Windows SDK isn't available for download yet for .NET 4. We are willing to accept builds that take a little longer than normal on the CI machine, until the CI machine can get the Windows SDK installed.

Hopefully this can help you get your .NET 4/VS2010 projects up and running on CI for the time being!

Writing an FxCop Task for MSBuild

The source code to the FxCop task is provided here.

I've been working on improving our processes on the ASP.NET MVC team, and one of the things that we wanted to do was have our continuous integration build run FxCop.

Unlike most of the teams inside of the Developer Division, we're actually building ASP.NET MVC on the released versions of Visual Studio. The division has a ton of custom-built tooling, but since we don't live in the same space as they do, we're using the same tools and techniques that you guys use.