Dann vielleicht in diesem speziellen Fall, ist keine Test
Pyramide, sondern Quadrat ist wichtig.
An der Stelle ist würde ich sagen.
Das ja dein Podcast rund um Softwareentwicklung und
aktueller. Tech News herzlich willkommen.
Ja, herzlich Willkommen zur neuen Folge des Coding Bodies
Podcast. Es geht mal wieder los.
Neue Folge steht an, natürlich wieder mal mit dabei meine
Wenigkeit, der Tino und wie immer der phantastische Fabi.
Moin Fabi, grüß dich. Guten Morgen, oder?
Ja, guten Mittag. Guten Mittag Nachmittag ja heute
schon bisschen später wir die Folge aufnehmen, aber ist nicht
so schlimm. Draußen ist es sehr windig und
regnerisch deswegen was kann es Schöneres geben als jetzt n
kleinen Talk hier durchzuführen. Ich freue mich drauf, wir haben
auch ein ganz spannendes Thema. Heute aber, bevor wir darauf
eingehen, möchte ich nochmal ein bisschen Revue passieren lassen,
was die Tage so passiert ist. Wir haben ja jetzt angefangen
auf Twitch zu streamen, das war ja noch ein Versprechen, dass
wir quasi auch live Coding Sessions machen.
Damit haben wir jetzt angefangen und was für eine Erfahrung, oder
das muss ich nochmal kurz mit dir thematisieren.
Ja, das war krass haben. Wir vorher noch nie gemacht.
Twitch zu Stream fand ich auf jeden Fall.
Total geil kann auf jeden Fall n Favorit von mir werden, muss ich
sagen. Ja, das Macht auf jeden Fall
Spaß. Ich war extrem aufgeregt, also
in dem Moment, wo es losging, war ich super nervös, weil ich
einfach gar nicht wusste, was mich da jetzt erwartet, man hat
ja halt auch gar keine Routine wie du meintest.
Es war ja das erste Mal und erstmal shoutout an die Leute,
die bis jetzt dabei waren, super cool, ja voll super cool
aufgenommen, ne. Total geile Atmosphäre fand ich
also auch genauso wie wir uns das ja auch eigentlich Wünschen
von unserer Community. Das ist ja genau sozusagen das
Feeling, was wir darin aufbauen wollen, dass jeder sich
irgendwie zufrieden, aufgehoben, gut aufgehoben fühlt.
Und dann haben sie entspannter Austausch halt auch stattfindet
ne und quasi ja eigentlich auch jeder was dabei lernen kann.
Das finde ich halt auch cool. Also auch wir haben ja
mittlerweile wieder Sachen dazu gelernt, richtig cool, deswegen
nochmal kleine Aufruf. Die Zuhörer, die Zuhörer.
Falls du noch nicht dabei warst, bei uns auf Twitch, schau doch
gerne mal vorbei und sei einfach Teil unserer Community und
engagiere dich da. Das wäre cool, würde uns auf
jeden Fall sehr freuen, unbedingt.
Kommt rein in den in die Streams genau der Link dazu.
Der müsste auch in den Show Notes sein und ansonsten ja bei
bei Instagram und so, wenn ihr da noch nicht seid auch mal
vorbei gucken und da kündigen wir das auch an.
Genau da kündigen wir an, wann wir online sind.
Und dann sehen wir uns doch hoffentlich da.
Aber jetzt würde ich sagen, lass uns mit der Podcast Folge
anfangen. Wir haben ganz cooles Thema
vorbereitet, was wir mal diskutieren wollen.
Magst du das Thema mal ganz kurz vorstellen, Fabi, Juhu.
Es geht natürlich mal wieder um das wunderbare Thema testen.
Vielleicht kannst der dem einen oder der anderen schon aus den
Ohren raus, aber am Ende ist es doch einfach wichtig, dass man
seine Software testet. Es gibt ja auch so ne richtige
Art von. Ich sag mal Theorie hinterm
testen. Ne.
Also zum Beispiel wenn man uns jetzt, wenn man sich jetzt mal
die Häufigkeit oder die Menge der Tests anguckt, die man so
hat im Verhältnis, also es gibt ja nicht nur.
Also den Test ist ja nicht gleich ein Test.
Es gibt ja verschiedene Arten von Tests und.
Ja, und diese Tests, wenn du, wenn man die jetzt sozusagen
bisschen anordnet in der Häufigkeit, dann kriegt man so
eine Art Pyramide zusammen. Das heißt, es gibt verschiedene
Pyramiden, also Test Pyramiden, aber wir gehen jetzt mal auf
eine, sag ich jetzt mal Standard Pyramide ein, das ist sozusagen
das oben im Kopf der Pyramide, in dem kleinen Teil, da gibt es
sogenannte System Tests, darunter kommen dann so
Integration, Tests und ganz unten Community Test Test.
Das heißt, wir haben im Normalfall hat man oder gibt es
so n so n. Wie sagt man ein Modell dieser
Test Pyramide, wo man ganz viele Unit Tests hat, dann bisschen
weniger oder n Stück weniger Integration Tests und am
wenigsten Tests gibt es von den System Tests.
Genau habe ich das soweit auch zu Deiner Zufriedenheit erklärt
Tino. Ja, auf jeden Fall genau.
Ich hoffe, dass sich jeder Zuhörer zuhören jetzt vorstellen
kann, wie eine Pyramide in dem Sinne aussieht, aber ich finde,
das hast du ganz gut erklärt. Oben ist die Spitze, oben ist
die Spitze. Genau das ist halt einfach, um
die Menge der Tests geht oder wie viele man davon denn
implementiert. Genau.
Plementieren sollte oder nicht, das ist, glaube ich, genau der
Schwerpunkt, über den wir heute reden wollen, aber
grundsätzlich, ja genau, wollen wir aber mal bitte kurz
erklären, was die einzelnen Arten sind.
Also du hast jetzt gesagt, wir haben System Test, darunter
kommen die Integration Tests und darunter die Unit Test.
Genau so haben wir jetzt mal unsere Pyramide.
Jetzt hier in dem Fall aufgebaut ne, weil das halt eigentlich ja
wie du meintest n Standard ist. Ja.
Wie gesagt, dann lass doch mal anfangen.
Ja genau, genau also wie es halt so mit Modellen ist.
Irgendwie erweitert sie, irgendwann werden sie wieder
vermindert und so weiter ne genau, aber lass uns doch mal
über Unit Tests anfangen zu reden, weil das ja laut der
Pyramide eigentlich die Tests sind, die am meisten innerhalb
einer Software vorkommen. Genau Unit steht für Einheit,
das heißt wir sind quasi auf. Eine Code Einheit bezogen auf
der Ebene unterwegs, um dafür Test zu schreiben.
Genau. Sprich für einzelne Funktionen
beispielsweise oder für einzelne Klassen.
Richtig, genau. Und dann nur innerhalb sozusagen
dieser Klassen oder Funktionen. Also ne, dass man sozusagen
nicht daraus aus diesem, aus dieser Unit, aus diesem quasi
aus diesem Gefängnis, dieser Unit ausgerichtet, ja.
Also beispielsweise wir haben. Zum Beispiel eine Klasse, die
eine Person beschreibt. Und wir wollen halt einfach
wissen, ob beispielsweise der vor und Nachname richtig
gespeichert und ausgegeben wird. Ne, also einfache Getter und
Setter testen zum Beispiel ja, könnte man sagen, wer jetzt ein
Unit Test oder man hat irgendeine mathematische Formeln
berechnet, keine Ahnung, die fünfte Fibonacci Zahl, also ganz
klassischen Beispiele, das sind ja einzelne Funktionen, die man
ja super abtesten kann und da wäre man ja auf dieser Unit
Ebene. Gehst du damit?
Genau. Also im Endeffekt ist das ja so
vom Prinzip her, dass wir sagen, es gibt eine Eingabe und wir
kriegen ne Ausgabe und genau das können wir testen, also wir
können quasi unsere Erwartungshaltungen für diese
Funktion, für diese Klasse oder für diese Einheit eben für diese
Unit genau definieren und spezifizieren und genau, und
wenn wir jetzt sagen, wir haben angenommen, 10 Funktionen
innerhalb einer Klasse mal als Beispiel und wir müssen
verschiedenste Erwartungen und Spezifikationen abtesten, dann
gibt es vielleicht. Ich jongliere einfach mal mit
ein paar Zahlen, so. Für jede Funktion gibt es 5
Tests, das heißt bei 10 Funktionen haben wir dann 50
Tests beispielsweise ne. Und das ist im Endeffekt ja auch
der Grund dadurch, dass man halt so viel abtesten muss für die
einzelne Funktion. Es kommt natürlich auf die
Funktionen an, ne, aber jedem umfangreicher die Funktion ist
oder auch beispielsweise wenn sie mehr eingabeparameter hat,
müssen wir natürlich auch mehr Kombinationen, beispielsweise
abtesten und dadurch steigt diese Anzahl der Unit Tests.
Selbst für eine Funktion eigentlich relativ schnell an
genau was erklärt, warum die Pyramide, also warum Unit Tests
ganz unten stehen, weil man da halt wirklich schnell in die
Breite kommt. Richtig, aber Unit Tests sind ja
zum Beispiel auch die Arten von Tests, die am günstigsten sind.
Ne, also mit günstig meinte ich jetzt zum Beispiel, dass sie
durchaus sehr schnell laufen. Ja, das ist halt unter anderem
wichtig, weil angenommen sagen wir mal, man testet jetzt
vielleicht so, also man lässt seine Tests laufen lokal auf
seiner Maschine, auf seiner Entwicklungs Maschine.
Bevor man irgendwie was ins Repository einchecken möchte,
dann möchte man natürlich nicht jedes Mal.
Also es ist natürlich schön, wenn Tests schnell durchlaufen,
weil dann hast du innerhalb von kürzester Zeit ein Ergebnis, ob
alle Tests grün sind, ob deine Software quasi deinen
Spezifikationen und deinen Erwartungen unterliegt und es
ist natürlich hinderlich, wenn man jetzt, OK ich weiß nicht,
lass meine Tests laufen, dann dauerts ne Stunde oder so und
dann weiß man eigentlich erst o kann ich jetzt zum Beispiel
diesen mitmachen, kann ich weitermachen, was auch immer.
Und da haben halt Unit Tests eben die sag ich mal, schöne
Eigenschaft, dass sie sehr schnell sind.
Das heißt, viele Tests sind nicht schlimm, weil sie sehr
schnell durchlaufen. Ne genau also mit sehr schnell
reden wir davon, dass ein paar Sekunden erledigt sein kann,
wenn man auch hunderte Tests hat, ne?
Genau, ja. Genau das ist eigentlich ein
guter Punkt und auch eine wichtige Eigenschaft.
Würdest du sagen, dass diese Art von Tests, also Unit Test, dann
eigentlich auch die Tests sind, dass man sagen kann, das sind
die Entwickler, Tests also. Ich will jetzt zum Beispiel ein
neues Feature entwickeln und möchte das Abtesten, was ich
entwickelt habe, fange ich dann an, Unit Tests dafür zu
schreiben oder gehe ich doch eher Ebenen weiter o höher also.
Ich kenne das so, ist wahrscheinlich, da gibt es
sicherlich auch unterschiedliche Meinungen zu, wenn man jetzt mal
so richtig nach. Ich sag mal nach einer Lehrbuch
Variante geht die ich kenne zum Beispiel, was aber auch ehrlich
gesagt auch ne schwierige Herangehensweise ist.
Einfach vom Kopf her finde ich ist, dass man anfängt und erst
mal für ein bestimmtes Feature was man entwickelt erstmal auch
einen System Test schreibt was ist gesagt wollen wir gleich
nochmal darauf eingehen, danach gilt man runter und fängt zum
Beispiel bei den integrations Tests an und geht dann runter
und fängt bei den Unit Tests. So, und wenn man das hat.
Also macht man so einen Top Down Ansatz.
Also ich fang an quasi auf oberster Ebene zu testen und
geht dann in die Tiefe. Interessant O.
K also diesen Ansatz gibt es auf jeden Fall.
Ich muss aber auch dazu sagen, dass ich zum Beispiel wir ja
auch eher weniger diesen Ansatz fahren, sondern wir fangen quasi
von Bottom an, also wir sagen, OK, wir schreiben erstmal den
Test für die Unit, entwickeln die Unit und gehen dann quasi,
hangeln uns nach oben durch, es ist aber im Endeffekt auch so n
bisschen ne Frage, wie man an die Sache rangehen.
Möchte aber ich denke beides. Ich kann mir vorstellen, ja, ich
kann mir vorstellen, warum man den Top Down Ansatz fahren kann
oder manche dafür argumentieren. Das würde ich aber später noch
mal argumentieren oder begründen oder diskutieren.
Lass uns mal jetzt nochmal weiter gehen.
Also wir haben jetzt auf Unit Ebene quasi können wir unsere
Software abtesten das heißt die einzelnen Funktionen
beispielsweise einer Klasse genau das ist ja erst mal ganz
cool, jetzt haben wir alle Klassen abgetestet, das heißt
jede Klasse. In sich ja, ist abgedeckt und
funktioniert so wie wir wollen. Warum?
Gibt es jetzt noch mehr Arten von Tests, also beispielsweise
die Integration Tests? Also.
Jetzt logischerweise in der Pyramide auf der nächsten Stufe
kommen. Genau.
Also wenn wir jetzt mal ganz abstrakt, ich kann erstmal ein
bisschen abstrakt beschreiben, und dann können wir auch nur auf
explizites Beispiel eingehen, Integration, Test sagt der Name
ja schon, dass man vielleicht zum Beispiel eine Unit in andere
Unit integriert, das heißt oder ne, du hast irgendwie NN Code
und der benutzt jetzt zum Beispiel ein anderes Stück Code,
nutzt ne Funktion aus. In der Klasse.
Und arbeitet damit. Und dann ist ja die Frage,
möchtest du jetzt genau, also angenommen du hast jetzt ne
Funktion, die sagt für diese, für diese Oberklasse, die
sozusagen eine eine Klasse mit einer Funktion darin benutzt,
möchtest du dann sagen, diese Funktion die keine Ahnung, sag
mal addition die da gemacht wird für eine komplexere Berechnung
wie zum Beispiel den Abstand zwischen 2 Punkten ne, dafür
benutzt du zum Beispiel die Funktion einer, also eine
additions Funktion. Wie du selbst geschrieben hast
du getestet, aber möchtest du jetzt nochmal in dieser sag ich
mal klasse die dir die die den Abstand zwischen 2 Punkten
berechnet. Möchtest du jetzt noch mal alle
Möglichkeiten der Addition plus das was sozusagen obendrauf
kommt mit der Berechnung der des Abstands der 2 Punkte abtesten
ne und das ist da wäre die Antwort meiner Meinung nach ganz
klar nein. Also du hast sozusagen diese
einzelne Funktionen getestet, diese zum Beispiel Addition und
sagst okay funktioniert, da gehe ich, da bin ich mir sicher.
Ich hab Tests dazu und die funktionieren so und jetzt
möchte ich nur noch wissen, wenn ich diesen wenn ich Punkt A und
Punkt b habe, dann war es meine Erwartungen, dass ich sozusagen
den Abstand XY bekomme, was auch immer ne, also du hast wieder
eine Eingabe und Ausgabe und kannst mit der Annahme hingehen
und sagen. Diese Funktion, die ich darüber
benutze, die habe ich getestet und funktionieren ne, aber das
ist sozusagen diese Art von Integration.
Mal ein konkretes Beispiel, was ich zum Beispiel aus aus eigener
Erfahrung kenne. Unter Integrationstests sind zum
Beispiel auch wenn man Frameworks benutzt ne, also
angenommen du hast jetzt zum Beispiel in Spring Boot
Framework, das kenne ich zum Beispiel und damit hab ich zum
Beispiel entwickelt. Haben wir auch zusammen schon
gemacht. Ja.
In unserer Freizeit sozusagen. Aber wenn man jetzt zum
Beispiel, da kannst du auch Unit Tests schreiben und diese Unit
Tests, die fahren zum Beispiel nicht, also spring hat ja ein
Framework Kontext und dieser Framework Kontext, der wird
nicht hochgefahren oder nicht aufgebaut, was natürlich
zeitintensiv ist. Das heißt wenn du jetzt aber zum
Beispiel eine API, also eine Rest API zum Beispiel mit Spring
Boot entwickelst und dagegen sozusagen deine Test schreiben
möchtest. Also um wirklich zu gucken.
Es kommt ein Call meine API rein.
Die Anfrage wird quasi verarbeitet und es wird zum
Beispiel auch richtig in der Datenbank gespeichert.
Also diese diese, da hat man ja mehrere Komponenten.
Man hat die Datenbank mit drin, man hat seinen Spring Boot
Server sozusagen, der läuft drin und du hast ne sozusagen ne
Eingabe, das ist sozusagen deine Anfrage.
OK, also kann man da noch mal kurz vereinfacht sagen.
Ich hab NN Verbund an Komponenten oder Bestandteile
der Software zusammengeschlossen genau und teste diesen Verbund
ab, das heißt es ist nicht die gesamte Software, aber es ist
ein Freischnitt aus dieser Software um beispielsweise ein
Feature wie du ja meinen zum Beispiel Ich krieg ne Anfrage
auf dem Endpunkt Speicher mir den neuen Benutzer der sich
gerade registriert hat und das Backend jetzt Spring Boot was du
meintest nimmt diese Anfrage entgegen weil die wahrscheinlich
ob der Nutzer vielleicht können noch nicht vergeben ist.
Irgendwas und speichert es dann in die Datenbank und das kann
ich als ganzen Verbund. Abtenau.
Ich kann natürlich genauso testen wie quasi welche Anfragen
kommen rein nur auf der Ebene ist das eine gültige Anfrage
oder nicht, aber hab denn die Datenbank beispielsweise nicht
drin? Genau und dann hast du halt sag
ich mal diesen Verbund, dass du einmal die Kette.
Bis dahin quasi abtesten kann. Und so kannst du denn sozusagen
feature weise ja auch schon. Tests schreiben richtig und
damit hast du ja genau und damit hat man ja jetzt an dieser
Stelle nur den Server Teil abgetestet weil angenommen du
hast ne ganze Anwendung die aus Frontend und Backend besteht,
dann ist das Frontend ja an der Stelle nicht getestet so aber du
kannst natürlich für dein Backend.
Unit Tests schreiben und Integration Tests schreiben,
wobei man halt jetzt sagen muss, dass die Integration Tests an
dieser Stelle, wenn wir bei dem Beispiel bleiben, schon länger
dauern, weil alleine zum Beispiel für das Hochfahren
eines Spring Boots Kontext dauert es vielleicht schon mal
so, ja, kann vielleicht auch schon mal einen oder mehrere
Sekunden theoretisch können vergehen, bis überhaupt die
Tests loslaufen. Ne und das ist sozusagen ein
kleiner Unterschied an der Stelle.
Und das ist halt n entscheidender Punkt, weil wenn
ich jetzt zum Beispiel, wie ich gerade meinte, ich teste
einfach, ob das n. Gültiger Endpunkt ist genau der
da reinkommt. Also ich geb ja quasi wie du ja
meintest, das Frontend existiert ja an dieser Stelle nicht,
sondern wir geben die Angaben oder Eingaben vor und ich möchte
jetzt einfach nur testen, was kann ich so reingehen, wann
nimmt der Server das an und wann nicht und ne, also diese
Kombination macht es denn Sinn das als integrations Test zu
machen weil man sich denkt so ja gut das hab ich ja dann auch
abgetestet oder ist es so kostenintensiv, dass man sagt
Weißt du das sind ganz simple Unit Tests?
Doch einfach, dass ich einfach mal vorgebe, was für Calls
kommen da rein und wie. Wie reagiert zum Beispiel der
Controller, der das übernimmt oder wie auch immer die Software
aussieht, macht es da nicht Sinn das einfach auf 100 Test Ebene
zu machen und vielleicht ein paar Tests mehr zu schreiben,
die aber insgesamt wahrscheinlich nur 10 bis 15%
der Zeit brauchen? Also das ist ne gute Frage, weil
es ist natürlich wichtig, dass man seine Tests in also gut
schneidet. Ne, es macht natürlich keinen
Sinn, unglaublich viele. Integration Test zu schreiben,
das zusätzlich noch zu vielen Unit Tests und das ist
eigentlich auch ein bisschen dieser Keep Punkt ne, weil es
durchaus wichtig ist zu sagen ey ich brauch nicht unbedingt eine
Test Pyramide, ich muss jetzt nicht sagen ich hab super viele
Unit Tests, ich habe jetzt weniger Integration Tests aber
auch so einigermaßen viele aber weniger als meine System Test
auf die kommen ja noch und deswegen ist meine Test Pyramide
super und damit passt das ne finde ich ist ein guter Punkt
weil im Endeffekt sollte man sich glaube ich einfach
überlegen. Wie kann ich.
Möglichst schnell Feedback bekommen über Tests ne.
Also wenn du jetzt. Vorhin als Entwickler ne klar.
Genau. Genau darum geht es mir.
Also gut, dass du das nochmal sagst.
Also es ist halt im Endeffekt so, wenn man jetzt sagt, OK.
Ich kann jetzt zum Beispiel auch angenommen, du hast n
Integration Test und 5 Unit Tests und jemand sagt Hey mach
doch mal noch 5 Unit Tests mehr und dann kannst du den
integrations Test streichen. Mal angenommen das würde
funktionieren, dann wäre es ja vielleicht nicht ratsam zu
sagen, aber die Test Pyramide sagt aber wir müssen das so und
so machen weil ich glaube es gibt eine gute Faustregel die
besagt wenn du eine Funktionalität über schnellere
Tests. Abtesten kannst.
Dann nutze diesen Weg. Weißt du ja.
Aber da muss man sich halt wieder Gedanken machen und da
sind wir wieder bei ja, aber darüber muss man nachdenken,
ist. Anstrengend also.
Das ist halt auch genau der Punkt, warum testen auch
wirklich Zeit erfordert und vor allem man sich da auch wirklich
Gedanken machen muss, weil angenommen ich bin jetzt dabei
mein Feature zu entwickeln und bin auf Unit, Ebene und Code
quasi zum Beispiel neue Klasse oder irgendwas wo ich aber weiß
wie die im Verbund arbeiten wird schaff ichs halt mit.
Unit Tests Erweiterung also dass ich mehr Unit Tests jetzt
schreibe für das neue Feature schon so viel, also so eine so
hohe Test Abdeckung der Software oder des Features zu erreichen,
dass ich halt vielleicht noch ein 2 Integration Tests brauche
oder vielleicht gar keinen wie du meintest und das ist diese
Zeit ist halt final gesehen sehr sehr kostbar die am Anfang
reinzustecken quasi in der Überlegung als jedes Mal wenn
ich die Tests laufen lasse pro Durchgang sag ich mal 1015
Sekunden länger zu warten. Ja, weil du ja als Entwickler,
weil das ja in der Regel lokal passiert und jetzt nicht
meinetwegen. Wir hatten auch schon mal drüber
gesprochen, wenn jetzt neue Software Version bereitstellen
will, also ein Deployment macht oder halt diese Continuous
Integration die wir besprochen hatten auf dem Server ist das
wieder ne andere Sache, der hat Zeit.
Ja das ist ja so gesehen eine ausgelagerte Arbeit, da ist es
natürlich auch förderlich schnelles Feedback zu bekommen.
Ob das jetzt integriert wurde oder nicht.
Aber ich finde lokal auf auf der Entwicklungs Umgebung des
eigentlichen Entwicklers muss halt so schnell wie möglich
passieren. Aber jetzt, da muss ich mal ganz
kurz einhaken, weil ich kenne genau die gleiche Situation, die
du geschildert hast im Sinne von.
Die Tests brauchen vielleicht ein bisschen länger, ne, also
da, weil wir ja noch auf die System Tests eingehen, die haben
halt schon relativ lange gedauert, also wenn jetzt zum
Beispiel sagt, was im Test dauert, vielleicht, du hast
vielleicht 20., die dauern halt keine Ahnung.
Mal 10 Minuten auf deine eigene Maschine und deine Maschine ist.
Eventuell würde ich jetzt mal sagen, sogar schneller als kommt
drauf an was man so sag ich mal in der Cloud bucht, aber
meistens kannst du schon hinkriegen, dass deine Maschinen
die du hast schneller sind als die für deine Pipeline,
jedenfalls ist das meine Erfahrung, ne also.
Man kann, man kann also da hab ich genau andere Erfahrungen.
Aber ja, das ist wie du schon sagst, je nachdem was man Cloud
technisch bucht oder halt selbst an Servern ist.
Natürlich ist natürlich irgendwann so ne.
Art von von von Manny ne weil du kannst natürlich mehr bezahlen
für eine schnellere Rechen Power genau, aber was ich zum Beispiel
gemerkt habe ist, dass es kommt drauf an ne angenommen man
arbeitet zu zweit an der Software, dann ist es eigentlich
jetzt nicht so ein großes Problem, aber wenn du jetzt zum
Beispiel sagst du arbeitest in einem Team von 8 Leuten und du
hast jetzt zum Beispiel 4 Pairs weil wir vertreten ja
programming. Und dann möchte jeder seinen
Stand committen. Aber die Pipeline braucht zum
Beispiel für das Testen, für das Bauen und für das Deployment
vielleicht schon ne Stunde, dann ist das einfach zu lange, wenn
sozusagen 4 commits innerhalb von 10 Minuten reinkommen und
jeder gucken will. Passt das jetzt, weißt du also.
Aber würde die Pipeline wirklich ne Stunde brauchen, wenn die
Tests am Anfang schon sagen du, das war nix?
Es kommt drauf an, wann, wann, wann das quasi passiert.
Also wenn du eine Pipeline aufgebaut hast, wo erst die Unit
Tests laufen, dann die Integration Test und dann die
System Tests, also seriell dann und irgendwann Fails im System
Test und. Dann dauert es.
Schon genau dann dauert es und ich hatte mal diesen Fall, dass
quasi im Endeffekt die Pipeline relativ lange gedauert.
Hat. Und dann gab es sogar noch
Tests, die Flaky waren. Das bedeutet, du konntest dich
nicht darauf verlassen, die waren aus unerklärlichen Gründen
manchmal rot und manchmal grün, das ist so das Schlimmste, was
passieren kann, weil dann setzt du halt ne Menge Zeit in den
Sand, ist aber eine andere Geschichte, kommen wir doch mal
kurz das System Test. Zurück, obwohl flaky Tests sehr
spannend. Da müssen wir mal eine besondere
Folge ja zu machen, definitiv, weil damit habe ich auch Horror
Erfahrung, ich bin gespannt. Wie zu hören?
Genau. Aber genau, kommen wir mal zu
den System Tests. Wir haben jetzt gesagt, OK, wir
haben so ein Verbund Test im Prinzip, Wir können Teile der
Software, die schon quasi Module miteinander integrieren Abtesten
und dann gibt es ganz oben bei unserer Pyramide jetzt noch auf
der Spitze die System Tests genau und die System Tests in
dem Sinne sind ja quasi Tests die unser Gesamtsystem abtesten
ja also gehen wir noch mal auf das Beispiel Frontend Backend
ein, Wir haben jetzt n Backend geschrieben die Datenbank, wir
haben da den Verbund abgetestet aber es gibt kein echtes
Frontend. Was jetzt die Calls wirklich
sendet ans Backend, also Calls im Sinne von Anfragen für Daten
oder Speichern von Daten. Ne, was wir ja quasi
thematisiert hatten, wenn ich jetzt den System Test schreibe,
wie sieht dann unser Setting aus?
Genau, also unser Setting ist ja dann so, dass wir im Endeffekt
eigentlich genau das komplette System benutzen.
Ne und jetzt kann man da hingehen und sagen, angenommen
du hast n Freund Backend, dann benutzt du halt genau beide
Komponenten. Als System ne.
Also du sagst zum Beispiel OK, du möchtest jetzt zum Beispiel
den Login testen, also Test den Login mit dem echten Backend
dahinter. Jetzt kann man natürlich noch so
weit gehen und sagen, OK, angenommen, das Backend
kommuniziert sogar noch mit einem anderen System oder das
Frontend kommuniziert noch mit einem anderen Backend, dann ist
natürlich die Frage OK, möchte man sozusagen das auch noch mit
in seinen Systemkontext reinnehmen oder nicht?
Ne, also da hab ich zum. Beispiel System, da wieder eine
Definitionsfrage. Würde ich sagen.
Also ich hab zum Beispiel auch schon die Erfahrung gemacht,
dass man dann halt zum Beispiel sagt, dass Frontend das Backend
beispielsweise weil wir gerade bei diesem Beispiel sind, ist
ein System und alle anderen System Schnittstellen oder
anderen Schnittstellen von diesem von dieser Applikation ne
die aus Front und Backend besteht, die werden sozusagen
mit einem kleinen eigenen, Sage ich mal Fake sozusagen
abgespeist. Genau, weil das spannender
Punkt, da wollte ich jetzt auch mal darauf hinaus.
Was ist bei einem System Test am Ende?
Echt oder halt wirklich noch quasi, wie du jetzt gesagt hast,
gefaked. Das heißt man simuliert quasi
Antworten oder Anfragen und das finde ich ganz spannend, weil
genau dieser Punkt, wenn jetzt irgendein Drittanbieter mit im
System hat, ja ein anderer Service, ein anderes Backend,
dann ist halt die Frage, nimmt man das in seinen Test mit rein
in den System Test oder betrachtet man das als Art Black
Box, die ich ja wiederum simulieren?
Könnte, weil ich ja eh keinen Einfluss darauf habe, wenn da
irgendwas nicht stimmt. Also ich kann ja gar nicht
dieses System ändern. Weißt du was ich meine?
Es gibt da echt n paar Sachen, also das ist finde ich ein super
krasser Trade off bei angenommen du sprichst ein System an und
hast sowas wie ein Raid Limit wo es heißt du darfst jetzt zum
Beispiel aber nur so und so oft gegen meine API irgendwelche
Calls feuern. Was ja nicht selten ist.
Genau. Und dann hast du zum Beispiel
keine Ahnung in einer guten Entwicklung haust du vielleicht
am Tag mehrere Commits raus und dann.
Laufen diese Tests da im Stundentakt und du hast aber
vielleicht nur Rate Limit von keine Ahnung alle 6 Stunden alle
24 Stunden so viel und dann läufst du quasi aus deinem raus.
Was bedeutet das System blockiert deine Anfragen weil
sie sich denkt Oh das ist ja irgendwie ein Angriff und damit
werden die Rest des Tages oder je nachdem wie lange du dann
blockiert bist eben deine Tests nicht mehr laufen und das ist
halt echt ein Trade Off auf der anderen Seite kannst du dich
hinstellen und sagen ey gut. Ich, ich Fake das, was aber dann
auch gleichzeitig wieder bedeutet, dass angenommen
irgendwie ein anderes System, mit dem du Kommunizierst, stellt
seine API um oder seine Schnittstelle zu diesem System
dann. Bekommst du es nicht mit?
Genau, und das ist halt ne super krasse Tradeoff und das ist zum
Beispiel auch eine Sache, die mich auch richtig interessiert,
wie auch andere, also liebe Zuhörerinnen und lieber Zuhörer,
wenn du damit Erfahrungen hast und schon mal mit genau mit
diesem Problem konfrontiert worden bist, würde uns das
wirklich mal sehr stark. Interessieren, wie ihr damit
umgegangen seid, weil das. Ist eine sehr spannende Frage,
finde ich. Auf jeden Fall.
Was ich dann noch so kenne oder was auch ein Punkt ist, du hast
ja nicht nur Rate Limits, dass dir quasi der Zugang verwehrt
wird, weil du einfach zu oft quasi angefragt hast.
Man muss ja auch genauso Service ja, aber es gibt ja auch genauso
Services und das finde ich halt noch spannender.
Dann die einfachen Abo Modell dahinter haben, das heißt ne
Anfrage kostet dich Geld und du hast da ein Konto oder
Credentials die du da quasi womit du dich authentifiziert.
Und zahlst aber pro Anfrage. Und jetzt stell dir vor, deine 4
Entwickler Paare hauen da 5 Comics am Tag raus und da gehen
richtig Anfragen die Geld also dem Unternehmen Geld kosten raus
und das ist halt auch ein Punkt wo man sich sagen muss so wollen
wir das wirklich machen oder sagt man zum Beispiel du Pass
auf der Ebene beim Reinen integrieren wenn wir jetzt
beispielsweise kein neues Release machen, dann haben wir
ein Fake und wenn wir wirklich etwas.
Und Deployen wollen. Dann müssen wir halt gegen den
echten Service gehen und müssen halt in Kauf nehmen, dass uns
das Geld kostet, die Tests ja, was ja, aber hinten raus wieder
Ersparnis ist. Weil wenn das nicht läuft und
depois da sind alle geliefert das aus und das funktioniert
nicht mehr, ist natürlich der Schaden viel größer ne aber das
ist genau das ist ein super spannender Trade auf den Du
genannt hast und da würde mich halt auch extrem interessieren
wie andere das machen also ich glaube cooler Punkt.
Ich glaube, am Ende gibt es so eine Art von Dependence, also
kommt drauf an. Aber die Frage ist jetzt zum
Beispiel also die, die die die interessante Sache an der ganzen
Geschichte ist ja, unter welchen Umständen wurde was gemacht?
Und wenn da jemand schon Erfahrungen hat und sagt, ja,
bei uns war die und die Situation, und die haben wir so
gehandelt, dann kommt jemand anders und sagt, ja, wir haben
aber zum Beispiel die Situation, haben ganz anders gemacht, das
wäre auf jeden Fall spannend, weil ich glaube, es gibt keine
richtige Antwort an der Stelle, aber das wäre halt.
Wichtig wäre halt echt spannend. Genau.
Was mich jetzt noch mal ne kleine Frage an dich.
Kino wenn jetzt von System Test ausgeht.
Macht das Sinn? Alles mit System Tests zu testen
oder was Sie? Was würdest du aus deiner Sicht
sehen? Was macht bei System Test Sinn
zu testen? Von der Testabdeckung her meinst
du? Ja, zum Beispiel.
Genau also. Ja, ja, also das ist halt auch
so ein Trade Off, also in einer auf einer Seite sind System Test
natürlich cool um einfach zu sehen funktioniert die Software
wirklich wie ich mir das denke, also weil ich ja auch nur noch
die Möglichkeit habe von außen quasi den Input zu liefern, wie
beispielsweise auch der Anwender am Ende der Software ne, also
ich kann ja nicht mehr irgendwo mittendrin in meinem System.
Irgendwas sag ich mal faken in dem Sinne.
Das ist ja auch gar nicht mehr der Sinn dahinter, richtig,
deswegen teste ich ja wirklich das gesamte System und kann mir
sicher sein, wenn der Test grün ist und der Test richtig
geschrieben ist, dass es auch so funktioniert, aber sie sind halt
sehr teuer im Sinne von zeitaufwendig, deswegen würde
ich sagen, das ist aber auch nur meine Meinung, lohnt es sich auf
jeden Fall die Wege, also Wege im Sinne von die Eingaben und
Testfälle abzudecken. Die funktionieren müssen, damit
mein meine Funktionalität gewährleistet ist.
Aber beispielsweise Fehler Fälle so ganz seltene Fälle, wo wo man
eigentlich nicht weiß was für ein Verhalten rauskommt, sowas
gibt es ja manchmal einfach, dass man da sagt, Ja OK, pass
auf, das ist nicht mehr der sogenannte Happy Pass, also da
wo alles grün ist, alles toll ist, sondern da wird halt ein
Fehler fliegen und was dann passiert, ja gut, dann ist halt
der Fehler geflogen, so nach dem Motto Weil war sehr
wahrscheinlich, hab ich ja auch. Unteren Ebenen Test Ebenen ja
auch diesen Fehler Fall betrachtet.
Das heißt ich muss den dann nicht mehr noch mal.
Also ich muss nicht jede Kombination Eingabe
Möglichkeiten im System Desktop der Decken genau ist eigentlich
so der Punkt. Das da gehe ich total mit und
ich glaube, das ist auch sollte glaube ich auch mehr als nur
deine, also deine deine persönliche Meinung sein.
Jedenfalls ist das glaube ich auch ne ganz gute Practice, dass
man in diesen sehr sehr zeitintensiven Ressourcen
intensiven Tests. Auch die Pacers abbildet finde
ich voll gut, weil wenn man sich jetzt, und da kommen wir genau
zu diesem Punkt, angenommen, man hat jetzt zum Beispiel 2 System
Tests und der eine testen happy Pass und der andere quasi ein
Pfad wo man n Fehler erzeugen möchte, dann dann kann man sich
an dieser Stelle auch Fragen OK krieg ich es hin mit einem Test
der weniger Ressourcen intensiv ist und also quasi schneller zum
Beispiel läuft Krieg ich mit so einem Test hin genau diesen
Fehler oder dieses Fehlverhalten abzutasten.
Das sozusagen nicht aus Versehen so ein Fehler in die Software
reinrutscht und dann kann man gucken AOK Krieg ich das
vielleicht in die Ebene des der Integrationstests rein, schaff
ich das und wenn ich das. Vielleicht sogar noch.
Genau das wollte ich gerade sagen.
Genau perfekt. Und wenn man das geschafft hat,
genau dann ebene tiefer gucken, also einfach mal diese Challenge
setzen um zu gucken schaffe ich es mit diesem Test, den ich
jetzt gerade habe oder vielleicht schreiben möchte,
kann ich den vielleicht weiter unten ansetzen oder hab ich
vielleicht ein Fehlverhalten was ich hier testen will?
Eigentlich schon in einer unteren Schicht abgetestet.
Das ist, glaube ich wichtig. Und wenn man, wenn die Antwort
ja ist, dann auf jeden Fall unbedingt machen.
Und wenn die Antwort Nein ist, dann ist es auch nicht schlimm,
wenn dann vielleicht in diesem speziellen Fall ist keine Test
Pyramide, sondern Quadrat ist wichtig, an der Stelle ist würde
ich sagen. Das ja, ja.
Ja, also es darf nur kein Test Kreis sein.
Dann nee, ganz genau, nein, aber.
Ja, aber lass uns doch mal. Zum Beispiel bringen.
Ich finde das, dann kann man sich das immer ganz gut
vorstellen, sehr gut, zum Beispiel, weil du vorhin Login
meintest. Wir haben jetzt ein
Gesamtsystem, da gibt es Benutzerkonten, und um auf unser
System zuzugreifen, muss man sich am Anfang einloggen, es
kommt ein Login Screen wie auf keine Ahnung auf Webseiten oder
was weiß ich, es gibt einfach quasi im internen Bereich, gehen
wir mal davon aus und ich muss mich einloggen, dann würde ja
der Happy Path sein, ich geb Credentials rein, also
meinetwegen Benutzername. Passwort und die sind gültig.
Das heißt ich werd weitergeleitet zum Beispiel ich
sehe den internen Bereich, kann das Abtesten so, das wäre also
ein System test ne weil ich das Frontend das Backend a teste,
richtig so macht es dann zum Beispiel Sinn die Richtlinien
für den Benutzernamen Abzutasten oder ein Passwort, sowas wie
muss Großbuchstaben beinhalten, muss ein Sonderzeichen
beinhalten. Genau, und da würde ich halt
sagen, also da könnte also mein. Mein Gedanke an dieser Stelle
ist, dass zum Beispiel, dass man das halt auch in dem in dem Unit
Test abtesten kann. Also angenommen du hast n
Frontend und das Frontend checkt zum Beispiel eine Check, also
muss zum Beispiel eine Fehlermeldung anzeigen, in
diesem Fall, das heißt für eine bestimmte Fehl Eingabe oder weil
zum Beispiel die Richtlinien des Passworts wie Du meintest nicht
eingehalten wurden, wird eine Fehlermeldung angezeigt,
beispielsweise nur ein Hinweis, so das.
Reicht aber sicherheitstechnisch nicht unbedingt aus, weil du
kannst natürlich auch diesen Käufer suchen, direkt ans
Backend zu senden und vielleicht damit das zu umgehen.
Das heißt, du solltest schon irgendwo am besten wie du gerade
meintest, in deiner untersten Logik Einheit für diese Abfrage
n Test haben verschiedene Tests wahrscheinlich um zu gucken OK,
also sozusagen s kommt zurück, sozusagen ist nicht gültig, wenn
kein Großbuchstaben, wenn kein Sonderzeichen dabei ist.
Wenn keine Zahl dabei ist et cetera ne so.
Und da würde ich sagen, das ist zum Beispiel eine Sache, die man
auf jeden Fall in den Unit Tests abtesten kann, ne?
Und da fällt mir noch eine Sache dazu ein.
Also gibt es vielleicht noch einen Test, den man irgendwo auf
Integrationsebene anbringen könnte, beispielsweise wenn wir
jetzt davon ausgehen, dass wir jetzt zum Beispiel irgendwie an
irgendwie n Back and Call machen, ne, und du kannst zum
Beispiel, du hast Sonderzeichen drin, du hast vielleicht zahlen
drin, du hast alle möglichen krassen Sachen drin, aber zum
Beispiel könnten SQL Statement ist wahrscheinlich, als sag ich
jetzt mal. Passwort eventuell sogar
geeignet oder was meinst du? Du ja.
OK, du bist jetzt auf Injection aus, oder?
Quasi. Auf der Heck Schiene unterwegs
genau, ja, natürlich reicht das nicht aus.
Das eine war jetzt, was wir besprochen haben, zum Beispiel
im Frontend Unit Test. Ne, das ist halt deine dein View
darauf schon reagiert und dich quasi gar nicht zum Beispiel auf
Login drücken lässt oder auf Create oder Science was auch
immer wie man es auch nennen möchte, Button den man genauso
musst du natürlich auch das Backend dagegen absichern, ne
dass da richtige Werte. Reinkommen, was aber da auch
wieder auf 100 Test Ebene sein kann.
Aber zum Beispiel, irgendwann bist du an dem Punkt, wo zum
Beispiel, wo du auch wirklich versuchst, Daten in die
Datenbank zu schreiben. Das kannst du über den System.
Test gut, dann bist du ja aber auch wieder wie wir besprochen
haben, in einem Verbund genau und da bist du auf Integrations.
Eben genau deswegen meine ich, du kannst es halt.
Theoretisch kannst es natürlich testen auf Systemebene, aber die
Frage wäre, Krieg ich eine Ebene tiefer und die Ebene tiefer
sollte man hinkriegen, weil man ja theoretisch einfach nur diese
Eingabe, also zum Beispiel Rest Befehl oder?
Ne Rest request quasi an die API senden kann und nur das Backend
benötigt und sagt OK, wenn für so eine Eingabe.
Wenn du zum Beispiel so SQL Injection versucht wird, die
möchte ich gerne abblocken ne und da wird zum Beispiel nichts
in der. Und.
Fertig und nichts in der Datenbank wird verändert,
verändert, verändert. Es wird zum Beispiel Table
gejobbt oder sowas. Ne, das ist wichtig und das
kriegt man United Ebene ja nicht hin, das heißt an dieser Stelle
würde ich jetzt zumindest. Vielleicht hab ich auch gerade
Denkfehler drin, aber würde ich sagen, man kann es auf System
Ebene. Man kann es auf
Integrationsebene testen, also gehe ich auf Integrationsebene,
nicht auf Systemebene. Unit Test Ebene funktioniert
nicht, also ist das auf jeden Fall für mich jetzt gedanklich
ein Test für die Integrationsebene weißt du?
Ja, aber ja gut, also du bist ja natürlich jetzt noch einen
Schritt weitergegangen mit irgendwelchen Eingaben, um das
System zu infiltrieren, sag ich mal.
Gehen wir noch mal auf das Beispiel zurück, dass du einfach
nur die das Format des Passworts nehmen willst, dann kannst du
das im Frontend testen und musst kein System, also du brauchst
kein System Test der dir sagt Ich möchte bitte ne
Fehlermeldung haben beim beim Create Account oder so wenn ich
ein gültiges Passwort eingebe ja so das kannst du halt einfach
kostengünstig. Auch auf unterer Ebene Abtesten.
Sie da haben Sie recht. Ganz genau.
Und ja, genau. Und ich finde, das ist auch so
ein bisschen die Take Home Message, die wir quasi mit der
Folge mitgeben wollen, dass man sich einfach wirklich Gedanken
machen sollte, was ist Pro und Kontra von den einzelnen
testkategorien Arten ne, also was wir jetzt hatten zum
Beispiel Test, Integration, Tests und System Test.
Wofür verwendet man sie, welche vor und Nachteile haben sie?
Und immer versuchen, so weit wie möglich unten in der Pyramide zu
bleiben. Natürlich nicht auf Kosten der
Testabdeckung. Also nicht sagen, gut System
Tests sind böse, die schreibe ich nicht, weil die dauert
lange, aber weil man kann nicht alles mit Unit Tests abdecken,
genauso kann man nicht alles nur mit Unit Tests, integrations
Tests abbilden. Also es gibt einen Grund warum
die Pyramide so aussieht genau aber trotzdem immer versuchen
mal lieber zweimal darüber nachdenken schaff ich es einfach
immer auf unterstem Level, also so weit wie möglich unten zu
bleiben. Ja, genau.
Und im Normalfall ergibt sich ja auch so eine Art von einer
Pyramide. Es bringt aber zum Beispiel
nichts, wenn man jetzt zum Beispiel sagt, Mal angenommen,
ne, wirklich mal angenommen, man hat genauso viele System Tests,
Integration, Tests und genauso viel Integration T Unit Tests
was ich meinte und dann bringt es nichts zu sagen A der Theorie
nach brauche ich aber eine Pyramide, deswegen schreibe ich
jetzt noch mehr noch mehr Unit Tests und so, dass man quasi am
Ende einfach nur noch Test Redundanz drin hat, die
eigentlich gar nichts bringt, außer dass die Tests länger
dauern. Das ist halt der Punkt.
Deswegen wirklich drüber nachdenken und meistens hat man
halt ne Test Pyramide schon automatisch irgendwie, wenn man
auch gesagt OK wir versuchen mal das Ganze immer sobald wie
möglich unten den Test anzusiedeln, aber wenn jetzt
irgendjemand sagt ja bei uns ist es aber nicht so, dann würde ich
mich jetzt auch nicht hinstellen und sagen dann ist es auf jeden
Fall falsch so, das ist halt so ein bisschen der Punkt.
Genau wie war so schön gesagt, haben Independence.
Also es ist natürlich auch immer System abhängig, also was ich.
Entwickle ich gerade, ja. Oder wieviel Schnittstellen habe
ich überhaupt innerhalb meines Systems?
Wieviel Komponenten, wenn ich jetzt einfach ein eigenständiges
Programm habe, jetzt zum Beispiel nicht noch irgendeinen
Server angesprochen wird oder eine Datenbank dranhängen, dann
sieht das wieder ganz anders aus, wenn ich zum Beispiel auch
keine Oberfläche hab oder na ja gut, ich würde sagen, wir haben
das ausreichend versprochen und. Das war auf jeden Fall.
Ich würde sagen, lass uns. Ja, das war ne Menge.
Das war ne Menge Tech talk, ich hoffe.
Heute war es mal ein bisschen Deep Dive.
Ich hoffe, liebe Zuhörer, liebe Zuhörer.
Es hat dir trotzdem gefallen und du hattest richtig motiviert,
jetzt deine Software zu testen, falls es Fragen geben sollte.
Auf jeden Fall bei uns melden, wir quatschen wirklich sehr
gerne über dieses Thema, beispielsweise über unsere Email
Adresse, die findest du in den Show Notes.
Ja, ansonsten würde ich sagen Fabi.
Das letzte Wort gehört dir, Band die Folge.
Peace, du bist raus, oder was? Ich bin.
Raus ja. Also wir würden uns auf jeden
Fall super freuen, wenn du den Podcast n bisschen weiter
empfiehlst, deinen Freunden und Freundinnen und natürlich auch,
wenn du einfach mal bei uns in der nächsten Twitch bei unserem
nächsten Twitch Stream dabei bist, würden wir uns auch super
freuen. Ja und in diesem Sinne wünsche
ich euch noch einen wunderschönen Tag und ich hoffe
wir hören uns beim nächsten Mal und.
Ja, in diesem Sinne. Deine Coding war dies.
Gemeinsam besser.