Expected exception

If you use the ExpectedExceptionAttribute to assert that an exception is raised in an NUnit-test the type of the thrown exception must match the actual exception's type exactly, for example if you check for an ArgumentException and an ArgumentNullException  is thrown the assertion will fail. To me this is wrong since an ArgumentNullException really is an ArgumentException. Of course you could argue that you shouldn't check for general exceptions for the same reasons as you shouldn't catch general exceptions, which I certainly agree with but I'd really leave that up to the developer.

The really big drawback of the attribute solution is that if you have code that's setting up the test objects and does other preparations for the test and this set up code by chance throws an exception of the expected type the test will succeed when it's really not even been run. 

Another issue is that when the expected exception is thrown - naturally - execution of that test is stopped resulting in execution never exits the test method. Now if you're using NCover for test coverage you don't have 100% coverage of your test cases since a line of code (the method exit) was missed.

To avoid this I created a helper method that checks for expected exceptions, another benefit from this is that it can be used with any testing framework. It uses the template method pattern I blogged about a week or so back.

I've implemented the method in a static class called TestHelper and I show an excerpt of it here:

/// <summary>
/// Provides helper methods for testing.
/// </summary>
public static class TestHelper
{
    /// <summary>
    /// Expects the supplied method to throw an exception of the specified
    /// type {T} when invoked. If no exception is thrown or if an exception
    /// of another type is thrown an exception will be thrown making the
    /// assertion fail.
    /// </summary>
    /// <typeparam name="T">The type of <see cref="Exception" /> to expect.</typeparam>
    /// <param name="method">The method that's expected to throw an exception.</param>
    public static void ExpectException<T>(Action method) where T : Exception 
    {
        bool expectedExceptionThrown = false;

        try
        {
            method();
        }
        catch (T)
        {
            expectedExceptionThrown = true;
        }
        catch (Exception unexpectedException)
        {
            // Not correct exception type, for demonstration only.
            throw new Exception("Unexpected exception type."); 
        }

        if (!expectedExceptionThrown)
        {
            var message = string.Format(CultureInfo.InvariantCulture,
                "'{0}' was expected but no exception was thrown.", typeof(T).Name);
            // Not correct exception type, for demonstration only.
            throw new Exception(message);
        }
    }
}

Now tests where I expect exceptions are implemented as any other test without the ExpectedExceptionAttribute. For example:

[Test]
public void ToString_NullObject_Exception()
{
    // Set up code. If an exception is thrown here the
    // test will fail.
    StringBuilder testedObject;
    testedObject = null;
    
    TestHelper.ExpectException<NullReferenceException>(() => {
        // The actual test code, a NullReferenceException must
        // be thrown here or the test will fail.
        testedObject.ToString();
    });
}

Technorati-taggar: xUnit,C#,csharp,lambda expressions,unit test,exception

A Subversion server the easy way

Anyone setting up a Subversion server on a Windows machine knows that it's a cumbersome task although it has gotten easier over the years. Now however it's become childs play, download and install the VisualSVN Server which includes Apache and the SVN binaries. When installed you have a nice UI for creating and removing repositories and editing user rights on them. The repositories are also browsable from a web browser.

VisualSVN is also a very good plug-in for integrating Subversion into visual studio although it costs a couple of dollars, it's definitely worth it.

Template functions

Being a big fan of functional programming languages such as Erlang and Prolog I am very glad to see lambda expressions introduced in C# 3.0 and the VB9. You've been able of writing code in a functional manner since the dawn of C#, but it's been very hard, since version 2.0 it's been easier though with anonymous methods and now with 3.0 and lambda expressions it's truly a walk in the park. One thing I like to do is factoring out common patterns into template functions. A common example of a pattern that is very common is using a database connection and a command for that connection as follows.

using (CustomConnection db = new CustomConnection())
{
    using (IDbCommand command = db.CreateCommand())
    {
        // Database access code here...
    }
}

Now we can factor this out by creating a new delegate type that takes a command and then defining a method that takes such a delegate as an argument.

public delegate void UsingCommandDelegate(IDbCommand command);

public static void UsingCommand(UsingCommandDelegate method)
{
    using (CustomConnection db = new CustomConnection())
    {
        using (IDbCommand command = db.CreateCommand())
        {
            method(command);
        }
    }
}

Now any time we want to make a database call we call this method and pass in the code we want to execute as a lambda expression.

CustomConnection.UsingCommand(command =>
{
    command.Connection.Open();
    command.CommandText = "DELETE FROM [A] WHERE [b] = 'c'";
    command.ExecuteNonQuery();
});

This saves us a couple of lines of code, but the main benefit in this case is that if we want to change any logic regarding how we create connections and commands, let's say we'll change the connection string we can do it in a single location for the whole system. The concept can used in many other cases.

Technorati-taggar: C#,c-sharp,csharp,vb.net,.net,dotnet,lambda expressions,functional programming

Unit testing discussions and nested code files

We had some discussions about my Unit testing pattern-article in one of the forums over at Channel 9. I noticed that a lot of people misread my intentions of the pattern a bit and thought that the advantage of using it is that it enables you to test non public methods, this is however just a side effect (desirable or not) of using the pattern. Therefore I've updated the article to better reflect my intentions.

Nested files

I also added a neat little trick that shows how to make code files depend upon other code files in Visual Studio enabling them to collapse nicely under the file they depend upon.

To do this, open the project-file in an editor and locate the Compile-element representing the file you want to be nested under another file. Insert a "DependentUpon" XML element under this element and use the file name of the file it depends upon as the value:

<!-- Change this: -->
<Compile Include="Foo.Tests.cs" />
<!-- Into this: -->
<Compile Include="Foo.Tests.cs">
    <DependentUpon>Foo.cs</DependentUpon>
</Compile>

Technorati-taggar: c#,csharp,c-sharp,MSBuild,netsed code files,visual studio,unit test

More on checked exceptions

I asked a couple of posts back if I was the only one missing Java's checked exception feature. I decided to read up on the subject, as to why it wasn't included in C# for example (since it was once pretty much a rip-off of Java). I found this interview with Anders Hejlsberg (the father of C#), which gives some good insight as to what's wrong with checked exceptions.

Still I very much like the feature and dislike lazy programmers who makes it a pointless feature. But I think Anders is right, it was a great idea but it just didn't work out in practice.

Google Reader

For anyone who hasn't tried it I recommend Google reader for reading blogs, the key benefit of it is of course that it's an online application and you have access to you blog-subscriptions anywhere you've got access to Internet. There's also a feature where you can share items, if you read something interesting, with just a click you can share it with the world. The link to my shared items is http://www.google.se/reader/shared/15936190092158419995.

Unit testing pattern

In this article I'm going to present a pattern I've developed for creating xUnit-tests in .Net, code samples will be in C# but the pattern is equally well suited for VB.Net or any other .Net-language that has preprocessor #if-equivalents. The main benefits of using this pattern is that your tests will be an integral part of the code under test and that it gives you access to all non-public members of the tested class making it easier to use test doubles (stubs, mocks, etc.) while also removing any requirements from tests on the public interface of a class.

Common practice

I've found that the most common practice when creating xUnit-tests for a project is to create another project with the ".Tests" suffix. For example if I create the project Foo.Bar, I'd also create a project Foo.Bar.Tests where I'd put all my test code for the Foo.Bar project.

This is the way I used to do it and it's certainly not a bad way, but it has some drawbacks, first of all it's a bit cumbersome having to manage two separate projects, when adding a class in the tested project one must also be added in the test project, perhaps the test classes should be in namespaces corresponding to the namespaces of the tested classes and so forth. Also, the way I see it tests should be an integral part of the code it tests. You shouldn't be able to get your hands on a piece of code and not at the same times get the tests for that code.

Another drawback is when using stubs, mocks or other test doubles there must be a way to have the tested object used the double-object instead of a production environment counterpart. Oftentimes this leads to adding constructors or properties to classes in order to make them testable that have no use outside testing and could even break encapsulation.

There's also a third issue that is a drawback or something positive, depending on how you look at it. When put in a separate project the test code can only test public members. There are different schools regarding this, there are those that say that tests should only test the public interface of a class and there are those that say that every member should be tested. I'm leaning more towards the first category. I think that tests should focus on the public interface of the class, or at least the non-private interface, but it can't be bad to have the option to test private members as well. (I'd also like to point out that I am aware that there are ways to get around this to enable test of members with a more narrow scope, but they are workarounds).

The way I do it

One way to overcome all of these issues is putting the tests in an inner/nested class of the tested class:

public class Foo
{
    public Foo()
    { 
        // Default constructor...
    }

    private Foo(object parameter)
    { 
        // Test only constructor..
    }

    private int Add(int a, int b)
    {
        return a + b;
    }

    [TestFixture]
    public class FooTests
    {
        [Test]
        public void Add_TwoValues_ReturnSum()
        {
            object mock = new object();
            Foo f = new Foo(mock);
            Assert.AreEqual(3, f.Add(1, 2));
        }
    }
}

As you see this makes our test an integral part of the tested code, and it lets us access all non-public members of the tested class so any constructors used for tests only could be declared private and not affect the classes interface.

But clearly this is not a good idea at all, our production code will now contain a lot of test code that simply shouldn't be there, but wait, there's a way to fix this, and it's simple. Let's use the pre-processor if-statement:

public class Foo
{
    public Foo()
    { 
        // Default constructor...
    }

    private int Add(int a, int b)
    {
        return a + b;
    }

#if DEBUG
    [TestFixture]
    public class FooTests
    {
        [Test]
        public void Add_TwoValues_ReturnSum()
        {
            object mock = new object();
            Foo f = new Foo(mock);
            Assert.AreEqual(3, f.Add(1, 2));
        }
    }

    private Foo(object parameter)
    { 
        // Test only constructor..
    }
#endif
}

Now the test code will only be compiled into the assembly when the DEBUG-flag is set, that is when the assembly is compiled with the Debug-configuration.

Any test-only constructors, properties or other members could be included within this #if-statement to so that they are only included when doing a debug build. Now I think we have a pretty good model, however there is some remaining issues.

The first issue is a minor one, we now have to have a reference to our unit-testing framework of choice in our production code, this is really minor though, since it'll never be used outside of the tests and those are only included in debug builds so when compiling a release build the only thing that will happen is that the referenced dll will be copied to the output directory, it's safe to remove it. A very simple fix is to edit the project file which is easy enough if you know your way around MSBuild, set a conditional attribute on the reference so that it's only included in debug-builds. Of course this goes for any references that's needed by test code only.

The second issue is that our production code is somewhat cluttered with test code, and I simply don't like the way it looks! But wait, 'cause now is where the real beauty of it all will reveal itself... Partial classes! Partial classes were new in the .net-framework 2.0 and is primarily a way to make designer-generated code not interfere with user code (and possibly overwrite it).

So, let's add another code file called Foo.Tests.cs to our project and in that file let's put all our test code, what we'll end up with is these two files:

Foo.cs

using System;

namespace Foo.Bar
{
    public partial class Foo
    {
        public Foo()
        { 
            // Default constructor...
        }

        private int Add(int a, int b)
        {
            return a + b;
        }
    }
}

Foo.Tests.cs

#if DEBUG
using System;
using NUnit.Framework;

namespace Foo.Bar
{
    public partial class Foo
    {
        private Foo(object parameter)
        {
            // Test only constructor..
        }


        [TestFixture]
        public class FooTests
        {
            [Test]
            public void Add_TwoValues_ReturnSum()
            {
                object mock = new object();
                Foo f = new Foo(mock);
                Assert.AreEqual(3, f.Add(1, 2));
            }
        }

    }
}
#endif

As you see now our tests have no impact on the production code in the Foo.cs file and everything looks perfectly normal (well, there is the partial modifier in the class declaration, but I'll live with that), all test code is in a dedicated file and will never be compiled in to release versions, actually note that even the using directives are inside the #if-statement.

There is one more little trick that you can use if you want the test code truly non intrusive in the project and it is making the test code file depend upon the class code file which will make it collapse nicely under the code file, just like designer files do in Visual Studio.

 

All you have to do to make this work is open the project file in a text (or XML) editor and locate the Compile-element for the test file. Add an xml-element under this element named "DependentUpon" with the value set to the name of the class code file:

<!-- Change this: -->
<Compile Include="Foo.Tests.cs" />
<!-- Into this: -->
<Compile Include="Foo.Tests.cs">
    <DependentUpon>Foo.cs</DependentUpon>
</Compile>

Conclusion

The one problem I've found with this is if the tested class is a generic class the inner class can not be instantiated and the tests can't be run. In most cases the easiest way is to simply move the test class out of the tested class so that it's no longer nested, of course the we can't access private or protected members but in most cases there is no need for that, there is however a way to keep the pattern intact with the nested class even in generic classes and I'll blog about that at some later point.

Technorati-taggar: unit test,xUnit,NUnit,MBUnit,nested class,partial classes,.net,c#,c-sharp,csharp,dotnet