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.
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.