Saturday, January 26, 2008

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.

Missed line

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

Friday, January 25, 2008

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.

Sunday, January 20, 2008

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.

Tuesday, January 8, 2008

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.

Nested or dependent files in Visual Studio.

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>

Monday, January 7, 2008

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.

Sunday, January 6, 2008

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.

Untitled-1

Saturday, January 5, 2008

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.

twoprojects

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.

Debug

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.

 Visual Studio displays that test file depends upon code file.

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.

Code in blogs

I found a plugin to Windows Live Writer that let's me post code snippets to the blog in an elegant way, check it out here.

Friday, January 4, 2008

Catching general exceptions

I just found a great article about why it's bad to catch general exceptions, you know like:

try
{
    throw new ApplicationException();
}
catch (Exception ex)
{
    // Handle or swallow.
}

That this is bad I've known for a long time, actually I've been familiar with a couple of very good reasons that this is bad for a long time too. For example when catching System.Exception the exception you catch just might be an OutOfMemoryException and just how are you going to recover from that? When talking to other developers about this bad behavior it's always been difficult to find really compelling arguments though but I think I found them in this article.

Am I the only fan of the Java way, where you explicitly have to say that your method throws one or more exceptions? The .net way of doing it is relying too heavily on documentation as I see it, and relying TOO much on documentation can never be a great idea knowing how well (or actually bad) most systems are documented.

Easy

Getting my blog posts to appear the way I'd like them to seems to be a bigger challenge than I thought it would be, anyone has any tips for posting code-snippets on a blogger-blog?

Technorati-taggar: ,,,

Thursday, January 3, 2008

Generic weak reference

I'm sure I'm not the first person who's found that there is no generic version of the System.WeakReference class. I searched and did find some implementation, but I found it not good enough. First of all it didn't inherit from WeakReference which is a major drawback since it can't be passed where a WeakReference is expected as an argument.

Also I thought it would be nice to be able to implicitly cast between a WeakReference<T> and a T as follows:

WeakReference<string> r = new WeakReference<string>("doh!");  
string s = r; // The variable s now holds the value "doh!".

(To be honest a weak reference to a string-object would in most cases be quite useless but this is just an example).

I'm not sure how well known the cast operators of .Net are, but they sure are handy, especially for this kind of generic classes, check out the implementation of Nullable<T> for examples of both the implicit and the explicit cast operator.

The implementation is simple enough as follows:

/// <summary> 
/// Represents a weak reference, which references an object while still allowing   
/// that object to be reclaimed by garbage collection.    
/// </summary>    
/// <typeparam name="T">The type of the object that is referenced.</typeparam>    
[Serializable]    
public class WeakReference<T>        
    : WeakReference where T : class    
{       
    /// <summary>        
    /// Initializes a new instance of the Minimal.WeakReference{T} class, referencing        
    /// the specified object.        
    /// </summary>        
    /// <param name="target">The object to reference.</param>        
    public WeakReference(T target)            
        : base(target) { } 
    /// <summary>        
    /// Initializes a new instance of the WeakReference{T} class, referencing 
    /// the specified object and using the specified resurrection tracking. 
    /// </summary>        
    /// <param name="target">An object to track.</param> 
    /// <param name="trackResurrection">Indicates when to stop tracking the object. If true, the object is tracked 
    /// after finalization; if false, the object is only tracked until finalization.</param> 
    public WeakReference(T target, bool trackResurrection) 
        : base(target, trackResurrection) { } 
    protected WeakReference(SerializationInfo info, StreamingContext context) 
        : base(info, context) { } 
    /// <summary> 
    /// Gets or sets the object (the target) referenced by the current WeakReference{T} 
    /// object. 
    /// </summary> 
    public new T Target 
    { 
        get 
        { 
            return (T)base.Target; 
        } 
        set 
        { 
            base.Target = value; 
        } 
    } 
    /// <summary> 
    /// Casts an object of the type T to a weak reference 
    /// of T. 
    /// </summary> 
    public static implicit operator WeakReference<T>(T target)        
    { 
        if (target == null)            
        { 
            throw new ArgumentNullException("target"); 
        } 
        return new WeakReference<T>(target); 
    } 
    /// <summary> 
    /// Casts a weak reference to an object of the type the 
    /// reference represents. 
    /// </summary> 
    public static implicit operator T(WeakReference<T> reference) 
    { 
        if (reference != null) 
        { 
            return reference.Target; 
        } 
        else 
        { 
            return null; 
        } 
    } 
}

My first post!

This is my first blog post, yeah, you heard it the first ever so I'll just say some quick words about this blog. My intention is that this blog will be about systems development, first and foremost on the .Net-platform, but also a lot about object oriented architecture in general.

I guess I should give a short presentation about myself to, I'm thirty years old, born and raised (and still living) in the town of Helsingborg in the very south of Sweden.

Kartbild

I've been working as a consultant for the last couple of years but since a year or so back I'm employed as a systems developer at a travel agency called Sembo (www.sembo.se). Before Sembo I'd almost exclusively written in C# for the .Net-platform, however I've done my share of com-programming in vb6 and earlier, at Sembo I do most of my programming in VB.Net.

Well, I guess, enough about me, the next post will probably be a bit more interesting...

Cheers,
Patrik

n620001997_476351_8920

PS. I couldn't find a decent picture of myself so I had to go with a not so decent one. These are two of my favorite colleagues however, very nice girls. Who's foot it is? No idea! DS.