Letzte Änderung am 20. Mai 2018 by Christoph Jüngling
Oh, hoppla, noch ein vergessener Artikel! Ich glaube, ich brauche Tests für mein Blog. Was man so alles findet, wenn man im Weihnachtsurlaub mal wieder das eigene Blog durchstöbert :-) Sorry, Paul, war keine Absicht!
Der Artikel passt gut in meine aktuelle Thematik, auch wenn er nichts mit Python zu tun hat. Aber das Grundprinzip von Software-Tests ist sprachenunabhängig.
Es war einmal, im April 2015, auf der SNEK 4, …
“Warum testen wir Software?” — Nach der Frage von Paul Rohorzka herrscht zunächst völlige Stille. Die Frage ist allerdings auch sehr vielschichtig, ebenso wie das Thema. Es gibt viele verschiedene Arten von Tests. Je nachdem wann und zu welchem Zweck man testet, wird man auch andere Werkzeuge benötigen.
Da gibt es die Pyramide nach Mike Cohn (Google-Suche). Zuunterst finden wir die Unit-Tests. Deren Komplexität sollte sehr gering sein, so dass sie in großer Zahl für unsere Funktionen erstellbar und durchführbar sind.
Die Akzeptanzkriterien folgen danach, oben stehen die Workflowtests. Aber egal wie stark der Grad der Automatisierung getrieben wurde, es sollte am Ende immer noch ein Mensch davor sitzen, der die Software nach Gefühl und Benutzbarkeit beurteilt. Dies nennt man “Exploratives Testen”. Wenn alle zuvor genannten Schritte automatisiert sind, ist dieser letzte Schritt damit auch der teuersten Ressource vorbehalten.
Auch die Sichtweise unterscheidet die Tests: Ob technische Sicht oder Anwendersicht wird entscheidend beeinflussen, was und wie getestet wird.
Testgetriebene Entwicklung
“Test Driven Development” oder kurz TDD bedeutet: Erst der Test, dann die Funktion. Dies funktioniert für den, der es noch nicht kennt, auf eine “pervers andere Art” (O-Ton Rohorzka). Zunächst wird ein Test geschrieben, der definitiv fehlschlagen wird, weil er voraussetzt, dass die Funktion existiert. Was sie nicht tut. Dann wird genau so viel Code geschrieben, dass der Test “grün” wird. So geht es stückweise weiter, bis die Funktion fertig ist. Zwischendurch werden beliebig viele Refactoring-Schritte eingefügt, damit der Code lesbar bleibt. Dies wird von vielen IDEs unterstützt, so auch Visual Studio (und Eclipse, wie ich heute hinzufügen möchte)
Der Vorteil dieser umgekehrten Vorgehensweise ist der, dass ich zu Beginn darüber nachdenke, was ich eigentlich erreichen will. Wenn mir das klar ist, ist der halbe Weg zur Lösung bereits gegangen.
Nebenbei gibt es noch:
- BDD – Behaviour Driven Development
- ATDD – Acceptance Driven Development
Wenn alle Tests erfolgreich durchgeführt wurden, kann von einer funktionsfähigen Software gemäß den Anforderungen ausgegangen werden.
Unit-Tests sind übrigens bereits in der Visual Studio Express Version 2013 enthalten, die für kleine Unternehmen kostenfrei zur Verfügung steht.
Der Rest des Vortrags ist ein großes Demo.
Die Benamung von Testroutinen ist für das Verständnis dessen, was getestet wird, sehr wichtig. Paul verwendet die Nomenklatur Funktionsname_Zweck_ErwartetesErgebnis().
“Der Compiler ist unser bester Freund”
Wenn der Compiler eine Funktion nicht kennt, ist der Test ohne jeden Zweifel fehlgeschlagen. Daraufhin werden die notwendigen Klassen und Methoden implementiert, wiederum nur als Rumpf. Dann wird der Test grün. Nun schreiben wir die Testfunktion. Diese besteht klassischerweise aus drei Teilen. Wenn man dieses Konzept einhält, bleiben auch die Testroutinen übersichtlich.
- Arrange: Herstellen der notwendigen Vorbereitungen
- Act: Durchführung der Aktionen
- Assert: Überprüfung der Annahmen für den Test
Tools für Tests
Zum Abschluss präsentiert Paul noch ein paar Tools.
SPECFLOW (Open Source)
Spezifikationen in natürlicher Sprache (eine DSL) erfassen, Specflow macht daraus (bei bestimmten Formulierungen) Unit-Tests. Es wird auch das “Cucumber for .NET” genannt (Cucumber ist das Tool für Ruby). Die verwendete Sprache ist “Gherkin” (Gurke).
Specflow schlägt die Brücke von in natürlicher Sprache formulierten Anforderungen zu automatisch generierten Unit-Tests.
SELENIUM WEBDRIVER
Automatisierung von GUI-Tests via Browser. Auch als Dienst zu verwenden, der verschiedene Betriebssysteme mit verschiedenen Browsern in verschiedenen Versionen anbietet, auf denen die Tests dann laufen können.
Neueste Kommentare