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.