Automatisierte Tests – Unit, Functional Tests und Test Driven Development

Wie kann ich als Unternehmen neue Software effektiv testen? Warum gibt es automatische Tests überhaupt und wo liegt der Unterschied? Und wieso ist das "Wasserfallmodell der Softwareentwicklung" nicht mehr Nonplusultra?

Wir liefern die Antworten und passende Lösungen.

Im klassischen „Wasserfallmodell der Softwareentwicklung“ wird eine Software erst definiert, dann umgesetzt und ganz am Ende getestet. Dies hat den Vorteil, dass die Software nur einmal vollumfänglich getestet werden muss.

Allerdings hat diese Art der Softwareentwicklung darüber hinaus große Nachteile. Zum Beispiel dass man erst ganz am Ende feststellt, wenn die Software den echten Anforderungen der Benutzer nicht so gut entspricht, wie man anfangs gehofft hat.

Aus diesem Grunde arbeiten wir von Ambient Innovation nach dem agilen Modell: Hierbei wird die Software in kurzen Iterationen - von zum Beispiel zwei Wochen - entwickelt. Am Ende jeder Iteration steht eine neue, funktionsfähige Version der Anwendung.

Bereits sehr früh im Projekt gibt es also eine einfache Version, in welcher die wichtigsten Funktionen in simpler Form enthalten sind. Anschließend erweitern wir die Software nach und nach um weitere Funktionen. So können wir gemeinsam mit dem Kunden sicherstellen, dass Nutzerfeedback früh eingeholt wird und wir flexibel auf Änderungen reagieren können.

UND WARUM SCHREIBEN WIR AUTOMATISIERTE TESTS?

Automatisierte Tests

Dieses Vorgehen hat Implikationen für das Testen der Software: Nach jeder Version müssen die neuen Funktionen getestet werden. Es muss aber auch getestet werden, dass durch die neuen Funktionen nicht versehentlich eine der bereits bestehenden Funktionen beeinträchtigt wurde.

Der Aufwand dies manuell zu tun, steigt also mit der Anzahl an Releases. Aus diesem Grund automatisieren wir die Tests. Anstatt bei jeder Version alles neu zu testen, schreiben wir für die neuen Funktionen automatisierte Tests. Die bereits bestehenden Funktionen werden dann von den zuvor entwickelten Tests automatisch abgedeckt, so dass ich sicher sein kann, dass keine bereits bestehenden Funktionen kaputt gegangen sind. Das Schreiben von automatisierten Tests spart also Zeit – Eine Investition, die sich schon nach den ersten Wochen lohnt.

Darüber hinaus bringen automatisierte Tests weitere Vorteile:

  • Die definierten Anforderungen an die Funktionen (die sogenannten „Akzeptanzkriterien“) werden durch die Tests fixiert und dokumentiert.
  • Zukünftige Modernisierungen (zum Beispiel strukturelle Anpassungen auf geänderte Anforderungen oder Updates von genutzten Komponenten, sog. Refactoring) werden einfacher, weil ich sicher sein kann, keine Funktionen kaputt zu machen. Der Mut zu Modernisierungen wächst und die Software kann leichter modern gehalten werden.

Arten automatisierter Tests

Je nach Ziel und Art der Umsetzung unterscheiden wir zwischen verschiedenen Tests:

Akzeptanztests und Functional Tests:

Akzeptanztests testen die Akzeptanzkriterien an eine Funktion aus Sicht des Benutzers. Sie testen also das, was der Product Owner/Kunde auch manuell testen würde. Ein Akzeptanzkriterium könnte beispielsweise sein „Wenn ich als Käufer mindestens einen Artikel im Warenkorb habe, wird auf der Seite ein Warenkorb-Icon angezeigt“. Bei der Abnahme der Funktion würde ich dies also testen, indem ich einen Artikel in den Warenkorb lege und dann nach dem Icon auf dem Screen suche. Dies kann mit entsprechender Software automatisiert gemacht werden.

Die Art des hier beschriebenen Tests wird auch als „Functional Test“ bezeichnet, weil er eine inhaltliche Funktion testet und nicht die dahinterliegende technische Funktion. Es ist also egal, wie die technische Umsetzung genau gemacht wurde. Auch wenn diese in Zukunft angepasst wird, sollte das Ergebnis (Warenkorb-Icon wird angezeigt) gleich bleiben.

Unit Tests:

Unit Tests testen einzelne technische Methoden und schauen dabei im Unterschied zu den Functional Tests auf das „wie?“. Hier könnte beispielswiese getestet werden, ob eine Funktion „add_to_basket()“ die Anzahl der Artikel im Warenkorb korrekt erhöht, wenn sie aufgerufen wird. Unit Tests helfen vor allem dabei, den Code besser zu strukturieren und grenzen im Falle eines Fehlers die möglichen Ursachen ein.

Lasttests:

Lasttest prüfen, wie sich die Software unter einer bestimmten (in der Regel hohen) Last verhält. Durch solche Tests kann sichergestellt werden, dass die Anwendung auch bei vielen gleichzeitigen Benutzer (beispielsweise nach einer intensiven Werbung oder Aktion) benutzbar bleibt und in einer angemessenen Zeit reagiert.

Testing Tools

Tools für Unit Tests sind meist in den Frameworks enthalten. Beispiele hierfür sind:

  • unittest, das Unit Testing Framework der Python Standard Library.
  • Jest, eine Testing Library für JavaScript.
  • Enzyme, eine Sammlung von Test-Tools für React, welche von AirBnB entwickelt wurde.
  • Die React Testing Library, eine Hilfe zum Testen von React Komponenten.

Tools für Akzeptanztests sind in der Regel losgelöst von der genutzten Technologie, weil sie die Anwendung ja aus Nutzersicht testen. Beispiele hierfür sind:

  • Selenium, ein Tool zur Automatisierung der Bedienung eines Browsers, welches häufig für Tests genutzt wird.
  • Cypress, eine Alternative zu Selenium, welche aus unserer Sicht etwas moderner und einfacher ist.
  • TestCafe, ebenfalls eine Alternative zur Automatisierung von Browser-Tests.

Lasttest führen wir mit Locust durch.

Test Driven Development

Beim sogenannten "Test Driven Development" schreibt man die Tests nicht nach der eigentlichen Entwicklung, sondern davor. Man schreibt also erst einen Test, welcher beispielsweise die Akzeptanzkriterien testet (Ist ein Warenkorb-Icon sichtbar, wenn mindestens ein Artikel hinzugefügt wurde?). Dieser schlägt natürlich fehl, weil der entsprechende Code ja noch gar nicht geschrieben wurde. Anschließend implementiert man die Funktion, bis der Tests letztlich erfolgreich läuft.

Test Driven Development

Dieses Vorgehen bei der Entwicklung hat einige Vorteile:

  • Man wird gezwungen, die Anforderungen an die Funktionen zu kennen und kommt gar nicht erst in Versuchung drauf los zu entwickeln.
  • Man stellt sicher, dass der Test auch wirklich fehlschlägt. So kann es nicht passieren, dass der Test (aufgrund eines Fehlers in der Test-Logik) immer erfolgreich ist.

Möchten Sie professionelle automatisierte Tests in Ihrem Unternehmen durchführen?

Gehen Sie den ersten Schritt und nehmen Sie Kontakt zu uns auf!
Wir freuen uns auf Sie.

Rufen Sie uns jetzt an