Dieser Audiobeitrag wird von der Universität Erlangen-Nürnberg präsentiert.

Ja, schönen guten Morgen. Sie haben es mitbekommen, wir hatten etwas mit den Typen der Technik zu kämpfen.

Normalerweise wäre das ein Vortrag mit dem einen oder anderen Praxisanteil.

Typischerweise hätte ich Ihnen jetzt Kot gezeigt, aufgrund der fortgeschrittenen Zeit

und der Tatsache, dass wir jetzt den Code nicht auf dieser Maschine hier drauf haben,

wo wir präsentieren werden, kann ich Ihnen halt im Wesentlichen nur erzählen,

was ich Ihnen hätte zeigen können und werde später letztendlich noch mal auf das Codebeispiel verweisen.

Ich hoffe, es wird nicht zu trocken dann an der Stelle.

Vielleicht vorab noch ein Disclaimer. Im Rahmen des Vortrags werden wir relativ viele Open Source Frameworks

nennen und vorstellen bzw. möglicherweise für Sie auch relativ weit in die Thematik Integrations-Tests einsteigen.

Verstehen Sie das bitte zum einen nicht so, dass man letztendlich in der kommerziellen Softwareentwicklung

alles zwingendermaßen so umsetzen müsste, wie wir das jetzt vorstellen.

Die Dinge sollen mehr als Denkanstoß verstanden werden, was wir letztendlich für typische Probleme,

für Lösungsansätze bieten können und welche Werkzeugungen uns im Zweifelsfall helfen können, diese Probleme zu lösen.

Der Vortrag nennt sich Tools in the Test Pyramid. If one size doesn't fit all.

Im Grunde genommen möchten wir das kleine Versprechen erfüllen, Ihnen kleinen Werkzeugkasten für die Lösung von Testproblematiken an die Hand zu geben.

Steigen wir mal ein in die Thematik. Wenn wir Software entwickeln, ist es unser wesentliches Ziel,

diese am Ende des Tages zum Kunden ausliefern zu können. Und das können wir typischerweise nur dann tun,

wenn wir uns sicher sind, dass das, was wir implementiert haben, im besten Fall funktioniert und auch noch sozusagen

den Wünschen des Kunden entspricht. Jetzt stellt sich natürlich die Frage, wie kommen wir in diesen Zustand?

Wir könnten manuell stundenlang, tagellang testen und das finden Sie draußen der Praxis auch relativ häufig vor Ort.

Viel besser wäre es natürlich, wenn man am Ende des Tages auf Knopfdruck und in möglichst kurzer Zeit entscheiden könnte,

dass das, was wir implementiert haben, genau das ist, was der Kunde möchte und das im Übrigen auch noch so funktioniert,

wie wir uns das vorgestellt haben. Insofern, wenn wir das Ziel haben, unsere Tests möglichst schnell durchführen zu können,

dann müssten wir die vermutlich automatisieren und stellt sich die Frage, naja gut, was müssten wir denn eigentlich

überhaupt zu alles testen, welche Arten von Tests müssten wir berücksichtigen, um eine möglichst gute Aussagekraft zu kommen

und wollen dann genauer beleuchten, naja, wie ist denn so ein Test eigentlich typischerweise zusammengesetzt,

insbesondere wenn wir uns von der Unit-Test-Ebene, by the way, Sie kennen alle Unit-Tests, haben Sie schon geschrieben?

Ist Ihnen bekannt das Verfahren? Sehr schön. Und wie würden wir diese Tests, sofern wir uns die Frage beantwortet haben,

wo wir die denn letztendlich zusammengesetzt sind, möglichst leichtgewichtig implementieren

und welche Werkzeuge helfen uns möglicherweise, das zu erreichen?

Ja, das führt uns dann direkt zu unserer Agenda, wie wir heute vorgehen möchten.

Zunächst werde ich Ihnen ein sehr, sehr einfaches und simplifiziertes Modell vorstellen,

wie man möglichst effizient Tests verteilen könnte. Das ist die sogenannte Testpyramide.

Das haben wir nicht erfunden, oder ich nicht erfunden, sondern Leute, die sich viel länger mit Agilität und Ähnlichem beschäftigen.

Wir werden kurz eine Beispielapplikation, zumindest uns jetzt verbal vorstellen. Live werden wir sie nicht wirklich sehen können.

Und uns dran den vier Schritten des Integrationstests widmen, nämlich der Testinitialisierung oder der Initialisierung des Testsystems,

das Befüllen der erforderlichen Daten oder abhängigen Daten. Wir werden die Frage beleuchten,

wie wir mit abhängigen Systemen umgehen können und am Ende des Tages,

wie wir vielleicht einen erfolgreichen Testlauf durchführen können, wo letztendlich auch eine Fachabteilung

oder ein Kunde noch einen Eindruck bekommt, dass das, was da getestet wurde, A, transparent ist und B, das ist, was man sich vorgestellt hat.

Steigen wir doch direkt mal ein in die sogenannte Testpyramide. Wer kennt die denn von Ihnen?

Haben Sie die schon mal gehört, oder? Sagt Ihnen nichts.

Die Testpyramide ist ein sehr vereinfachtes Modell, wie optimal unsere Tests für eine Software möglichst effizient verteilt werden können.

Im Wesentlichen bezagt sie, dass wenn wir Code schreiben, sprich Methoden und Klassen,

wir es sehr einfach haben, möglichst viele Varianten letztendlich von Tests zu schreiben.

Und diese sind in ihrer Ausführungsdauer typischerweise, je näher wir oder wie direkter wir beim Schreiben des Codes sind, sehr gering.

Und aufgrund der Tatsache, dass die Ausführungsdauer und die Komplexität dessen, was wir letztendlich testen wollen,

auf Methoden eben beispielsweise nicht sonderlich groß ist, können wir einfach sehr einfach mit wenig Setup Code relativ viele Tests schreiben.

Komplexer wird das Ganze, wenn wir letztendlich daran gehen, verschiedene Komponenten oder externe Abhängigkeiten zu verknüpfen.