NUnit 2.4.7 includes RowTest Extension

Standard

Charlie Poole released NUnit 2.4.7 today. This release eliminates some problems related to NUnit’s interaction with log4net and various bugs are also addressed. The release notes contain more detailed information.

RowTest Extension 1.2.2 is packaged in the NUnit extension assemblies. It’s the first time that an externally developed addin is included in a release of NUnit. You’ll have to change the namespace from NUnitExtension.RowTest to NUnit.Framework.Extensions if you want to port your unit tests from older versions of RowTest Extension.

You can download NUnit 2.4.7 from the NUnit site or from Sourceforge.

RowTest Extension 1.2.2

Standard

I released a new version of the RowTest Extension. I made following changes:

  • null cannot be used as argument on .NET Framework 1.1. A new enum value SpecialValue.Null can be used instead. If the RowTest addin finds this value as argument the value will be translated to null.
  • Fixed Bug: Common NUnit attributes like Category, Description etc. don’t work for RowTest methods.

You can download it from the RowTest Extension page.

Using Bazaar and Launchpad on Windows

Standard

Bazaar is a distributed version control system (DVCS) written in Python with many interesting features. Like all DVCS it supports disconnected operation which means that you don’t have to be connected to a central repository to commit changes or to view the history.

Launchpad is a free software hosting and development site. Another well-known site of this category is Sourceforge. Launchpad was originally created for Ubuntu and is now used by many other open source projects, e.g. Zope and Silva CMS.

Erik Thomson wrote some tips about using Launchpad and Bazaar on Windows and made a (http://showmedo.com/videos/video?name=1510070&fromSeriesID=151). When I tried to make a first branch at Launchpad on Windows I had some problems, though. I got errors like “bzr: ERROR: Don’t know how to handle SSH connections. Please set BZR_SSH environment variable.” or “bzr: ERROR: [Error 2] The system cannot find the file specified”. To push changes from the local branch to Launchpad Bazaar needs the python library paramiko for SSH connections and it was missing on my system. Paramiko requires pycrypto, binaries for Windows can be found at The Voidspace Python Modules. To install paramiko install pycrypto first, extract the downloaded zip package, change to the directory and call “&path to python&\python setup.py install”. After installing the missing libraries everything worked fine and you can find a branch for the RowTest extension for NUnit at Launchpad.

Wie gefährlich sind SetUp und TearDown in NUnit?

Standard

Im klassischen JUnit wurde eine bestimmte Konstellation aus Testobjekten Test-Fixture genannt. Es besteht zumindest aus einem Objekt der getesteten Klasse, aber auch aus Objekten, von denen das getestete Objekt abhängt. Außerdem können auch alle anderen Vorbedingungen, die für den Test notwendig sind, wie z.B. Dateien dazugezählt werden.

Im Buch “xUnit Test Patterns” von Gerard Meszaros werden mehrere Varianten für die Organisation der Testfallklassen erwähnt:

  • Testfallklasse pro Klasse:
    Dabei wird für jede getestete Klasse eine eigene Testfallklasse erstellt.
  • Testfallklasse pro Feature:
    Alle Testmethoden, die ein bestimmtes Feature einer Klasse testen, werden in einer Testfallklasse zusammengefasst. Als Feature werden alle Methoden und Eigenschaften bezeichnet, die zusammen eine Fähigkeit der getesteten Klasse implementieren.
  • Testfallklasse pro Fixture:
    Alle Testmethoden, die das gleiche Testfixture benötigen, werden in einer Testfallklasse zusammengefasst.

In NUnit werden Testfallklassen mit dem Attribut TestFixture markiert. Damit wird angenommen, dass die Testfallklassen nach Fixtures organisiert sind. Häufig werden Testfallklassen auch nach Klassen organisiert. Wenn der Testautor dann Setup-Methoden verwendet, um den Code, der die Testobjekte erstellt, in eine Methode auszulagern, läuft er in die Probleme, die zwei Entwickler von xUnit.net, James Newkirk und Brad Wilson, in ihren Blogs beschreiben:

  • Schwer zu verstehender Code, weil der Setup- und der Cleanup-Code vom eigentlichen Testcode getrennt wird.
  • Im Setup-Code werden mehr Objekte erzeugt, als für die einzelnen Tests notwendig sind. Das kann die Lesbarkeit und die Performance negativ beeinflussen.
  • In Setup-Methoden werden Instanzvariablen initialisiert. Wenn man nicht aufpasst, werden Testobjekte nicht aufgeräumt und können dadurch andere Testfälle beeinflussen.

Als Alternative können Testobjekte durch Methoden erzeugt oder das Pattern Testdata-Builder verwendet werden. Doch auch hier gilt, dass u.U. Testobjekte wieder aufgeräumt werden müssen, z.B. wenn sie Dateien geöffnet haben. Der nächste Test schlägt dann fehl, wenn er die gleiche Datei öffnen will.

Wenn Sie Testfallklassen nach Fixture organisieren, können Sie auch Setup- und Teardown-Methoden verwenden. Es werden dann immer genau jene Objekte erzeugt, die für die Tests notwendig sind, und der Code sollte dennoch lesbar bleiben, weil ja alle Testmethoden auf dem gleichen Fixture aufbauen.