Moin, zu einer neuen Folge einfach komplex. Wir haben Grad überlegt welche Nummer es ist, aber 103 wahrscheinlich. Hoffentlich 103 ja. Wir sind wieder zu zweit da, also der Burkhard und ich Gerrit. Ja Moin. Ja Moin, die hat sich schon gehört auf der Tonspur. Ja, richtig. Und wir wollen heute mal das Thema Software Testing besprechen, und zwar die groben Züge, was Testing eigentlich bedeutet, weil wir haben
gemerkt. Schon so viele Folgen gemacht und noch nie so explizit über Tests gesprochen, obwohl es ja eigentlich total, ja naheliegend auf der Hand liegt. Also weil es ja immer dazu gehört, nehm ich an ne beim Entwickeln von Software auch, oder? Muss ja, mir hat mal irgendjemand gesagt, eine eine Software die keine entsprechenden Tests hat ist nicht ist keine Software die die du in Markt schicken kannst. Das ist Spielwiese für dich selbst.
Muss immer Tests dabei sein, ja sonst weißt du nicht was los ist. Gehört also in einem Atemzug dazu. Ja, Software und deren Test. Warum denn eigentlich? Warum testen wir Software Burkhard? Alles klar. Machen wir mal den Einstieg in die Folge.
Ich hab ich hab gerade schon angeteasert, dass ich ne ne schöne Geschichte, ich weiß nicht ob er sie kennt, oft hab ich ja Geschichten auch schon 2 oder 3 mal erzählt im Podcast aber nicht das weiß ich, also erzähl ich die so kurz von den Anfängen meiner Zeit, wo ich noch nicht diesen Mann gehört hatte, der gesagt hatte du musst immer Tests schreiben damit du gute Software hast. Also hab ich gedacht ich hab gute Software geschrieben aber keine Tests damals.
Meiner allerersten Firma, die ich noch während ich Student war schon aufgebaut hatte. Und was hatten wir gemacht, wir hatten es war die Zeit vom Lamp Stack, das sagt vielleicht n Paar Leuten Linux Apache My Sequel PHP, DAS ist der für das SP, das war damals halt so der Technologie Stack und wir hatten auch ne kleine Webanwendung gemacht zum zur Teilnehmerregistrierung n Datenbankpack wie sich das so gehört. Und und der der Kunde hatte sich
ein neues Feature gewünscht. Wir hatten so n Hotelbuchungsmodul mit drin für Wissenschaftskongresse und Verhalten ist auch drinne und da war das aber immer ganz klar eine Nase in ein Zimmer, wir haben es quasi so Vorgebucht und dann haben wir das quasi als fertige Liste dem Hotel weitergeleitet, da wir da kontingent, Boni und so weiter kriegen konnten und sofort ja aber jetzt wollte jetzt nun dieser Veranstalter die Möglichkeit haben.
Das Doppelbettzimmer, die es einfach so gab in einem Hotel besucht werden können auch von Teilnehmern quasi, die sich eigentlich nicht kennen, die dann quasi ne kleine schmale Geldbörse haben und denen sagt OK ist egal, ich bin halt junger Wissenschaftler, ich schlaf halt im Doppelbettzimmer. Ja genau und dann gab es diese sogenannte Random Sleeper Option, so haben wir es genannt, Random Sleeper, weil ist mir egal, ich Schlaf doppelbettzimmer wer da mit drin
ist. Wurscht, ja das sollte aber nur für die Leute gelten, die das Halt auch ankreuzen und wollen ne und lange Geschichte kurz. Irgendwer hat was verbrochen im Code. Also meine Wenigkeit.
Ich hab damals schon für den Code zuständig war und ja, die Teilnehmerregistrierung liefen los und die Datenbank füllte sich und dann bekamen wir e Mails eine die werd ich nie vergessen von irgendeinem französischen Professor der meinte so wieso hab ich jetzt ne Anfrage von einer Studentin die auf mir mir auf meinem Zimmer schlafen will ne dann kam schon so das Erste die erste Schweißperle auf die Stirn und dachte OK das kann auch nicht so sein.
Ja, da war halt n fetter Bug in der Zuordnung und es stellte sich heraus, dass halt gar nichts funktioniert hatte mit den Random sleepern und alle irgendwie wild durcheinander
Hotelzimmer gebucht bekamen. Das war dann auch so und so lief auch die Konferenz und so wurde die auch eröffnet, so nach dem Motto Wir haben hier 2 coole Jungs, die haben ne coole Software gemacht, ja die hat aber einen blöden Bug so und deswegen ist es alles n bisschen wild durcheinander, aber vielleicht ist es ja besonders schön ja es war ne besonders interessante Konferenz, ja. Es zeigt aber, dass es weder für den Kunden cool ist, noch für die Firma.
Also wir. Ich hab dann nachher beim ich hab versucht es noch live zu fixen, wir haben ja damals noch die Datenbanken ausgedruckt und die Assoziation versucht zu finden und so weiter ja, aber da war es dann halt schon zu spät.
Ja als kleiner Anekdote für einen nicht vorhandenen Test, der das vielleicht vorher schon gleich weggebügelt hätte, ja, aber man hat ja in die Zeit, man muss es schnell ins Feld bringen und man hat da gedacht, das passt schon und dann passiert sowas ja also mal als worst case oder nein, worst case vielleicht noch nicht, aber schon mal Bad Case. Weshalb wir besser Tests haben auf unsere Software.
Wir haben besser Tests, damit nicht du mit irgendwelchen Leuten Kinder mäßig n Hotelzimmer gebucht wirst. Genau, genau. Ja, das ist ne. Geschichte ich kenn die Geschichte auf jeden Fall schon, ich würde sagen, dreimal kommt hin, hab ich die gehört. Ja, ich. Würde fast behaupten, sie kamen auch schon beim Podcast. Vor Nein glaub ich nicht. Ja, glaubst du nicht? OK, ja. Gut. Vielleicht haben wir ja aufmerksame Hörer und Hörerinnen, die das mal irgendwie ja uns Bescheid sagen können.
Neulich gab es n Kommentar irgendwo, wo jemand sagte, Ich bin gerade bei Folge 43 und hier wurde gerade dies und jenes besprochen, was ihr jetzt auch noch mal aufgegriffen habt und so, also man verschwimmt, aber egal, die Geschichte ist gut, OK, was hättet ihr denn eigentlich tun können um das zu vermeiden? Ja, man hätte, man hätte wohl Test schreiben müssen, man also man hätte 2 Sachen machen können, man hätte es entsprechend besser testen können selber. Führt mich dazu, wie man
überhaupt Software testet. Also es gibt ja das sogenannte QAQ and a. Ich weiß nicht wie man sagt, also Quality Asurance was einfach n Prozess ist, wo ich mir die Zeit nehme, das was ich an neuen Features habe oder das was ich gefixt habe auch einfach noch mal anzuschauen, durchzugehen im Testszenario aber so natürlich an der. An einem echten Produktionssystem so nah wie möglich dran. Da ist ja immer die Idee bei Tests ja und ist einfach noch mal in Ruhe durchzuspielen.
Ja und das Q und A ist oft manueller Prozess, der ist mehr darauf, dass also drauf gezogen QA glaube ich QA also ja genau. QA wäre Equestion ernsthaft, ja. Stimmt ja richtig, deswegen sag ich Q und a. Das ist richtig. QA ja quality of Schwules also da geht es darum irgendwie das ganze Bild noch mal anzuschauen, zu schauen, wenn ich das Durchklicke ist das so wie es sein soll.
Da geht es auch n bisschen mehr um die UX, um die Bedienbarkeit, da ist das so. Intuitiv erscheinen die richtigen Boxen an der richtigen Zeit wird der User das verstehen, was er da machen soll.
Jetzt ja, da hat man mal so n bisschen nen anderen Blickpunkt als und das ist die zweite, der zweite Seite der Medaille die ich hab beim Testen sind die automatisierten Tests die ich quasi hinschreibe um einfach die Richtigkeit der Funktion die ich implementiere und der Zusammenhänge der Prozess der inneren softwareprozesse sag ich mal zu testen. Die laufen also, die schreib ich quasi auf.
Ich schreibe quasi noch mal ne Software um meine Software zu bestätigen, dass sie das tut, was sie tun soll.
Diese Tests n bisschen anders vom Charakter, weil die sind immer binär, also die entweder failen die oder passen die ja, da schreib ich halt ne ganze Menge von den Dingern auf und dann dann dann müssen die eigentlich alle Pass Pass Pass Pass Pass durchgehen ne während so NQA hat halt auch irgendwie, hat halt nicht irgendwie das hat bestanden oder nicht bestanden, sondern das ist quasi so n Gesamtbild ja nach dem Motto OK das passt so passt es. So können wir es erstmal in den
Markt schicken. Ja, könnte man auch da ungefähr so sagen bei QA, dass das ein bisschen anders, als du gerade gesagt hast, eher um Prävention geht. Also du machst Code Reviews oder machst so Sachen wie per Programming oder sowas, setzt klare Requirements um Fehler grundsätzlich, also ja präventiv also vorher zu vermeiden, während testing. Du hast ja gesagt, du schreibst eigentlich noch mal Software um deine eigentliche Software automatisiert durchspielen zu lassen.
Darum geht dann die Fehler oder die Bugs zu finden, die dann da drinne sind. Ja, das ist richtig. Genau. Wenn ich das anders gesagt hab, dann da tut es mir leid. Nee, es ist natürlich QQA passiert, im besten Falle. Bevor ich also präventiv, bevor ich das Produkt Release zum Kunden, ja genau das ist richtig und das Testing passiert aber im Prinzip auch davor. Ja ich, also ich schreibe, aber ich schreibe.
Aber noch mal, ich mein damit du versuchst gar nicht erst Fehler in den Code reinzubauen, der dann getestet werden muss. Quasi. Und dann kommt das Testing und der Release kommt dann erst später. Ja, also beides vom Release logischerweise eigentlich, oder?
Ja, ja, ja der der QA Prozess, den kannst du auch weiterlegen ne das der beinhaltet ja auch schon die Designphase und und und so weiter und sofort ja also auch das Aufschreiben von Requirements und so, das ist ja n sehr weiter Begriff, wenn ich den ordentlich mache vermeide ich quasi auch Fehler, indem ich schon vorher Edge Cases besprochen habe, die ich dann entsprechend behandel, sodass der Code schon in der ersten Fassung. Sauberer geschrieben wird.
Genau das ist richtig. Ja, das stimmt ja, ich würd sagen, aber wir befassen uns im im Verlauf der Folge jetzt nicht so viel mit dem QA Prozess, weil der ja, also der ist ja sozusagen n bisschen manueller und auch sehr vielleicht individuell, je nachdem was ich gerade für n Produkt unter der Hand hab und so weiter und gucken eher so n bisschen darauf wie wie was gibt es für Mittel und Wege wie ich normalerweise
Software automatisiert teste. Ja und ich sag es auch gleich vorweg, das ist also Testing ist ja auch so. So n bisschen wie Religion find ich. Also es gibt irgendwie lehrbuchmeinung, wo ich aber auch nicht genau weiß wo die herkommen.
Hat halt irgendjemand mal aufgeschrieben, das Internet ist voll von Meinung was man wo wie macht und es gibt auch diese Pyramide, da kommen wir gleich noch drauf, ich sag es gleich vorweg, was ich heute sage ist das was ich meine, wie man erfolgreich Tests schreibt nach 20 Jahren irgendwie im im im Softwaregeschäft sag ich mal da gibt es bestimmt auch ne zweite
Meinung zu also. Man kann das sich jetzt anhören und was davon mitnehmen und und wem das nicht passt, so der der, der soll das gerne anders machen oder auch n Kommentar schreiben, aber ich glaube da gibt es halt um das vorweg zu sagen, nicht den einen richtigen grünen Weg, der für alle so klappt, sondern jeder muss sich glaub ich da so n bisschen was finden und ist irgendwie am Ende auch n bisschen was subjektives.
Hauptergebnis ist aber wenn ich ne gute testabdeckung hab und gut schlafen kann, dann hab ich irgendwas richtig gemacht ja und wenn mein Produkt stabil im Markt steht das das ist was am Ende zählt wie ich das dann exakt erreiche weil. Welchem Verhältnis oder welchen Cover regist oder welchen Tools, sei mal dahingestellt. Das will ich mal als Disclaimer vorweggeben ne. Dann, wie strukturieren wir das
denn? Also was ich ja immer wieder höre, ist von Unit Tests und Integration, Tests und so weiter und sofort willst du dir erst mal alle so n bisschen einordnen was es da so gibt. Ja, das können wir machen, also die, die Tests so wie Software halt auch ist. Ne ich hab ich hab atomare Bestandteile von der Software also wenn ich ganz ganz unten ins Detail gucke, dann hab ich irgendwo Funktionen. Dann gliedere ich Funktionen in
Klassen auf. Die Klassen werden dann zu Instanzen, die Instanzen laufen auf Prozessen und wenn ich ja dann in die moderne Webwelt gucke, wo wir auch immer gerne diskutieren und wo, nachdem sich auch diese Folge n bisschen richten wird, dann habe ich halt diese Prozesse in Microservices, also zum Beispiel in Containern, oder habe ich mehrere Container, die mit den Prozessen von den Klassen und den Funktionen arbeiten und so weiter und man merkt schon, es baut sich halt
Level of Level of Level auf, ja, und ich hab irgendwie ne Komplexität ganz unten atomare Komplexität.
Die ständig höher steigt. Ja, bis ich irgendwo ganz oben bin und ganz oben ist in der Webwelt tatsächlich irgendwo meistens ne UIN Frontend, wo zum Beispiel nen nen User irgendwas klickt und dieser eine Klick der führt zu wieso ne Art Gewittersturm kann man sich es vorstellen Klitze runter durch die ganzen Levels, manchmal ist es nicht nur ein Flow der passiert, sondern es werden viele Sachen gleichzeitig evaluiert, viele verschiedene Klassen und Funktionen werden
dann durch diesen einen Klick getriggert, zum Beispiel Authentifizierung und so. Haben die Folge, dass irgendwo in der Datenbank vielleicht irgendwas eingetragen wird. Irgendwie kommt das wieder hoch und dann hat man im Browser noch n Cache, dass der gemerkt wird fürs nächste Mal und und und. Und ja so und das ist halt ne komplexeste Ebene.
Ja und so wie der wie der Code halt auf verschiedenen Abstraktionsleveln strukturiert ist, strukturiere ich eigentlich auch meine Tests damit ja und man man nennt das so im ich, ich glaube so im Lehrbuch Level irgendwie testpyramide und meint damit im Prinzip die Abstraktionspyramide ja und wenn ich in die atomarsten Details reingucke also ganz. Ja, ist jetzt unten oder oben in der Pyramide. Ich weiß es gar nicht. Gerrit, Ja, das hab ich mir gar nicht angeguckt, aber auf jeden Fall.
Wo es eher viele von gibt unten. Pyramide die weitere Pyramide. Ja genau stimmt das sind dann die Unit Tests. Lehrmeinung ist Unit, Tests kann man viele von haben sind auch einfach zu schreiben, sind halt einfach gekapselt ja weil ich halt atomare Bauteile quasi checke. Ja ich checke halt die Funktion tut sie das was sie soll? Ja kommt da wenn ich das wenn ich das und das Argument da rausgebe also im einfachsten Fall ja ich hab ne
additionsfunktion. At ja, wenn ich 1 und 3 da oben reingebe, dann soll da halt 4 rauskommen. Ja gut, das ist jetzt n bisschen Silly, aber so ungefähr wird dann halt pro Funktion oder pro Klasse eine Einheit abgetestet ja. Also in deinem Unit Test steht irgendwie drinne, wenn man diese Inputs reingibt in die Funktion, dann ist dieser Output zu erwarten und wenn der durchläuft und da n Output rauskommt, der nicht dem erwartbaren Ergebnis entspricht, dann ist der Gefailed oder?
Genau so sind im Prinzip eigentlich alle Tests aufgebaut, weil von der ab, von der Ebene her unabhängig.
Ich habe, das sag ich gleich noch mal gleich vorweg, man man strukturiert Tests oft in in, ja in in so 2 Kategorien würd ich sagen, man sagt man gibt so ne Überschrift, was teste ich jetzt gerade je nach Framework heißt nicht unterschiedlich, also zum Beispiel im im im Jazzframework was 1 der bekanntesten ist von der Webwelt dann sagt man macht man so n discribe also was was kommt jetzt und das Discribe kann auch geschachtelt sein und dann sag ich. Wenn ich das und das mache, dann
erwarte ich das und das. Ja, genau so ist es ja und deswegen auch diese binäre Eigenschaft, da muss dann halt 1 zu 0 rauskommen. Entweder ist das so oder auch nicht, ja genau, ja genau und unten, also die die untersten Tests auf der niedrigsten Abstraktionsebene, die nennt man halt die Unit Tests, weil die halt abgeschlossene Units testen und auf dem nächsten Level gibt es dann das Wort Integration Tests, das hat sich auch so etabliert, die Integration Tests. Die nehmen dann quasi schon
etwas mehr mit. Die testen halt nicht nur ne Funktion, die testen dann quasi. Also ich ich definiere Integration Tests immer bei Microservices so dass ich zum Beispiel nen anderen Microservice haben muss um den
nächsten zu testen. Ja ich ich will zum Beispiel testen, kann ich den User einloggen ja und das kann ich eigentlich nur seriös testen wenn ich wenn meine Datenbank auch mitläuft ja weil ich irgendwie nen Eintrag an die Datenbank mache und dann les ich das aus und dann ist das irgendwie das Zeichen dafür, dass der eingeloggt ist oder irgendwie was ja. Also hab ich in der an der Stelle n Abstraktionslevel mehr, nämlich nen anderen Microservice
den ich einfach benutzen muss. Ja und dann nennt sich das Integration Test. Ja und vielleicht und aber das sagt er noch nicht, vielleicht sagt dieser Integration Test noch ist ist das noch nicht die die finale Finale also ich hab nicht das ganze System unterm Hintern ja ich hab aber nur genau die Komponenten unterm Hintern beim Integration Test die ich jetzt brauche um um meine eine Bedingung die ich
jetzt hier geschrieben habe. Zu testen ja das auch die Kunst bei den Tests, dass ich versuche vom ich versuch nur das minimal Notwendige mit einzubringen, weil damit es halt quasi reproduzierbar reliable bleibt. Ja je komplexer ich die Tests mache und desto anfälliger werden die natürlich zu allen möglichen Schräubchen die ich drehe im Produkt.
Ja, deswegen nennt man es auch Testpyramide, deswegen sagt man im Schnitt und das ist wahrscheinlich richtig, dass man wo ich viele Unit Tests haben kann, weil wenn die erst mal da sind, dann ändern die sich nicht, ja.
Integration Tests, da muss ich dann schon aufpassen, dann weil die haben, da hab ich schon Beziehungen zwischen verschiedenen Codekomponenten und wenn ich die Anfasse, dann muss ich schon wieder anfangen, meine Tests anzufassen und zu schreiben, entsprechend und die höchste Ausbaustufe, da gibt es bestimmt im Prinzip noch Zwischenstufen, aber lässt man erst mal weg in der Testpyramide es sind die End to End Tests, wie die so schön heißen ne Ende zu Ende und die laufen quasi
hier ist es tatsächlich so, dass ich irgendwie simuliere wie ein User klicken würde, also auf dem obersten Level. Und dann ist meine Erwartung, jetzt erscheint ein Pop Up oder Irgendsowas. Ja, wäre zum Beispiel der Test und dann muss ich halt auch testen, dass in der UI dann der
Pop up erscheint. Ja, die sind irgendwie cool, weil die dann, weil das so die Tests sind, die mir die volle Bestätigung geben, dass das wirklich funktioniert, also wenn wenn der Test gelaufen ist, dann weiß ich, das geht nicht schief, die haben aber den Nachteil, dass sie halt boah, dass sie halt extrem schwer zu warten sind, ja, weil in dem Moment wo ich da. So, man kann sich jetzt schon vorstellen, dass es gar nicht so einfach ist. Ja, wie sieht denn das Pop up aus?
Ja, die Bedingung da, da kommt jetzt ein Pop up hoch zum Beispiel ja ja, aber was denn für n Pop up an welcher Stelle, welche Farbe wird schon schwieriger so ja und wenn ich jetzt irgendwo rumschraube in meinem Code und oder zum Beispiel wird irgendwas langsamer oder irgendsowas wann kommt das hoch nach dem Klick und so weiter die werden halt sehr schnell sehr schwierig wartbar diese Ende to Ende Tests ja. Also es ist auch schwer zu
beschreiben, was genau das zu erwartende Ergebnis ist oder so oder wann du dann eigentlich davon abweist. Es ist halt schwieriger, automatisch zu testen. Ich glaube, das ist erstmal das große Problem, weil vor allen Dingen, wenn du halt nen, wenn du halt ne UI hast ja immer wenn du ne funktionsrückgabe hast. Das ist ja sehr einfach sag ich
mal. Aber wenn du ne UI hast, dann sprechen wir ja von gemalten Pixeln und so weiter stimmt auch nicht, so funktionieren die nicht, die gucken quasi auf den Dom, also aber dann brauchst du auch wieder IDS und Elemente die dann auftauchen in deinem. Auf deiner Seite sag ich mal die du identifizieren kannst, um überhaupt das Ergebnis zu
verifizieren. Ja, das ist da können wir nachher noch mal n bisschen drauf rumkauen, da gibt es auch natürlich überall Tools, für die dir das Leben erleichtern und die werden auch immer besser, genau, aber die also sagen wir mal so ich ich finde immer mit mit höherer Abstraktionslevel decken die Tests natürlich mehr ab, also während du kannst irgendwie. Du kannst irgendwie 100000 Unit Tests haben die geil funktionieren und hast aber trotzdem ne schrottige Software wo wo?
Wo du irgendwas, ich sag mal n Port hast du falsch konfigurierten 2 Microservices telefonieren nicht miteinander, funktioniert gar nichts ja und hast aber alle Unit Tests auf grün ja auf der anderen Seite ist halt aber das Dilemma, dass wenn du End to End Test schreibst sind da so aufwendig hinzuschreiben, dass die nicht flakey sind wie man sagt, dass die auch immer seriös reproduzierbar genau das gleiche Abtesten, dass dass man da abwägen muss und das ist jetzt
das ist, das ist auch was Wichtiges beim Testen, dass du nicht einfach so viel mehr Test schreibst als eigentliches Produkt. Ja, wir haben ja auch, also wir machen ja nicht Software aus Spaß, also gibt es auch ne und zu wissenschaftlichen Zwecken so aber ganz viele Leute machen halt Software um um irgendwie wirtschaftliches Produkt rauszuhauen und ich muss halt gucken, dass meine meine Kapazitäten Tests zu schreiben nicht die Wirtschaftlichkeit
übersteigen, die insgesamt mein Produkt mir erwirtschaftet, ja. Da muss ich dran denken an unser Interview mit dem. Mit dem Heinrich von von Zalando, der Observability hier uns mal näher gebracht hat im Podcast, der hat ja gesagt und und so ähnlich ist es ja bei uns auch.
Also du kannst ja gar nicht alles End to end testen, es gibt ja so also jetzt bei Zalando natürlich noch mal was weiß ich, viel, viel, viel mehr potenzielle Fehlerquellen und Wege, die Nutzer einschlagen kann, als jetzt in unserer vergleichsweise kleinen Software, obwohl unsere ja auch schon richtig ist. Dass man manchmal das eben dann auch erst hinnimmt, dass dem Kunden das passiert oder dem Nutzer und dann. Man agiert ne, dass etwas nicht funktioniert hat oder schmaler Grat.
Voll ja. Also es ist n schmaler Grat und du willst eigentlich das vermeiden, dass der Kunde, aber das ist manchmal nicht vermeidbar, weil du hast ne Mathematik hast. Das ist NNP komplettes Problem, also je nachdem wie viele Features du hast. Du hast ja die Kombinatorik aus allen Features, ja. Und kannst nicht jeden Edge Case einfach vollständig abtesten. Das geht nicht. Ja, also mal allein davon, selbst wenn wenn das irgendwie komplett automatisiert
hingeschrieben würde. Die Laufzeit die das irgendwie bräuchte um alles durchzuspielen und so genau, also es ist n schmaler Grat und die Kunst ist und ich glaube das ist so n bisschen echt ne Kunst. Ja, die Kunst ist die Tests und das QA quasi was damit einhergeht so zu designen, dass sie halt zu dem Produkt passen und diesen schmalen Grat so
erfüllen. Das ja vielleicht noch mal was weiß ich n Promille der Kunde irgendwie beim speziellen Edgecase halt baden geht, dann dann kommt Support vom Kunden und möglichst schnelles, fixen und so weiter und dass du aber trotzdem irgendwie ne zügige Weiterentwicklung hast, dass du dich nicht selber ausbremst durch deinen ganzen ganzen Testkampf. Du willst ja auch und andere Software ist ja auch, du willst ja auch schnell mal n neues
Feature reinbringen und so weiter willst es fortentwickeln und so weiter auf Kunden Features reagieren auf Requests und so weiter ja. Das heißt, so n bisschen abschließend, die Pyramide noch mal aufzurollen. Du versuchst möglichst viele Unit Tests eigentlich zu haben, die die ganzen kleinen Blöcke machen, nee, auch nicht.
Ich hab jetzt das Lehrbuch neulich gesagt, das ist die Testing Pyramide. Ich halte von jetzt kommt das Objektive, das subjektive Entschuldigung ich halte von Unit Tests gar nichts, ich schreib fast gar keine Unit Tests ja lass ich weg die Ebene weil die mir also weißt du echt so Funktion auf Funktionslevel also aus 2 Gründen erstens sagt es wie gerade gesagt hat nicht so viel aus über die gesamt.
Funktionalität deiner Software ich glaube Web Software heutzutage ist deswegen komplex und geht kaputt, weil wir auf einem höheren Level Probleme haben. Die haben nämlich verteilte Anwendung.
Wir haben Kommunikation von ganz vielen verteilten Komponenten, da geht es meistens baden, da fängt es sich an zu lohnen, zu testen und das ist halt das Level von Integration Tests und das sind meine Lieblingstests ich teste ganz ganz viel, ich hab ganz ganz viele Integration Tests und versuche halt immer aus dem großen Microservice Bush irgendwie die Kleinen die kleinen Sachen Rauszuschneiden. Die ich testen kann.
Ja, und ich teste auch und das hat auch mit Mocking zu tun, ne ich versuche auch wenig zu mocken ja was ist mocken?
Nehmen wir noch mal die Datenbank ich kann ich kann sagen ich hab ne Funktion die braucht dann n datenbankeintrag jetzt kann ich sagen OK die Datenbank hab ich jetzt hier nicht in meinem Test weil ich will ihn ganz einfach halten ich tue so als hätte ich ne Datenbank und geb halt irgendwie Werte zurück wie sie ne Datenbank zurückgeben würde dann hab ich die Datenbank gemockt ja.
Oder ich sag halt nein, ich mach daraus n Integration Test, weil ich hab ja die Datenbank, ich geb mir die Mühe, dass ich n Integration test gut schreibe und teste den gleich mit der echten Datenbank. Ja und siehe dann halt Oh verdammt ja wenn ich jetzt im auf einmal ne My Secret Datenbank reinnehme und nicht ne postquest Datenbank, dann geht auf einmal dieser Secret Call irgendwie nicht weil weil die unterschiedlich sind im Detail. Ja auf einmal fällt mir das auf,
ja und deswegen sag ich ja klar kannst du Unit Test schreiben, aber kannst du auch lassen also schreib mal lieber ordentliche
Integration Test und hab auch. N ordentliches Portfolio an End to End Tests wenigstens für die Storylines durch deine UI, die halt die sind, die die meisten die am meisten gegangen wird und noch mal auf diesen Bereich ne, also man weiß ja seine Good Cases und man weiß ja in seiner UIUX eigentlich was häufig passieren sollte und diese Pfade sollte ich halt auch vielleicht in End to End Tests mit mit einstecken, dass die die Pfade die immer abgetreten werden von den Usern halt auch wirklich
funktional sind, ja dass die mit Einnehmen in den Tests ja. Das meine Meinung. Zu der zu der Testpyramide ja, ich würd die einfach n bisschen höher anfangen lassen, dann sprechen wir mehr über sowas wie n Diamanten so der ist unten schmal und dann kommen viele viele Integrationtests und nach oben ist es wieder schmaler so. Sieht es dann nur so ein Produkt aus? Ja, tatsächlich, genau, wir haben keine, wir haben eine Test Diamanten genau richtig, ja ja,
ich hab. Gerade gesehen, dass das in der Recherche oder hab ich vorher gesehen, dass dieser Begriff von irgendeinem Cant Sea dots geprägt wurde? Du nennst das die Testing Trophy, ja das das geht auch in die Richtung, also n bisschen moderner gedacht. Es kommt auch drauf an, was deine Units sind.
Ne also ist auch kein Geheimnis, wir nutzen ja auch schon oft gesagt viel Open Source und wenn jetzt zum Beispiel deine Units sind schon gut getesteten Open Source, also die Open Source Produkte selber die irgendwas machen, die haben ja auch ihre Unit Tests, das muss ich auch mal sehen ne und wenn du die jetzt wenn du jetzt nur n kleinen API wenn du die nur und das ist ganz oft Inhalt von Software ist ja nicht andauernd alles neu zu erfinden sondern Sachen zu nutzen die da sind, ja
und wenn ich jetzt einfach ne Sache nutze die da ist und schreib dann nur ne ganz dünne. N Schimmel rum ne ne nutzungs das ist eigentlich nur nutzungscode. Ja dann muss ich ja in meinen Unit Tests nicht noch mal das testen was der Hersteller von der Open Source Produkt schon
für mich getestet hat. Ja das ist ja Wahnsinn ne das würde man weglassen an der Stelle, deswegen macht auch der ganze Unit Test an der Stelle dann keinen Sinn für mich und ich nehm das Gleiche höher an ne Stufe und hole mir n Integration Test ab Integration Tests hat man früher nicht so gerne gemacht weil die Halt auch schon mega aufwendig sind weil ich muss halt andere Komponenten hochfahren und runterfahren. Und das Schlimmste bei Integration Tests ist, das
vergisst man immer. Ich muss Tests reproduzierbar hinschreiben, ich will ja nicht von den Tests noch mal Tests machen, ich muss halt wissen, dass die Tests halt immer gleich laufen, ne mit gleicher Code, gleiches Testergebnis ja so und das ist wird aber schon gar nicht mehr so einfach wenn ich lebende Komponenten habe und früher war das n Problem, heute ist es aber kein Problem mehr weil ich kann, das ist wichtig, ich muss den gleichen State, den Clean Slate wie man so schön
sagt ne also ich muss den den gleichen Start. Status für den Test wenn der Losläuft erreichen und ich muss, wenn ich zum Beispiel viele Tests laufen lasse, gegen ne Datenbank zum Beispiel, dann muss ich vielleicht die Datenbank immer wieder cleanen, sodass sie immer wieder frisch ist, sodass dass sich die Tests nicht gegenseitig beeinflussen und so weiter sonst sonst komm ich in Teufelsküchen.
Ja, das ist zum Beispiel ne, das ist zum Beispiel auch was sag ich jetzt mal geradezu, wenn man Tests schreibt, dann hat man so Lifecycle Hooks in den Tests, also man kann sagen, bevor vor allen diesen Tests machst du das und nach allen diesen Tests machst du das, man hat so. Zu beginnen und aufräumen, Routinen ne. Man könnte zum Beispiel vor den Tests sieh zu, dass du Datenbank hast und so weiter und nach den Tests räumen das alles wieder ab.
Ja oft wird richtig viel auf und abgeräumt, das ist eigentlich kompliziert, aber mit Docker überhaupt nicht mehr. Ja hier hier mein Killer Rezept für Integration Test und das kann man, wir haben quasi so n ganz ganz kleines Framework für die Integration Tests basiert auf Docker Compose.
Hatten wir auch schon mal ne Folge, da kann man ja seine Datenbank und alle seine Microservices, die man so braucht, die klickt man da einfach rein ins Dockercompose, dann sagt man Dockercompose ab und die ganze Dockertechnologie sagt ja schon, wenn ich mir das nicht gerade als Volume Speicher, was man da nicht machen sollte als Test.
Alles ist frisch ja ich bring es drauf und dann ist es immer wieder gleich also wie ich es drauf gebracht hab und dann hab ich einen Container so mach ich das dann immer wo ich mein Wo der Test läuft das ist der der Container den ich testen will ja zum Beispiel ne Konnektivität zum Beispiel. Der läuft dann gegen die restlichen Container, prüft das alles durch und dann lass ich das ganze System wieder
verschwinden. Tocca Compost down, Schluss aus, Ende ja nächster Test Tocca Compose ab wieder alles hoch und zack ja und geht los. Ja und damit kann man relativ zügig relativ einfach Integration Test schreiben ja ohne viel Kopfschmerzen ja und die sind die sind sehr sehr wertvoll weil die alles Mögliche zeigen ja. Wird halt dann immer das ganze Produkt einmal so aufgebaut, also ganz frisch in diesem Clean State. Wie es in echt wäre, wenn man es dann jetzt wirklich released.
Oder so, so annähernd. Ja ja, erstmal nicht das ganze Produkt. Ne wenn ich das ganze Produkt aufbaue und teste dagegen, da sind wir dem Ende zu Ende. Test ja also ich baue den Teil des Produktes auf den ich brauche um was zu testen. Ne ganz oft ist halt irgendwie zum Beispiel ne Datenbank halt mit Teil des Produktes und ja jein Gerrit also du kannst du machst es so gut wie es geht, dass es aussieht wie im finalen Produkt ich sag es mal so ja das ist nicht immer möglich aus 1000 gründen.
Aber du kannst mit Docker Compost die Container schon so ähnlich aussehen lassen wie es geht zum Produktionssystem und siehst damit sehr sehr viel. Ja o. K wann, wann passiert das in deinem Entwicklungsprozess, dass das durchläuft. Aber wann das läuft? Ja o. K also das passiert immer, wenn wir nen Commit machen tatsächlich ja, also es gibt ja die sogenannte CICD Pipeline, wie man so schön sagt, Continuous Integration, Continuous Delivery, glaub ich.
Manchmal sag ich deployment, ich glaub es war Delivery. Hatten wir auch schon mal ne Folge.
Also es ist das ist dann wieder Tooling um dich rum, aber wenn du quasi sagst ich hab n neuen Stand der Software ich committe also was ist n repositor ich mach nen neuen neuen Commit, dann triggert normalerweise automatisch ne Pipeline los, das ist n extra Server typischerweise der erkennt halt diese ganzen Tests, der hat diesen Code und der läuft die alle durch ja also bei uns kommt bei mir kommt ständig am Tag locker 20 mal oder sowas bei jedem commit kommt dann so ne
Nachricht schon. Ist ja alles heute miteinander verhakt. Dass CI Tests erfolgreich durchgelaufen hat. Die werden dann alle Durchgerauscht, ja. Dafür hast diese diese Anweisung, das zu tun, die sind irgendwo aufgeschrieben, ne. Also genau da gibt es auch wieder verschiedene Tools.
Aber also wir nutzen da, das ist kein Geheimnis, Wir nutzen davon github, die Github actions, das ist extra dafür gemacht, ist richtig cool, da kann man so n kleines Skript aufschreiben, was der wann wie aufrufen soll, ist ja auch oft matrixmäßig du musst dann verschiedene. Auf das ist dann verschiedene Sprachversionen und so weiter und sofort. Das konnte alles aufbauen und dann läuft das alles automatisch
durch. Das ist n Feature was man gestellt bekommt tatsächlich von github auch die Serverressourcen um das Durchzulaufen ist ganz cool.
Ja und da gibt es natürlich alle, da gab es früher noch Travels und so weiter das das hat sich also das das ist so, das ist immer in Entwicklung, da ist mal das Tool besser mal das andere, aber an der an der Praxis ist es bleibt es immer gleich und versucht möglichst mit jedem mit jeder Änderung des Codes. Alles, was ich an Tests hab durchzuschießen ja weil nur dann weiß ich, dass diese Änderung keinen Effekt hat auf den gegebenen Code.
Ja, da kann ich ruhig schlafen, ne, das ist ganz wichtig. Ja und je mehr ich getestet hab, wenn ich wenn ich wenn ich wirklich ganz viele Tests habe, dann kann ich sogar große Refaktorisierungsmaßnahmen vornehmen im Code und wenn ich die dann committe und alles ist wieder grün, dann weiß ich OK das hab ich im größten großen Stil wohl geschafft, ja. Führt jetzt mich dazu. Jetzt hast du gefragt, wann laufen die Tests noch interessanter ist die Frage, wann schreibt man die. Tests?
Ja, das meinte ich. Eigentlich. Das meintest du eigentlich. Nein, das ist OK. Ich meinte genau das, was du gesagt hast. Ja, dieses automatisierte Triggernde Tests nach jedem Commit, das war. Ja genau, ja das also das, das muss man vielleicht auch nicht nach jedem Commit machen. Man kann auch sagen, bei jedem Tag oder Irgendsowas, je nachdem wie, wie, wie, wie. Also wie krass, auch wenn nicht.
Das ist. Bei uns ist das noch gerade akzeptabel, dass das, dass das so geht, die Server laufen da schon ganz ordentlich, aber es geht schon so. Ja ich ich, ich würde es empfehlen, dass man das so macht, ja, da hat man immer ne gute Sicherheit, ja. Sag mal, wann schreibt man eigentlich diese Tests? Ja genau. Wann schreibt man die Test? Da hab ich ne ganz ganz klare Meinung.
Ist ganz einfach ja, aber es ist auch nicht, vielleicht nicht Lehrbuch, aber meine Meinung ist, ich schreibe halt einen Test hin, entweder weil ich n neues Feature programmiert hab. Oder weil ich n Bug gefixt hab und das sind auch die 2 einzigen Dinge, die ich in der Software tun darf.
Ja ich ich ich ich mach n neues Feature rein oder ich fix n Bug ja das ist eigentlich das ist mehr gibt es eigentlich gut, dann gibt es die Refaktorisierungen da schreib ich dann vielleicht keinen Test weil ich weder n Feature noch n bug gemacht hab ich hab irgendwie nur den Code umgeändert um ihn schöner, besser schneller zu machen, da verlasse ich mich dann auf die Tests sicher ja wenn ich wenn ich das so mache, dass wenn ich ein Feature schreibe und gleich
den Test da mit dazu schreibe. Dann passiert mir nicht, dass ich später ein böses Erwachen habe, weil dann habe ich eine gute Abdeckung, eigentlich immer, ja und und wenn ich das auch so mache, das ist fast noch wichtiger, dass wenn der User mal einen Fehler oder vielleicht sogar auch intern während QA oder irgendwas ja wenn man feststellt, Oh, da gibt es fast einen Bug oder irgendwie und ich fixe den im Code, dann schreibe ich auch einen Test, und zwar genau den Test, der mir jetzt
anzeigt, dass dieser Bug vorher. Gefällt hat und nach dem Fixing im Code dieser Test nicht mehr failed sondern paste. Ich teste also, dass dieser Bug nicht mehr vorkommt, es ist ja irgendein, es ist ja, es war ja irgendeinen Edge Case oder irgendein Prozess, irgendein Verhalten, in dem in dem Code der vorher nicht abgetestet wurde und diesen Bug habe ich erkannt und den hinterlege ich mit dem Test. Und das nennt man dann auch Regression Tests. Ja, das hat was mit der Zeitleiste zu tun.
Ja, also in dem Moment wo ich quasi nen Feature oder nen Bug im Test hinterlege, dann dann hab ich es natürlich getestet, dann seh ich das funktioniert, das wäre quasi einfach testing, aber für alle zukünftigen Weiterentwicklungen des Codes drumherum werden werden diese Tests quasi mein Safety Netz. Ja das ist mein Sicherheitsnetz ja weil weil weil dann weiß ich schon wenn ich wieder was angefasst habe und oft ist das ja nicht nicht so einfach zu sehen für Entwickler wo sich
irgendwie. Wenn ich hier ne Schraube drehe, was passiert noch so alles im Code, vor allen Dingen wenn man im Team arbeitet. Wenn aber jeder sein Feature und seine Bugs immer ordentlich testet, dann kann man sich relativ sicher sein, dass das cool ist. So ja, klingt total einleuchtend, das ist mein einfacher Advice. Ja, es gibt es gibt noch ne andere Lehrbuchmeinung, die davon halt ich nichts, aber die
die muss man mal. Jeder der kommt der der Vollständigkeit erwähnen es gibt dieses Test Driven Development TDD ist auch so n Keyword da da da macht man das noch anders, da
sagt man halt ich schreib. Gar nicht erst Bug oder Feature hin, sondern ich schreib mal den Test hin oder ganz viele Tests, die dann erstmal alle fehlschlagen, weil ich noch gar nicht den Code dazu hab und dann schreibe ich den Code, der dazu führen muss, dass diese Tests grün sind und wenn die Grün sind, dann hab ich wohl guten Code geschrieben. Ne, ich mag diese ganze Philosophie nicht ja also ich ich find das irgendwie rückwärts und komisch ja also ich nicht.
Es mag Firmen geben, die das so machen. Ich find das irgendwie doof, weil ich überleg mir lieber erstmal genau was für n Features ist. Genau wie ich das Coden will, dann Code ich das auch in Ruhe und dann muss ich mir die Zeit nehmen.
Das ist halt so, vielleicht auch nicht nur den den Good Case Abzutesten das ist die Kunst beim Testen glaub ich und als Entwickler das schlimmste ich weiß ja was ich geschrieben hab und ich weiß wann es funktionieren wird wahrscheinlich und normalerweise schreibt man genau den Test hin der zeigt es funktioniert ja. Ich muss mir aber eigentlich, wenn ich Feature gemacht hab, ganz ganz stark in pokneifen sag ich mal als Entwickler und überlegen, wie könnte man das
alles noch benutzen. Ja und zwar ganz kuckelig und falsch. Ja also alle möglichen Cases ja und ich muss auch zeigen und das ist auch wichtig, erstens das also noch mehr als ein Test schreiben zu dem einen Feature und ich muss auch testen, dass es unter den nicht unter den unter den schlechten Zuständen auch nicht funktioniert noch die richtigen Fehlermeldungen gibt und so weiter.
Ist ganz oft so und das erleiden wir auch ganz oft noch, dass wenn wenn irgendwas nicht so ist, wie es sein soll, dass dann zum Beispiel die Fehlermeldung irgendwie kacke ist oder oder völlig quer ja oder irgend sowas, das kann man in den Tests, wenn man die gut macht auch schon mit testen. Ja also ich ich ich fordere eine einen Fehler heraus bei dem Test und analysiere den Fehler ob der auch ordentlich ist und solche Sachen, ja das gehört auch dazu, also negativtesting quasi ja
das. Ich wollt, ich wollt grad noch fragen, wie schreibt man denn jetzt eigentlich gute Tests? Jetzt hast du es schon so n bisschen gesagt, aber das bedeutet ja auch man muss wirklich Prozentsatz x seiner Zeit und auch gehirnkapazität dafür auch wirklich einplanen und und und. Vom Chef hast du jetzt nicht, aber wenn man einen hätte oder ne Chefin dafür auch die Zeit bekommen tatsächlich ne haben das auch zu tun. War früher richtig aufwendig. Jetzt haben wir KI.
Ah ja, jetzt. Ist es relativ schnell, ist der Drop relativ schnell gelutscht. Ja. Ja, weil tatsächlich KI, also ich weiß nicht, doch ich weiß, ich kann mir vorstellen, warum. Ja, KI ist unglaublich mächtig im Testschreiben, ne, weil man kann sich vorstellen, warum bei KI, so wie sie es funktioniert mit den ganzen Wahrscheinlichkeiten, dem Lernen und dem Trainieren und so weiter das ist ja, Tests sind sehr sehr sauber und strukturiert
aufgeschrieben, ne also. Das ist ja so n if than Else oder ich ich, das ist oft oft in diesen Test dramworks auch in so einer Art Englisch geschrieben, das kannst du richtig lesen, wieso n Buch ja wenn das passiert, dann expected das oder hat zu sein oder contains und so die die nutzen auch richtig normale Wörter quasi in der API, also hat das AKI wahrscheinlich sehr gut gelernt und ist sehr gut in der Lage Tests zu schreiben und das ist ja auch echt so n so ne Aufgabe die also
ich kenn ja wenig Entwickler denen das Spaß macht. Und KI donnert das halt einfach runter. Es muss aber gemacht werden, es ist total wichtig und es ist auch kein Boilerblade das KI da generiert.
Du kannst halt KI sagen, guck mal das ist mein Feature und jetzt überleg mal was kann da alles schiefgehen und überleg dir einfach mal richtig viele Tests dazu, ich mach das den ganzen Tag ja also ich les dir auch und Review die und überleg ob es noch mehr gibt aber die schreib ich dann meistens auch nicht selber lass dich KI schreiben und Review die wieder weil weil das unglaublich mächtig ist KI und dann bist du also es gibt eigentlich kein Excuse mehr heutzutage mit mit
mit KI keine Tests zu schreiben ne. Also gibt es keine Excuse mehr, Software auszuliefern, die die Buggy ist im Grunde genommen. Ja, wenn man es, wenn man es bis auf die Spitze treibt, müsste es so sein. Ne, genau. Gut, aber es gibt natürlich noch die, die die Teile denen, wo noch kein Bug da war und noch keine oder noch keine entdeckt wurde und noch kein Feature neu entwickelt wurde, wo es dann eben Contact. Ja, und es gibt halt die Abstraktionslevels ne.
Also ich hab jetzt von Integration Test gesprochen, das kann schon sein, dass die alle cool sind und dann geht ja trotzdem Ende zu Ende was kaputt, ja. Und oft liegt da der, der der Hase im Pfeffer, weil wir sprechen mal gerade aus dem Nähkästchen, auch wieder Aktuelles gibt. Manchmal echt schwierige Sachen, ja, weil weil dir büchst halt irgendwie in einem Use Case was aus, da hast du auf einmal n Burst von 10000 Clients, die wollen irgendwie was gleichzeitig, ja und dann?
Dann gehen die wildesten Sachen kaputt, die du so überhaupt noch nie auf Zettel hattest. Ja, führt mich auch noch zu einer anderen Kategorie von Tests. Jetzt haben wir von den funktionalen Tests gesprochen, die unter, ich sag mal so mehr oder weniger normalen Umständen laufen. Wenn man das richtig ernst betreibt und ne verteilte Plattform hat mit Cloud und allem drum und dran, muss man eigentlich auch Last oder Performance Tests schreiben die die Abprüfen.
Was. Wie verhält sich dein System unter nicht normalen unter unter extrem anstrengenden Bedingungen sag ich mal ja und und die Tests ganze aber die müssen wir n bisschen extra behandeln, die die sind schwierig in so ne CICD
Pipeline einzubauen ja weil die. Ja, die, die brauchen halt oft noch mehr Material. Die müssen ja auch erstmal quasi das alles simulieren, dass du so viele Clients hast und so weiter die sind noch komplexer zu schreiben und noch komplexer auszuwerten, aber die sollte man auch haben bis zum gewissen Grad und auch in irgendeinem Schema laufen lassen und dass man da auch sicher ist, dass man auch keine Performance Bugs einbaut, die sind nämlich hart zu tracken.
Ja, kann ja sein, dass immer noch alles funktioniert, es ist aber leider irgendwie zehnmal langsamer geworden und ich seh es erst wenn wenn der nächste User mit einem Sturm von Nachrichten ankommt oder irgendwas ja.
Wegen Memory League oder irgendwie solche Geschichten dann ne. Ja, wegen also Timing spielt ja, und das ist das komplizierte beim beim verteilten System spielt ja das Timing und Asynchronität ne ne riesige gigantische Rolle. Ja im Notfall komme ich in irgendein Limit rein, ne memory Bandbreite, netzwerkbandbreite, CPU Last Storage was ich gleichzeitig hier ne auf dem Disc schreiben kann aber ich bin halt einfach immer in der Lage wenn ich nicht auf einem physikalischen Not bin.
Sondern hab mehrere zusammengesteckt und sag halt irgendwie hier ihr 100 ihr schickt mir alle wie wild Nachrichten auf den einen und das sind klassische Architekturen. Irgendwo hab ich immer mal irgendwo ne Stelle wo wo wo wo Daten zentral archiviert werden müssen, da gibt es natürlich 1000 patterns in der Software, aber das passiert halt und das kann ich halt nicht mit Unit Tests und auch nicht mit dem einfachen Integration Test
spiegeln. Ja da brauch ich halt echt ich bring halt die die Hardware und die Software damit an ihre Grenzen indem ich indem ich tatsächlich erstmal 100 Streams TCP Streams aufbauen muss von Notes, die physikalisch in der Lage sind den einen kaputt zu Bomben. Ja ist gar nicht so einfach alles zu simulieren, ne das sind so das sind Tests wo man sich wirklich viel Gedanken machen muss, ja dann die dauern halt auch ihre Zeit hinzuschreiben. Kann man dann so für so Performance Tests auch.
Gibt es da testumgebungen? Sag ich mal wo man dann Traffic simulieren kann ne bestimmte Anzahl von Anfragen oder solche Geschichten. Ein kurzer Hinweis in eigener Sache. Kennst du das auch? Ihr seid gefangen zwischen starrer, veralteter Standardsoftware und endlosen Individual Entwicklungsprojekten. Unsere Mission bei Heisenware ist es, das zu beenden mit unserem App Baukasten geben wir dir die Möglichkeit, maßgeschneiderte Software für den Shopfloor schnell und ohne Code zu erstellen.
Denk an Maschinendatenerfassung moderne Visualisierung für die Produktionsleiter oder eine mobile App zur Buchung von Zeiten und das beste du kannst deine Lösung ganz einfach ohne it Aufwand selbst betreiben. Kurz gesagt, günstiger als eine externe Entwicklung unendlich passender als Software von der Stange. Weitere Infos und eine kostenlose 30 Tage Testphase findest du auf heisenware.com. Slash einfach minus komplex und jetzt viel Spaß mit der weiteren Folge. Ja, es gibt.
Also es gibt es gibt ganz viele Tools noch und nöcher. Es gibt auch, also es gibt vor allen Dingen auch Frameworks, haben wir noch nicht drüber gesprochen heute, also für diese Integration Tests. Würde überhaupt für, ich sag mal das innere Test schreiben. Ich sag mal nur 1, was ich halt
irgendwie ist. Daily Bat and Butter ist just also JEST, das nimmt man so in der Webwelt ist super für Note GS und und und und React Tests und so weiter ja und dann gibt es diese für für diese krasseren Tests so also für diese End to end Test. Da muss ich ja quasi irgendwie mit dem Browser simulieren und alles mögliche ne. Also ich muss ja n ich muss ja quasi automatisiertes so tun als
hätte ich n Knopf gedrückt. Und dann will ich eigentlich, auch wenn der Test fehlschlägt, Hits mir auch nicht zu sagen, der ist jetzt fehlgeschlagen. Ich muss ja irgendwie das verstehen können als Entwickler, wann ist da was passiert, also hab ich da am liebsten auch so n Framework, was mir zum Beispiel genau aufzeichnen kann, in welcher Millisekunde ist da was gerendert und warum, da gibt es halt auch so Tools.
Ja das älteste was man da so kennt ist Silenium ist so n bisschen der bisschen wie wie C für für Testing gibt es auch immer noch im Markt, gibt aber jetzt modernere Tools zum Beispiel Cypress oder playright ich will den mal hier nennen, die sind halt coole Tools wo man ja die hängen sich quasi in den Browser rein, die simulieren quasi die ganze Browser Engine und mit denen kann ich quasi im Test sagen, drück mal jetzt auf diesen Knopf, ja und dann drückt es quasi tatsächlich auf diesen
Knopf, aber es macht halt der Test automatisiert und dann kann ich mehr oder weniger mit auch mit fast englisch Grammatik irgendwie sagen und jetzt erwarte ich das und das Ergebnis und so weiter ja die Kunst ist das Schwierige für diese Produkte ist diese Asynchronität. Abzukriegen ja, weil weil die Sachen nicht gleich lang dauern.
Ne die testen ja quasi dann auch so viele Komponenten, Netzwerk und und Browser, dass du ne gewisse wie soll ich sagen ne gewisse Grauzone hast wann exakt was kommt und so weiter ja und das nennt sich flakiness ja, also wenn dein Test mal funktioniert und mal nicht, obwohl du nichts geändert hast. Also eigentlich, das hat man ganz am Anfang ne du willst eigentlich genau den gleichen State haben und testest was und mal ist der Grün und mal ist der Rot, dann nennt man das Flakey.
Und das halt ganz gruselig, weil dann weißt du dann, den kannst du lieber gleich streichen den Test, weil dann das, damit kannst du gar nichts anfangen, weißt du nicht was du hast? Ja, und und die Tests werden umso flakier, je abstrakter sie sind. Ja, also Ende, Ende zu Ende, Test nicht flaky hinzumachen, dass sie immer genau gleich sind und sich gleich verhalten, das hat halt auch was mit dazu zu tun, wie du deine Architektur aufgebaut hast.
Ja ob die sauber immer gut durchläuft, ja oder ob die sich irgendwo verschluckt irgendwann. Das ist halt, das ist ne hohe Kunst. Aber da helfen dir halt auch diese Tools, die sind halt viel, viel besser geworden als früher, um das automatisch zu warten und so weiter gut abzuschätzen und so gut. Haben wir mal n paar Frameworks
noch kennengelernt? Wie viele kann man vielleicht bei uns noch mal n Beispiel machen, wie viele so End to end Tests haben wir, also kann man darüber reden und weil wir haben ja noch mal ne extra Schwierigkeitsstufe bei uns drin, weil wir haben ja n Produkt mit dem man dann wieder Software bauen kann. Die kann man ja auch, die kann ja sonst wie aussehen, da kann man ja gar nicht alles
durchtesten. Ja, und dann haben wir ja alles schon erlebt, ja, dann kommt der eine Kunde hat noch n iphone von 2015 oder so OK ist n bisschen übertrieben, aber älteres Modell ja und hat dann irgendeinen Browser drauf und dann sieht das da n bisschen anders aus als auf dem neuesten Samsung Galaxy s 25 oder wie es heißt keine Ahnung. Ja es ist halt anders. Ja, du hast Recht, also das. Also das ist genau das ne, also man man man kann also man kämpft gegen Windmühlen, ne also.
Das schaffst du gar nicht abzudecken und meine, meine Philosophie ist, wir haben gar nicht so viele automatisierte Ende zu Ende Tests. Ja, ich finde ich finde im Moment noch für uns als kleine Firma ist es wirtschaftlicher, wirtschaftlicher klingt so blöd ne, aber es ist einfach effizienter und erfolgreicher wenn wir uns die Zeit im QA nehmen oder wie auch immer man das nennen will, manuelles Testing ne es ist halt nicht automatisiert, aber wir nehmen
uns halt die Zeit um die Sachen selber durchzuklicken und zu gucken ob die funktionieren ne das kann lange besser sein als. Als Auto versuchen, das zu automatisieren, weil es echt
extrem schwierig ist. Ich, ich geb dem noch mal ne Chance. Wir sind tatsächlich auch gerade am Versuch. Es gibt auch Plattformen, also Cloud Plattform Cloud Anbieter. Ich nenn jetzt hier mal keinen, aber ich keine Werbung machen will, aber die die auch mit KI an Bord quasi dir dir da ganz viel erlauben weil da kannst du quasi so n Link hinschicken und dann nehmen die da quasi du spielst das einmal durch, die Zeichnen das mehr oder weniger
auf und dann wird das quasi eingebettet in nen Test mit KI und dann wird auch quasi nen nen Cypress oder? Oder Play Ride Test quasi erstellt im Hintergrund. Ja, da gibt es richtig viel cooles Krams. Ja, da gucken wir immer mal wieder drauf, das braucht aber auch seine Zeit um sich da um da quasi am Zahn der Zeit zu
bleiben. Was sind das für Tools und die musst du irgendwie integrieren und so weiter und sofort, das muss immer wieder laufen, ich muss sagen da sind wir noch nicht ganz fertig, ich analysiere da immer noch den Markt und solange das irgendwie für mich noch nicht so richtig ganz klar ist, machen wir auch viel beim Ende zu Ende, testen einfach viel manuell, ja. Ja, ja, kann ich auch n Lied von
singen. Ich bin hier regelmäßig involviert, ja die Dinge einfach durch zu testen durch zu klicken, hab dann immer auf meiner Demo die neueste Version ja und darf dann Features auch mal live vertesten. Das ist so. Ja, genau. Aber so ist es ja, das ist ja cool und man, man schlägt gleich mehrere Fliegen mit einer Klappe, quasi ne. Ja, du hast, du hast da. Du kannst nicht alles haben, ne,
du kannst. Also du kannst natürlich sagen, OK ich, aber das ist wie wie wie wie mit dem mit dem verteilten System. Du kannst nicht alle Parameter
optimieren, ja du kannst. Kannst irgendwie versuchen Kompromiss zu finden zwischen wir sind reaktiv und antworten Antworten auf User request und versuchen Features auch reinzubringen versus wir sind absolut irgendwie, da passiert überhaupt nichts, wenn du das nächste Release hast oder aber dann, dann haben wir halt NN Release Cycle von einem in einem Jahr haben wir n neues Feature draußen oder irgend so was ja und bei einer kleinen Firma glaub ich kriegst du nicht alles
optimiert ja du und du musst halt für dich den Kompromiss finden ne. Mhm. Ja, wir werden auch größere. Firmen Verkämpfen haben auf anderem Level. Glaub ich auch. Glaub ich auch. OK, haben wir noch was vergessen? Zum Thema Software Testing. Ja, bestimmt und bestimmt gibt es auch ganz viel dazu zu erzählen. Mit anderer Meinung, aber ich glaub ich hab so n bisschen was rübergebracht, was wie ich das
so sehe. Ich glaube, dass man mit KI sei vielleicht mal abschließend, so wie man überhaupt seine ganze Entwicklung überdenkt, gerade und wie alles irgendwie sich auf den Kopf stellt ist KIN krasser gamechanger was das Testing halt auch angeht und vielleicht auch das NTN Testing. Und vielleicht haben wir dann noch mal ne anderes, ne andere geographische Figur, ne umgedrehte Pyramide oder
irgendwas später. Weiß es nicht, weil halt einfach dieser durch das Code generieren ist halt dieser massive Aufwand. Das Mantain ist halt nicht mehr so krass. Ja und wenn KI schafft nicht flakey seriöse Ende zu Ende Tests zu schreiben die man zügig Revuen kann, das ist n krasser Mehrwert da also wir nutzen es für degration Tests zum Beispiel auch richtig viel da, also es funktioniert wunderbar. Mhm. OK, kann ich nur empfehlen. Fand ich ne coole coole Folge. Ja, viel.
Theorie sozusagen, aber komplett angereichert mit der Praxis und der Erfahrung, die du da hast. Und wir in unserer Entwicklung super das was dabei das was dabei mach mal sag zu wie du es immer sagst, ja hab ich lang nicht gesagt, aber machen wir das ja, sag zu genau wir danken euch fürs Zuhören und wenn ihr Lust habt, dann schreibt uns wie ihr so testet, vielleicht habt ihr noch gute Tipps, die nehmen wir immer gerne an würde ich sagen und die anderen Hörer bestimmt auch.
Und dann bis in 2 Wochen bei einfach komplex macht's gut tschau tschau. Bis zur Folge 104 Tschüss aus Hamburg. Einfach komplex wird produziert und präsentiert von Heisenware. Heisenware ist deine Low Code Plattform zur Erstellung und zum Betrieb interaktiver Apps rund um den Shopfloor. Starte noch heute deinen Free Twil unterheisenware.com einfach komplex.