Perseverance – or – how to stop whining and embrace unit testing

Dave Chestnutt — Sat, 28 Mar 2009 07:43:40 GMT

We’ve all heard the mantra – Unit Testing is good for the soul. We hear about the goodness of things like JUnit, NUnit, and TDD from other people.

But you’re not convinced.

After all, it takes more time to write unit test code – and you’d rather get on with the next feature. Besides, whether it’s true or not, you certainly feel like your progress is measured by how many features you crank out.

In my own journey, I found I went through three distinct stages to testing heaven. Look at my “diary” for the first few unit tested projects I was on.

Stage 1: "I believe, it's stupid but I believe"

Unit Testing, huh? Great, now I have to spend time writing these stupid tests before I can say I’m done. It’s not really hard, but it takes additional time to create these tests. Time that I think would be better spent moving the project along with more features. I was told to do it, so I will, but I don't see or feel the benefit yet. I write tests because I have to.

Stage 2: OK, it’s good for the project

Hmm, I added a new feature today – and someone else’s test broke. As I checked it out, I found that indeed, I had modified some code that no longer worked for another scenario. So, for the first time I saw a benefit from the tests. Of course, I still think my time is better spent adding new features – but I begin to see that they’re a good thing to have, especially if other people write them. So now I’m voluntarily writing tests for some of the new code I write. The project is better for it.

Stage 3: Hey, I can code faster

And gradually it happened. Bit by bit the the second level effects of testing crept into my work.

I can write a small test to reproduce a bug, and I don’t need to get a whole test environment set up. This lets me debug my solution much much faster.
I can write a small test to exercise some code that I can’t even get to from the main application yet. This is cool, because I can implement a feature before someone else needs it. And put it through its paces.
Now that I’ve gotten the hang of writing tests, I find it extremely easy to write lots of test cases for the same piece of functionality. After writing the first test, it’s real easy to tweak it for many test cases. We always talked about testing all the edge cases – now I can actually do so.
I can modify code (like redesign the innards of a class) with high confidence that I won’t break something that depends on it – because I have a set of tests to make sure I don’t break behavior. This is where Unit Testing plus Refactoring have a real synergy. The two combined offer a great advantage over either practice by itself. Better quality code that’s easier to maintain.

So that’s how it finally happened. I actively use tests to develop and debug code. In fact – TDD (writing the tests first) as a process kind of snuck up on me. I can’t imagine writing code without tests anymore.

So if you’re not there yet – don’t worry. Especially if your boss is on your case. It’ll come. And when it does, you’ll wonder how you ever ever did without it.

Technorati tags: unit testing, junit, nunit, CodeGaffes

NUnit - support both .NET 1.1 and 2.0 at the same time

Dave Chestnutt — Tue, 07 Mar 2006 23:44:00 GMT

How to easily run NUnit tests in both .NET 1.1 and 2.0 environments.

I want to run my NUnit tests! But I have a problem -- my code runs under both .NET 1.1 and 2.0 frameworks. It is real easy to run tests from the IDE, which I do, but that means I'm only running the tests under one version of .NET.

How can I easily run tests under both .NET frameworks?

I'm lazy, so it has to be easy. So, without even resorting to the command line, here's how I do it in 3 steps:

1. Running tests with the .NET 1.1 Framework

I use Visual Studio 2003, and the TestDriven.NET Add-in (http://www.testdriven.net/). I right-click on tests, projects, or the whole solution - and run my tests under .NET 1.1.

2. Running tests with the .NET 2.0 Framework

I use the NUnit GUI app to run tests under the .NET 2.0 environment. To make the NUnit GUI run with .NET 2.0 framework - I modified the nunit-gui.exe.config file so its startup section has the 2.0 runtime first:

<startup>
  <!-- NUnit will run under the first version it finds -->
  <SUPPORTEDRUNTIME version="v2.0.50727"/>
  <SUPPORTEDRUNTIME version="v1.1.4322" />
  <SUPPORTEDRUNTIME  version="v1.0.3705" />
  <REQUIREDRUNTIME  version="v1.0.3705" />
</startup>

I place a shortcut to the NUnit GUI on my Quick Launch toolbar, and I'm all set. While it's still true that I run the tests in the IDE the most, I can easily start the NUnit GUI and fire off my tests under .NET 2.0. And since it's easy, I do it.

3. Making a test conditional based on .NET framework version

Some of my tests only make sense under .NET 2.0, and some under 1.1. [They all compile under 1.1 because we support both.] So how do I make a few tests conditional? This requires two things: How to detect the version of the framework in use, and how to stop NUnit from running tests that are inappropriate for the framework in use.

I've seen a bunch of ways to detect what framework version we're actually running under. This is my favorite because it's so simple and clear:

public bool IsUsingDotNet11()

    return (Environment.Version.Major == 1)

        && (Environment.Version.Minor == 1);

public bool IsUsingDotNet20()

    return (Environment.Version.Major == 2)

        && (Environment.Version.Minor == 0);

As far as NUnit goes, we let it run all the tests, because we add checks inside the tests to stop them if they require the "other" version of the framework. By using NUnit's Assert.Ignore() method, we can give a nice message, as well as gracefully stop the test in its tracks.

[Test]

public void TestSomethingOnDotNet11Only()

    if (! IsUsingDotNet11())

        Assert.Ignore("This test is for .NET 1.1 only");

    // … Rest of test code ...

There you have it. You can adapt this technique to suit your needs. For example, if you run your tests from a batch file, you can modify nunit-console.exe.config to make the console run under any version of the Framework that's installed on the machine.

The reality is that many of us have to support more than one version of the DotNET framework. Until such support is built into Visual Studio, we'll have to resort to methods like this to test in the real world. Hopefully this short cut will make it easy.

So you can be lazy like me.

NUnit Tips

Perseverance – or – how to stop whining and embrace unit testing

NUnit - support both .NET 1.1 and 2.0 at the same time