Latest / Coding Buddies | Tech & Dev-Mindset / Eine Geschichte von Pyramiden und Testen

Transcript

Eine Geschichte von Pyramiden und Testen · Coding Buddies | Tech & Dev-Mindset

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