Menü
Was sollte ein Softwareentwickler immer tun, wenn er etwas am Code geändert hat? Richtig! Testen, testen und nochmals testen. Und Unit-Tests sind der erste Schritt zur Umsetzung dieses gut gemeinten Ratschlags. Denn mit ihnen werden die kleinsten Programmeinheiten (Units) automatisiert überprüft – quasi Code, der Code bewertet. Ziel ist es, die Schnittstellen jeder einzelnen Komponente (z.B. Klassen, Methoden oder Funktionen) auf Fehler abzuklopfen. Ein Unit-Test läuft dabei häufig nach einem festen Schema, dem sogenannten AAA-Pattern (keine Sorge wir überprüfen nicht Ihre Bonität) ab:
Und so sieht ein Unit Test in C# aus:
using NUnit.Framework;
namespace UnitTests
{
public class MatheTests
{
public int Nummer1 { get; set; }
public int Nummer2 { get; set; }
public TaschenRechner TaschenRechner { get; set; }
// Arrange
[SetUp]
public void Setup()
{
Nummer1 = 1;
Nummer2 = 1;
TaschenRechner = new TaschenRechner();
}
[Test]
public void Teste_Addition()
{
// Act
var ergebnis = TaschenRechner.AddiereZahlen(Nummer1, Nummer2);
// Assert
Assert.AreEqual(2, ergebnis);
}
}
}
Idealerweise hat der Softwareentwickler für alle wichtigen Funktionen mindestens einen Unit-Test geschrieben. Denn so kann man sich auf die faule Haut legen und nach und nach beobachten, wie der Computer alle Tests der Reihe nach überprüft. Hat die Softwareentwicklerin oder der Softwareentwickler saubere Arbeit geleistet, erscheint ein Bericht mit vielen grünen Häkchen. Wenn nicht, dann geht’s noch mal ran an die Fehlersuche – und täglich grüßt in der Softwareentwicklung das Murmeltier bzw. der Test-Report.
Damit ein Unit-Test in einer Entwicklungsumgebung wie Visual Studio auch als solcher erkannt wird, gibt es für Softwareentwickler spezielle Bibliotheken. Diese Fertigbaukästen beinhalten alles, was es braucht, um eine Softwarekomponente auf Herz und Nieren zu prüfen:
Die bekanntesten Unit-Test-Frameworks, die man in der Softwareentwicklung mit .NET als Bibliotheken verwenden kann sind:
