Geeks With Blogs

News Disclaimer
The views expressed on this weblog are mine and do not necessarily reflect the views of my employer.

All postings are provided "AS IS" with no warranties, and confer no rights.

 Subscribe in a reader

I'm test-driven!
Locations of visitors to this page
Blog Moved to Blog Moved to
UPDATE: More posts on the subject

UPDATE: xUnit.NET RC2 New Drop includes ASP.NET MVC support and better GUI runner.  Details here.
UPDATE: Added Static Methods mention and F# - Thanks to DevHawk!

I've been a big fan of such testing frameworks as NUnit and MbUnit, but recently I've found myself getting pulled more towards at least to play around with for any of my code samples that I write for this blog and on my own time.  I'm not really a fan of MSTest and many I think would agree about its deficiencies.  I won't go as far as say Jay Flowers and wear the shirt though...

Another Release?

Recently, Brad Wilson and Jim Newkirk recently announced the release of RC2 on CodePlex.  I'd encourage you download the latest bits here.  For those wondering what changes happened between RC1 and RC2, Brad has a good writeup on his blog here.  What's interesting about this is the removal of the Assert class methods which take a user defined message should it fail.  I was never really a fan of those in the first place though. 

Another interesting added features was the IUserFixture<T> which allows you to have a startup and teardown for your fixtures in a separate class and therefore reusable, unlike the current way of using no parameter constructors as your startup and the IDisposable.Dispose for your teardown.  See the tests in the FixtureExample for details.  But here's a snipped version of that code:

    public class DatabaseFixture : IDisposable


        SqlConnection connection;

        int fooUserID;


        public DatabaseFixture()


            string connectionString = ConfigurationManager.ConnectionStrings["DatabaseFixture"].ConnectionString;

            connection = new SqlConnection(connectionString);


            string sql = @"INSERT INTO Users VALUES ('foo', 'bar'); SELECT SCOPE_IDENTITY();";


            using (SqlCommand cmd = new SqlCommand(sql, connection))

                fooUserID = Convert.ToInt32(cmd.ExecuteScalar());



        public SqlConnection Connection


            get { return connection; }



        public int FooUserID


            get { return fooUserID; }



        public void Dispose()


            string sql = @"DELETE FROM Users WHERE ID = @id;";


            using (SqlCommand cmd = new SqlCommand(sql, connection))


                cmd.Parameters.AddWithValue("@id", fooUserID);







What the above code allows us to do is to define a class that holds the data from the initialization of the first test, to the cleanup after the last test.  Our state is therefore maintained in a reusable manner.  As you will note, the startup logic resides in the default no parameter constructor and all teardown logic is in the IDisposable.Dispose method.

    public class FixtureTests : IUseFixture<DatabaseFixture>


        DatabaseFixture database;


        public void SetFixture(DatabaseFixture data)


            database = data;




        public void FooUserWasInserted()


            string sql = "SELECT COUNT(*) FROM Users WHERE ID = @id;";


            using (SqlCommand cmd = new SqlCommand(sql, database.Connection))


                cmd.Parameters.AddWithValue("@id", database.FooUserID);

                int rowCount = Convert.ToInt32(cmd.ExecuteScalar());

                Assert.Equal(1, rowCount);




Then we can go ahead with our tests, while using the SqlConnection as defined on our DatabaseFixture.  After we're done with our test, it goes ahead and calls Dispose on the fixture.  I tend to like this approach and it's definitely growing on me.


For those new to, there are some decent links to help you along.  Some of the more interesting ones can be found here:
But, why am I interested in it?  Well, let's just say that I think it tackles things in a slightly different manner.  I think one of the key pieces that I really like is the Assert.Throws instead of the clumsy ExpectedExceptionAttribute which you must clutter your tests with on the top.  I would rather assert that such a thing happened programmatically, so that I may analyze the exception.  I can also specify which line I expect during my test will throw the exception, instead of taking on blind faith that my test threw an exception.  It may be of the right type, but that may not have been the one you wanted, thus giving a false sense of security.

To use this, just simply use the Assert.Throws<TException>(Assert.ThrowsDelegate) which I've found to be very helpful.  Let's look at a quick test of that being used.


    public void PopEmptyStack()


        Stack<string> stack = new Stack<string>();

        Assert.Throws<InvalidOperationException>(() => stack.Pop());


As you can see, we're pretty explicit about what line will throw the exception, and that's really the key to this scenario.  There are a good number of samples provided on the releases page that you should check out.  As always with most products that I talk about, I highly recommend reading the tests to really fully understand what's going on underneath the covers.  Not only does it help you understand the intent of the program, but you can learn about good coding techniques, design patterns, testing patterns and so on.

Another point that separates itself from the pack is the ability to decorate static methods as facts.  This frees you from having to create an instance of your test class in order to call them.  Harry Pierson, aka DevHawk, demonstrates its use with regards to F# and testing the parse buffer here.  It definitely opened my eyes and a few more avenues as I pursue more F# related work items in the future.  Here's just a quick and dirty sample of showing how you can use with F# quite easily, just as Harry's post did.


#R @"E:\Tools\xunit-build-1223-samples\Samples\xunit\xunit.dll"

open System
open System.Collections.Generic
open Xunit

type Stack<'t> = class
  val elements : LinkedList<'t>
  new() = { elements = new LinkedList<'t>() }
  member x.IsEmpty
    with get() = x.elements.Count = 0
  member x.Push element =
  member x.Top
    with get() =
      if x.elements.Count = 0 then
        raise (InvalidOperationException("cannot top an empty stack"))
  member x.Pop =
    let top = x.Top

let NoElementsShouldBeEmpty () =
  let stack = new Stack<string>()

If you notice, the FactAttribute is placed on a static method called NoElementsShouldBeEmpty and sure enough it works like a champ through  I like this approach instead of the pomp and circumstance required for creating classes as shown above with my Stack class.  Note the use of the empty parans which forces it to be a void method with no values passed either.  But if you run it through the xunit.console sure enough it succeeds like a champ.

What are we missing though?  Well, I'm in favor of having a standalone GUI Test Runner much like NUnit and MbUnit have.  In fact, Brad has started this and you can get these features from the latest commits here.  Mind you I haven't gotten it to work just right yet, but it's a work in progress.


There is a lot to like about and takes a lot of lessons learned from the use of NUnit, MbUnit and others and I think they're doing a good job incorporating issues.  This project isn't as active as MbUnit and NUnit, but it's definitely one to keep an eye on.  Recent releases of NUnit and Gallio Automation Platform will probably be also covered in the short while as well as they have a lot to offer.  Until next time...

kick it on Posted on Monday, March 31, 2008 7:31 PM .NET , Test Driven Development , Behavior Driven Development , F# | Back to top

Comments on this post: RC2 Released

# re: RC2 Released
Requesting Gravatar...
I am trying to use Hudson with (and also CruissControl). Does hudson support
Left by Patricio on Jul 29, 2008 3:00 PM

Your comment:
 (will show your gravatar)

Copyright © Matthew Podwysocki | Powered by: