xUnit.net RC2 Released

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 xUnit.net 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 xUnit.net 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);

            connection.Open();

            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);

                cmd.ExecuteNonQuery();

            }

 

            connection.Close();

        }

    }


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;

        }

  

        [Fact]

        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.

Why xUnit.net?

For those new to xUnit.net, 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.

    [Fact]

    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 xUnit.net 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 xUnit.net with F# quite easily, just as Harry's post did.

#light

#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 =
    x.elements.AddFirst(element:'t)
   
  member x.Top
    with get() =
      if x.elements.Count = 0 then
        raise (InvalidOperationException("cannot top an empty stack"))
      x.elements.First.Value
     
  member x.Pop =
    let top = x.Top
    x.elements.RemoveFirst()
    top
end

[<Fact>]  
let NoElementsShouldBeEmpty () =
  let stack = new Stack<string>()
  Assert.True(stack.IsEmpty)


If you notice, the FactAttribute is placed on a static method called NoElementsShouldBeEmpty and sure enough it works like a champ through xUnit.net.  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.

Conclusion

There is a lot to like about xUnit.net 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 DotNetKicks.com
Published Monday, March 31, 2008 7:32 PM by podwysocki
Filed under: , ,

Comments

# re: xUnit.net RC2 Released

Monday, March 31, 2008 11:23 PM by podwysocki

@DevHawk

I'd agree and that one slipped my mind as I was writing, but you're absolutely right on that one.  That was one piece I forgot to cover was the statics and I'll update that now.

Matt

# re: xUnit.net RC2 Released

Tuesday, April 1, 2008 12:55 PM by podwysocki

@Andy

Great news!  I need to cover the latest bits from NUnit anyways, so that's a good segue way into the subject.  I'll cover that in a subsequent post.  As I do more F#, I need to do just as many unit tests as before, so statics really help so that I don't need clumsy instances sitting around.

Matt

# re: xUnit.net RC2 Released

Wednesday, June 1, 2011 8:35 PM by weblogs.asp.net

Xunit net rc2 released.. Neat :)

# re: xUnit.net RC2 Released

Thursday, May 3, 2012 6:23 AM by oem software

QD6nby Thanks again for the post.Really looking forward to read more. Want more.

# re: xUnit.net RC2 Released

Monday, November 5, 2012 7:12 AM by ktiVaxvjKXCvrEfOX

gmJSgW I truly appreciate this blog. Much obliged.

# re: xUnit.net RC2 Released

Friday, February 1, 2013 4:53 AM by SjRJDSkUPuQolOztXX

HIboC8 I think this is a real great blog article. Want more.