Testbasierte Entwicklung ist schon eine schöne Sache, vor allem bei größeren Projekten. Mit Hilfe sogenannter Unit-Tests kann man dabei automatisiert überprüfen ob der zu testende Softwareteil noch immer die Ergebnisse liefert, die erwartet werden. Meist ist es so, dass man in größeren Softwareprojekten etwas ändert und damit implizit an anderen Stellen Fehler einbaut, welche ohne Unit-Tests gar nicht bzw. erst später auffallen.
Für die Entwicklung unter .NET/Mono mit Hilfe des Visual Studios habe ich mich dabei für NUnit entschieden, da man dieses im Gegensatz zu MsTest auch unter Linux und Mac OS X nutzen kann. Damit sich das ganze bequem in das Visual Studio integriert nutze ich TestDriven.NET welches unter http://www.testdriven.net/ bezogen werden kann. Der persönliche Gebrauch ist dabei kostenlos.
Nach der Installation von TestDriven.NET kann man sein Visual Studio starten und mit der testbasierten Entwicklung beginnen. Dabei hat man zwei Möglichkeiten dies zu lösen. Die erste Möglichkeit ist es die Tests in ein extra Projekt zu verlagern so das diese nicht in der zu testenden Software vorkommen. Bei der zweiten Möglichkeit werden die Tests direkt im zu testenden Projekt geschrieben (z.B. in einen Namespace „Tests“).
Als Beispiel sei folgende Klasse gegeben:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace Project
{
public class FooBar
{
public int A { get; private set; }
public int B { get; private set; }
public int C { get; private set; }
public FooBar(int a, int b, int c)
{
A=a;
B=b;
C=c;
}
}
}
Die Klasse „FooBar“ nimmt dabei im Konstruktor die drei Variablen a, b und c entgegen und weist sie den jeweiligen Eigenschaften der Klasse zu. Um nun zu testen ob diese Zuweisung funktioniert schreiben wir eine entsprechende Test-Unit. Dazu erstellen wir eine Klasse namens: „FooBarTest.cs“:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using NUnit.Framework;
namespace Project
{
[TestFixture]
public class FooBarTests
{
[Test]
public void TestNewFooBar()
{
FooBar fooBar=new FooBar(13, 24, 47);
Assert.AreEqual(13, fooBar.A);
Assert.AreEqual(24, fooBar.B);
Assert.AreEqual(47, fooBar.C);
}
}
}
Diese Testklasse testet nun ob die Werte die im Konstruktor angegeben werden auch wirklich in den entsprechenden Eigenschaften landen. Dazu wird zuerst das NUnit Framework mittels:
using NUnit.Framework;
eingebunden. Mittels des Attributes „[TestFixture]“ sagen wir dem NUnit Framework das sich in dieser Klasse Unit-Tests befinden. Bei diesem Attribut gibt es einige Einschränkungen, so darf die Klasse z.B. nicht abstrakt sein, näheres dazu erfährt man auch in der Dokumentation.
Das Attribut „[Test]“ über der Funktion „TestNewFooBar“ teilt dem Framework mit das es sich bei dieser Funktion um einen Unit-Test handelt, welcher überprüft werden soll. Dazu legen wir in der Funktion eine Instanz von „FooBar“ an und übergeben die entsprechenden Werte an den Konstruktor.
Mittels der „Assert.AreEqual“ Funktion (weitere „Assert“ Funktionen findet man in der Dokumentation) überprüfen wir ob die Werte auch bei den Eigenschaften A, B und C angekommen sind. Wäre dies nicht der Fall so würde der Tests fehlschlagen.
Nachdem ein Test für die entsprechende Klasse geschrieben wurde, klickt man im Visual Studio mit der rechten Maustaste auf die Testklasse und wählt dort „Run Test(s)“ aus. Möchte man mehrere Tests laufen lassen so muss einen übergeordneten Ordner auswählen. Wenn alles richtig gemacht wurde, sollte man folgende Ausgabe sehen:
------ Test started: Assembly: Project.exe ------
1 passed, 0 failed, 0 skipped, took 3,07 seconds (NUnit 2.6.0).
Falls ein Fehler aufgetreten ist so sieht das ganze so aus:
------ Test started: Assembly: Project.exe ------
Test 'Project.FooBarTests.TestNewFooBar' failed:
Expected: 47
But was: 0
FooBarTests.cs(19,0): bei Project.FooBarTests.TestNewFooBar()
0 passed, 1 failed, 0 skipped, took 1,66 seconds (NUnit 2.6.0).
Findet man einen Fehler bei einem Test sollte man schauen wodurch dieser verursacht wird und ihn beheben. Wenn man nun bei der späteren Entwicklung Fehler findet (und beseitigt), welche durch keinen Tests abgedeckt sind, so sollte man gleich einen entsprechenden Test dafür schreiben, damit dieser Fehler nicht ein weiteres Mal auftreten kann.
Weitere Informationen gibt es unter:
http://de.wikipedia.org/wiki/NUnit
http://de.wikipedia.org/wiki/XUnit