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>
[TestFixture]
public class target_configuration
{
  [Test]
  public void should_be_release()
  {
    var instance = new ContentForTestProject();
    Assert.That(instance.Factory.GetTargetConfiguration(),
                Is.EqualTo("Release"));
  }
}

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

testing_default_internal_build_factory

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

testing_default_internal_build_factory.target_configuration.should_be_release

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

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”

Advertisements




Extending Enums

2 11 2012

Not really going to be a long post since I’m up to my ears in code and the tests aren’t going to write themselves (now THAT would be a worthy plugin for my IDE).

Enumerations, some people like them and some people think they’re evil. Like everything else I say they’re a tool that can be used and/or abused. I like to capture semantic meaning of certain unshakable facts, usually in regards to certain values that are used as flags, by cementing them as enumerated values. This post isn’t much about the reasons to use or not to use enums but rather a convenient feature of C# to allow us to supply extension methods for enumerated types as well given that enums, like EVERYTHING else in C# are derived from object.

Extension methods, just as a quick aside, are also a neat feature of C# that can be abused quite sorely 😛 and they, basically, allow programmers to ‘extend’ an object operational field (ie. interface). And it goes something like this:

// This is our enum
public enum Flags
{
  Flag1,
  Flag2,
}

// Contains our extension methods; notice must be static.
public static class FlagsExtensions
{
  // An extension method; notice accepts the 'this' pointer.
  public static string GetString(this Flags flag)
  {
    return "Hello";
  }
}

And that’s all folks, we can now get a nicely formatted string out from our flags.

string flagString = Flags.Flag1.GetString()

Perhaps not the most useful thing in the world but nice to know anyway and it helped me a little bit in the last couple of days 😀

“And they say the ghost of Lucius Clay gets up and he walks around.”