Unit Tests v2.0

6 11 2012

Not the most profound title to be found out there but I couldn’t think of anything better. I’m a big proponent of testing and test-driven-development in particular. This enthusiasm, unfortunately, does not automatically make me good at writing tests or at driving my designs using tests – but I try. One of the things I find really hard about TDD is how to organize the tests into coherent units and, extrapolating from this, which tests should I write where. I’ve tried a few schemes and didn’t really feel comfortable with any of them (most likely an issue with me rather than the schemes themselves by the way). So lately, and I mean as of the following week or so, I’ve adopted the following pattern.

Quick aside, I’m using C# and the .Net version 4.0 along with NUnit and Visual Studio 2010.

First of I’ve decided to symbolically separate test classes [TestFixture] and methods [Test] from the rest of my code by using, *gasp*, underscores and all lower-case letters. Secondly I’ve started making instances of the class under test so that I can verify actual usage of the class itself and finally I’m making a namespace for each instance and a test fixture for each operation/property that I want to test under that instance.

It’s probably a bit hard to follow that explanation (and I probably will refine it to a set of written standards at some point) so let me give a real world example from my very own code!

/// <summery>
/// Testing the generated target configuration when using the
/// DefaultInternalBuildProperties.
/// </summer>
public class target_configuration
  public void should_be_release()
    var instance = new ContentForTestProject();

That’s the testing piece and it lives under the namespace of:


Which means that when I’m reading the entire test description it generates the following string:


Another point should also be made here concerning the following line in the testing code:

 var instance = new ContentForTestProject();

ContentForTestProject is a type of, ah, factory I guess you could call it, that generates for me an instance of the class being tested. The previous line of code will be repeated for each testing method simply because I’ve come to realize that this article is correct when using NUnit.

/// <summary>
/// Generates an instance of the DefaultInternalBuildProperties [Factory]
/// which will in turn fabricate those properties for some fake game
/// project in a folder called 'Test'.
/// </summary>
public class ContentForTestProject
  public readonly DefaultInternalBuildProperties Factory;

  public ContentForTestProject()
    Factory = new DefaultInternalBuildProperties();

This entire scheme might not be ideal or even used and maybe I’ll find it doesn’t scale very well down the line. But for now it sort of fits the way I view my code and it helps me keep track of the operations that I’m testing (that is the operations that I want my classes to perform).

“And we only smoke when bored, So we do two packs a day”




Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: