Jeder Softwareentwickler kennt das Szenario.
Du hast ein neues Feature implementiert und dabei ein anderes „kaputt“ gemacht. Wenn du jetzt sagst, dass dir das noch nie passiert ist, dann bist du entweder noch nicht lange im Geschäft oder produzierst ausnahmslos perfekten Code und hast jederzeit den kompletten Code im Blick und weißt auch ganz genau, was genau in Zeile 42 in der Datei XY steht.
Für alle anderen möchte ich in diesem Beitrag beleuchten, warum UnitTests wichtig sind und wie die sogar Geld einsparen können. Dies gilt schon bei der Entwicklung, aber insbesondere im weiteren Lebenszyklus der Software.
Was ist ein UnitTest?
Der Begriff UnitTest, setzt sich genau genommen aus zwei Wörtern zusammen. Unit und Test.
Unit sagt an der Stelle aus, in welchem Umfeld getestet wird, bzw. die Granularität. Je kleiner solch eine Unit ist, desto besser kann man diese auch testen.
Konkret gesagt, ist eine Unit eine Methode/Funktion/Prozedur, die komplett isoliert getestet wird.
Eine solche Unit könnte in etwa so aussehen:
public string GetFullName()
{
return $"{SurName}, {ForeName}";
}Die „korrekte“ Funktionsfähigkeit dieses Codes wird wiederum mit dem Test sichergestellt. Und dadurch ist wiederum sichergestellt, dass der Code auch in allen künftigen Versionen genau so funktioniert, wie hier definiert. Solange der Testcode unverändert bleibt.
Der große Vorteil ist, dass man diesen Test per Knopfdruck und/oder komplett automatisiert ausführen kann. Damit wird sichergestellt, dass der Produktivcode genau so funktioniert, wie gewollt.
Der dazugehörige Testcode könnte in etwa so aussehen:
[Test]
public void GetFullNameMustReturnForeAndSurNameSeparatedByComma()
{
var person = new Person("John", "Doe");
var name = person.GetFullName();
Assert.That(name, Is.EqualTo("Doe, John"));
}Zugegeben, dieses Beispiel ist ziemlich trivial und ich höre schon viele Leute aufschreien:
- Warum soll ich so etwas testen?
- Muss man so etwas testen?
- „Das sieht man doch, dass das funktioniert!„
Warum soll man UnitTests schreiben?
Die Frage ist eher nicht das warum, sondern was sind die Alternativen, die du ohne automatisierte Tests hast.
Alternative 1: Manuelle Tests
An manuellen Tests führt kein Weg vorbei. Auch eine Software mit vielen UnitTests muss man manuell testen.
Besonders wenn es darum geht, dass externe Komponenten, auf die man kein bis wenig Einfluss hat, kaputtgehen können.
Für jeden Use Case, welches die Software bietet, soll man mindestens eine Frage formulieren. Sind die einzelnen Use Cases komplexer, können es auch gut und gerne 50-100 solcher Testfragen werden. Arbeitest du an einer komplexen Software, kann sich der Testprozess (und damit auch die Release-Phase) erheblich in die Länge ziehen.
Konkret heißt das, dass alle Testszenarien in einem Testhandbuch festgehalten werden müssen. Dieses Testhandbuch bekommt der Tester für jeden „Release Candidate„.
Ein gar nicht mal so absurder Fall ist, dass ein Tester solch ein Testhandbuch über – sagen wir mal – 500 DIN A4 Seiten bekommt. Dieses muss er anschließend komplett durcharbeiten. Dafür braucht er in etwa eine Mannwoche.
Das wären beim aktuellen Mindestlohn (vorausgesetzt man engagiert kein Profi-Tester) ca. 480 €. Da man ein wenig mehr Wert auf die Softwarequalität legt, beauftragt man mal direkt 10 Tester.
Und wie der Zufall so will, sind die 10 Tester ihr Geld wert und finden 42 Fehler. 7 davon stuft man als kritisch ein. Diese sind Release-Relevant und müssen noch unbedingt in dieser Version behoben werden. Weitere 13 sind Bedienfehler und werden entweder gar nicht oder in einer späteren Version behoben.
Man behebt also diese 7 Bugs und gibt es noch einmal in den Test. Nach einer Woche Wartezeit und weiteren 4.800 € erhält man den Bericht: Es gibt 3 neue Bugs, die vorher nicht da waren.
Übrigens, wenn man ein Profi-Tester engagiert, möchte er wahrscheinlich auch einen entsprechendes Honorar (120 € vielleicht). Somit hat man sich kaum Kosten gespart. Die Fragen, die man sich dabei stellen muss, sind: Quantität vor Qualität? Sehen 20 Augen mehr als 2?
Alternative 2: Tests am User
Wenn man sich die ganze Testerei ersparen möchte, gibt es noch eine weitere Möglichkeit. Man führt die Tests direkt am User aus. Soll heißen, dass man abwartet, wie viele Fehlerberichte den so direkt nach dem Release kommen.
Hier kommt es aber auch sehr stark auf die Nutzergruppe an. Du musst dir auch die Frage stellen: kann ich es mir erlauben, eine fehlerhafte Software zu releasen?
So oder so, wenn sich die Anzahl der Fehler häuft, schwindet das Vertrauen der User. Zwangsläufig werden immer weniger Menschen deine Software verwenden.
Hast du für deinen Kunden eine Speziallösung entwickelt und dieser ist damit unzufrieden, wird der Kunde entweder abspringen oder nach Fehlerbehebung verlangen. Der wirtschaftliche Schaden in diesem Fall kann erheblich werden.
Vertreibst du eine – ich nenne es mal – geschäftskritische Software, kann es sogar zu einer Sammelklage führen. Dies kann sogar zu einem wirtschaftlichen Ruin für dich führen.
Zwischenfazit
Zugegeben, das waren jetzt alles Katastrophenszenarios. In der Realität läuft es glücklicherweise ein wenig anders ab.
Gleichwohl können automatisierte Tests den Release-Prozess deutlich beschleunigen. Durch die Ersparnis unnötiger Testiterationen kann auch Geld eingespart werden. Außerdem läuft man nicht in die Gefahr, dass immer mehr und mehr Kunden unzufrieden sind.
Warum sind UnitTests wichtig?
Tests sind in der Tat nicht nur in der Release-Phase wichtig. Sie erhöhen auch gleichzeitig direkt deine Produktivität.
Sagen wir mal, du schreibst eine interne Software. Die Anzahl der Bugs ist irrelevant, da du die „mal eben“ korrigieren kannst. Es beschwert sich auch keiner, wenn etwas kaputtgeht. Die Lebensspanne der Software ist auch sehr kurz.
UnitTests? Ja, unbedingt!
Beispiel 1: Einfache UI
Sagen wir mal, du hast eine Eingabemaske in der du den Vor- und Nachnamen einer Person eingibst. Anschließend soll diese Person in die Datenbank geschrieben werden. Aber auch nur, wenn es noch keinen entsprechenden Eintrag gibt.
Was meinst du, wie oft du deine Software starten musst und immer wieder aufs neue den Namen einzugeben und auf Speichern zu drücken?
Sobald du UnitTests hast, kannst du diese Operation mit einem Mausklick (oder einer Tastenkombination) direkt ausführen!
Beispiel 2: Game of Life
Kennst du eigentlich das Game Of Life? Der Algorithmus steht jetzt einfach mal für irgendeinen etwas komplexen Algorithmus.
Ich weiß nicht, wie es dir geht, ich für meinen Teil bin in meiner Vorstellungskraft etwas eingeschränkt. Ich kann auch nicht in einer vierten oder fünften Dimension denken. Bei maximal 3 ist bei mir Schluss. Auch solche Späßchen wie „Wenn es gestern geregnet hat, wie wird das Wetter morgen?“.
Das „Game of Life“ besteht eigentlich nur einer Handvoll Regeln. Beachtet man jedoch eine dieser Regeln nicht, funktioniert der komplette Algorithmus nicht mehr. Anschließend kann es passieren, dass du länger am Debuggen bist als zu entwickeln.
Allein durch die Tests kannst du jedoch den Algorithmus anhand von dem vorher fest definierten Ergebnis nachbauen.
Beispiel 3: Backend
Kommen wir zur „Königsdisziplin“ bei der du ohne UnitTests keine Chance mehr hast.
Ähm … doch … indem du dir drölf TestGUIs in deinem Backend Projekt erstellst und anhand der von dir festgelegten Testdaten testest, ob der Code genau so funktioniert, wie du es dir vorher vorgestellt hast. In der Regel existiert da aber keine GUI.
Mit anderen Worten: Spätestens wenn du Backend Entwicklung machen möchtest/musst, musst du UnitTests schreiben. Einfach schon aufgrund der Tatsache, dass du sehr viele verschiedene Fälle beachten musst und nicht einfach nur davon ausgehen, dass es funktioniert, weil: „Das sieht man doch!„
Fazit
Wir als Softwareentwickler haben – glaube ich – alle dasselbe Bedürfnis. Möglichst stabile und qualitativ hochwertige Software abzuliefern.
Allein der Einsatz von UnitTests bringt dein Können auf das nächste Level. Du wirst nicht nur kurzfristig, sondern auch (vor allem) langfristig davon profitieren.
- Du sparst dir Zeit und auch Geld!
- Deine Software wird stabiler.
- Du bleibst konkurrenzfähig.
Ich hoffe, ich konnte dir aufzeigen, warum UnitTests wichtig sind und dass UnitTests auch bei dir künftig Einsatz finden.
Und wenn du wissen möchtest, wie ein richtig guter UnitTest aussieht, kannst du gerne hier weiterlesen.