WEBVTT 00:00:08.320 --> 00:00:09.360 Binärgewitter, 00:00:19.280 --> 00:00:25.760 herzlich willkommen zu Binärgewitter Spezialusgabe 5 zum Thema 00:00:25.760 --> 00:00:26.640 Testing. 00:00:26.880 --> 00:00:28.480 Und ist ja schon ein bisschen Tradition. 00:00:28.560 --> 00:00:32.320 Wir kündigen immer eine Menge Spezialsendungen an und irgendwie wird es nichts, 00:00:32.480 --> 00:00:35.760 aber deswegen haben wir uns diesmal wieder ein komplett anderes Thema genommen, 00:00:35.920 --> 00:00:39.600 nämlich Testing und mit dabei sind Marc. 00:00:39.840 --> 00:00:40.400 Hallo. 00:00:40.720 --> 00:00:41.520 Flydi. 00:00:41.680 --> 00:00:42.640 Ja, ich bin der Fleidi. 00:00:42.960 --> 00:00:43.600 Felix. 00:00:43.840 --> 00:00:44.160 Moin. 00:00:44.560 --> 00:00:45.360 Und Matt. 00:00:45.840 --> 00:00:46.160 Hi. 00:00:46.560 --> 00:00:47.760 Und ich bin auch dabei. 00:00:48.000 --> 00:00:50.480 It really whips the Lambers Ass. 00:00:51.440 --> 00:00:58.160 Und das ist auch gleich schon trotz Testing Spezialsendung unser kurzer Tote der Woche. 00:00:58.640 --> 00:01:00.720 Weil Felix, du hast es reingeschrieben. 00:01:01.200 --> 00:01:02.560 Win'Amp ist gestorben. 00:01:02.880 --> 00:01:07.200 AOL hat WinAmp gestorben werden lassen. 00:01:07.840 --> 00:01:09.680 Win'Amp ist jetzt nicht bei Apache. 00:01:10.000 --> 00:01:10.400 Noch nicht. 00:01:10.640 --> 00:01:12.720 Nee, sie haben sich komplett aufgelöst einfach weil. 00:01:13.840 --> 00:01:14.160 20. 00:01:14.320 --> 00:01:20.400 Dezember machen sie die Webseite dicht und du kannst nicht mehr runterladen und es geht in die ewigen 00:01:20.400 --> 00:01:20.880 Jagdgründe. 00:01:21.200 --> 00:01:24.160 Es gibt ja irgendwie schon eine Petition, dass es freigeben sollen, Open Source. 00:01:24.800 --> 00:01:27.280 Dafür haben sie so coole Visualisierung eigentlich immer gehabt. 00:01:27.440 --> 00:01:29.280 Die haben nämlich quasi einen Make-Drop gehabt. 00:01:29.440 --> 00:01:32.480 Das war eine Zeit lang irgendwie der Player schlechthin? 00:01:35.360 --> 00:01:39.280 Hat er sich gerade mit seinem Headset ins Gesicht geschlagen, der hat geslappt. 00:01:39.520 --> 00:01:41.920 Er hat sich mit dem Headset selbst geslappt. 00:01:42.000 --> 00:01:42.320 Oh Mann. 00:01:42.640 --> 00:01:44.080 Erlaubt ist, was gefällt bei uns hier. 00:01:44.320 --> 00:01:45.440 Also, ganz ehrlich, Leute. 00:01:45.600 --> 00:01:47.200 Das war ein fehlgeschlagener Unit-Test. 00:01:48.480 --> 00:01:48.800 Ja. 00:01:49.200 --> 00:01:54.160 Okay, also WinAmp ist tot, geht ein und ihr benutzt halt XMMS. 00:01:54.720 --> 00:01:56.880 Genau, den anderen riesigen Cancer dazu. 00:01:57.600 --> 00:01:59.840 Also ich glaube auch den Winam Code, den will keiner lesen. 00:02:00.000 --> 00:02:01.680 Das ist so wie ein Netscape Code, den wollen er auch gerne. 00:02:01.840 --> 00:02:02.400 Es gibt wie XMM. 00:02:02.640 --> 00:02:07.280 Es gibt der WinAm auch für Mac OS, es ist ja nicht nur WinAmp, sondern es gibt dann auch Android WinAMP und 00:02:07.360 --> 00:02:08.400 also das Win ist dann. 00:02:12.160 --> 00:02:17.200 Das ist eine Art von Windows Amplifier oder so umgewandelt worden in Vamp. 00:02:17.520 --> 00:02:17.920 Richtig. 00:02:18.160 --> 00:02:20.640 Ja, aber es ist schon schade, dass das Lama jetzt einfach nicht. 00:02:21.360 --> 00:02:22.480 Das Lama war schon echt cool. 00:02:22.800 --> 00:02:23.120 Ja, gut. 00:02:23.200 --> 00:02:24.000 Haben wir das auch gekriegt? 00:02:24.160 --> 00:02:24.400 Genau. 00:02:24.560 --> 00:02:26.480 Gut, kommen wir zu Testing. 00:02:27.120 --> 00:02:32.880 Also die Leute, die irgendwie gerade im Chat sind und uns live hören, 00:02:33.040 --> 00:02:36.000 die werden sich ein bisschen wundern, dass wir ein anderes Thema machen, 00:02:36.080 --> 00:02:40.800 aber das ging jetzt noch, weil Marc noch da ist, der geht ja demnächst über den großen Teich. 00:02:41.280 --> 00:02:44.560 Und deswegen haben wir uns dieses Thema nochmal vorgenommen. 00:02:44.960 --> 00:02:48.160 Zuerst mal, was versteht ihr denn unter Testing? 00:02:48.240 --> 00:02:50.640 Also ich bin ja dann nicht Coder, ich habe überhaupt gar keine Ahnung. 00:02:50.720 --> 00:02:54.960 Ich mache ja einfach mal, ich stelle einfach nur die dummen Fragen heute und frage jetzt einfach, 00:02:55.760 --> 00:02:57.440 was ist Softwaretesting, Marc? 00:02:58.080 --> 00:03:03.760 Softwaretesting ist eine Methode, um Komplexität skalieren zu lassen. 00:03:04.080 --> 00:03:04.320 What? 00:03:05.600 --> 00:03:07.840 So schön aus Wikipedia lesen. 00:03:08.320 --> 00:03:08.880 Nee, gar nicht. 00:03:09.040 --> 00:03:12.400 Habe ich mir immer mal gemerkt, weil es irgendjemand gesagt hat und ich fand das eigentlich ganz gut. 00:03:13.040 --> 00:03:16.800 Softwaretesting ist eben, finde ich, so was, was. 00:03:17.360 --> 00:03:20.640 Ich meine, das Ganze nennt sich ja Software Engineering im Englischen, 00:03:20.800 --> 00:03:24.320 obwohl da von Ingenieurswesen eigentlich nicht sonderlich viel drin ist, 00:03:24.640 --> 00:03:29.360 außer man begibt sich eben in die Richtung, wo man dann wirklich auch sicherstellt, 00:03:29.440 --> 00:03:33.840 dass die Sachen, die man baut, auch funktionieren, wie das Ingenieure ja hoffentlich normalerweise machen, 00:03:34.000 --> 00:03:35.520 mit irgendwelchen Teststellungen. 00:03:35.600 --> 00:03:41.520 Und Softwaretesting ist eben dafür da, um deine Programme nachher auf ihre Korrektheit zu überprüfen. 00:03:41.680 --> 00:03:45.200 Und man kann es natürlich nicht beweisen, da gibt es ja irgendeine Halteproblemgeschichte. 00:03:45.600 --> 00:03:51.600 Und man kann aber versuchen, zumindest alle Use Cases, 00:03:51.680 --> 00:03:52.720 was ist das auf Deutsch? 00:03:53.360 --> 00:03:54.080 Anwendungsfälle. 00:03:54.400 --> 00:03:58.960 Anwendungsfälle, die normalerweise so ein Benutzer hat oder die einem sehr wichtig sind, 00:03:59.120 --> 00:04:02.320 durch einen Test abzudecken, dass das einmal durchexerziert wird. 00:04:02.640 --> 00:04:06.880 Und es kommt dann eben darauf an, ob du deinen kleine Bibliothek, die du schreibst, 00:04:06.960 --> 00:04:10.160 testen willst oder ob du nachher das komplette Produkt testen willst. 00:04:10.480 --> 00:04:16.000 Aber solche Tests helfen dir dann eben, je größer die Applikation wird, 00:04:16.720 --> 00:04:20.240 Änderungen mit ein bisschen mehr Vertrauen durchzuführen. 00:04:20.560 --> 00:04:23.200 Genau, also es ist auch Qualitätssicherung dann quasi. 00:04:24.800 --> 00:04:29.840 Also was mir stark auffällt, also wenn ich Software schreibe, 00:04:30.080 --> 00:04:33.760 bei irgendeinem Punkt hat man so nicht mehr das Gefühl, dass man das, 00:04:33.840 --> 00:04:37.040 was man gerade ausführt, dass man das wirklich noch versteht, was es eigentlich tut. 00:04:37.120 --> 00:04:41.120 Und man hat so das Gefühl, so irgendwie, kann das überhaupt noch funktionieren? 00:04:41.280 --> 00:04:44.560 Was sich gerade gemacht hat, hat es irgendwie einen Einfluss auf das, was ich dahinter gemacht habe. 00:04:44.640 --> 00:04:50.560 Und Tests sind für mich dann quasi die Bestätigung, dass das, was ich davor irgendwann mal geschrieben habe, 00:04:50.640 --> 00:04:53.600 was jetzt vielleicht schon einen Monat her ist oder fucking ein Jahr oder so, 00:04:53.840 --> 00:04:55.360 dass das auf jeden Fall noch tut. 00:04:55.440 --> 00:04:57.040 Und das ist ein gutes Gefühl einfach. 00:04:57.120 --> 00:05:01.440 Das gibt dir quasi dieses Gefühl der Unsicherheit macht es ein bisschen weg und gibt dir ein bisschen gutes 00:05:01.440 --> 00:05:01.920 Gefühl. 00:05:02.320 --> 00:05:02.800 Also mir. 00:05:03.040 --> 00:05:07.600 Ja, das gute Gefühl, das würde ich tatsächlich, dem würde ich einen Namen geben, nämlich Selbstbewusstsein. 00:05:07.680 --> 00:05:14.000 Also Tests machen, dass du selbstbewusst deinen Code ändern kannst, 00:05:14.160 --> 00:05:20.800 ohne dir furchtbar schrecklich schlaflose Nächte zu machen, 00:05:21.120 --> 00:05:24.640 weil du Angst hast, dass dir alles um die Ohren fliegt. 00:05:24.800 --> 00:05:29.040 Du kannst zumindest sagen, den Teil, den du durch Tests abgedeckt hast, 00:05:29.360 --> 00:05:33.920 wenn die Tests weiterhin durchlaufen, dann wird der Teil weiterhin funktionieren. 00:05:34.000 --> 00:05:37.760 Und dann kannst du halt sagen, okay, wenn irgendwas anderes bricht und du merkst es in der Applik, 00:05:37.920 --> 00:05:44.400 äh, im Produktionsbetrieb dann, dann schreibst du dir einen Test dafür und dann weißt du, 00:05:44.480 --> 00:05:46.320 dass das in Zukunft nicht mehr brechen wird. 00:05:46.400 --> 00:05:48.640 Es sei, oder der Test wird fehlschlagen. 00:05:49.360 --> 00:05:52.560 Und zu der Geschichte, die Marc erzählt hat, wollte ich noch anbringen, 00:05:52.720 --> 00:05:58.960 ein Ingenieur ist halt auch so eine Sache, also die bauen oft so physikalische Dinge. 00:05:59.280 --> 00:06:03.360 Also, keine Ahnung, jetzt Brücken oder Häuser oder was auch immer. 00:06:04.080 --> 00:06:05.280 Motorsteuergeräte. 00:06:05.600 --> 00:06:12.400 Da muss man natürlich viel simulieren, da muss man auch viel ausrechnen und sich 00:06:12.400 --> 00:06:14.560 viel überlegen, weil man kann das nur einmal machen. 00:06:14.640 --> 00:06:17.360 Jetzt haben wir halt im Softwarebereich den Luxus, wir können halt sagen, 00:06:17.440 --> 00:06:21.840 ja gut, wir arbeiten iterativ und wir fügen dann immer mehr neue Features hinzu. 00:06:22.160 --> 00:06:23.520 Wir hangeln uns von Fehler zu Fehler. 00:06:23.680 --> 00:06:30.560 Genau, wir hangeln uns von Fehler zu Fehler, aber das verleitet auch dann halt 00:06:30.560 --> 00:06:35.680 dazu, wie Mark schon erwähnt hat, sehr schludrig zu arbeiten, weil es halt immer die Möglichkeit gibt, 00:06:35.840 --> 00:06:38.640 im Nachhinein wieder Fehler zu beseitigen, was du jetzt bei so einem, 00:06:38.800 --> 00:06:43.360 bei irgendeinem Bauwerk oder bei irgendeinem Ding, was tatsächlich in der physikalischen Welt existiert hat, 00:06:43.520 --> 00:06:44.000 nicht hast. 00:06:44.480 --> 00:06:45.840 Und du kannst abreißen und neubar. 00:06:46.080 --> 00:06:51.040 Und ich finde, gerade dieses sludrige Arbeiten, das erlauben dir Tests halt auch in einer gewissen Weise, 00:06:51.120 --> 00:06:55.120 also gerade wenn du neu zu einer Codebase hinzukommst und irgendwie du weißt, 00:06:55.280 --> 00:06:58.800 das andere Team hat da irgendwas geschrieben, da kommt irgendwie ein Wert raus, 00:06:58.960 --> 00:07:01.840 aber du brauchst die ein bisschen anders oder du hast irgendeinen Edge Case gefunden, 00:07:01.920 --> 00:07:03.440 wo das vielleicht nicht so richtig klappt. 00:07:03.680 --> 00:07:06.720 Tests erlauben dir halt einfach, da reinzugehen, irgendwie zu finden, 00:07:06.800 --> 00:07:10.400 wo du es wahrscheinlich bearbeitet wird und ohne dass du den Rest vom Code kennst, 00:07:10.560 --> 00:07:14.400 kannst du eben sagen, ja, ich glaube, ihr habt dir irgendwie, wenn da kleiner als null ist, 00:07:14.480 --> 00:07:16.240 sollte man vielleicht irgendwie einen Feder zurückgeben. 00:07:16.400 --> 00:07:20.800 Kannst du da einfach reinhacken und dann einfach einmal die Tests starten und wenn die immer noch alle 00:07:20.800 --> 00:07:25.360 durchlaufen, dann kannst du eigentlich das an das Team weitergeben und sagen, 00:07:25.440 --> 00:07:27.840 hier, ich glaube, ich habe es repariert, alle Tests sind auch okay, 00:07:27.920 --> 00:07:28.240 fertig. 00:07:28.400 --> 00:07:32.160 Ja, und im Zweifelsfall ist so ein Test halt auch eine sehr gute Dokumentation, 00:07:32.320 --> 00:07:37.280 wenn du jetzt, sagen wir mal, Open Source Code benutzt, der sich irgendwie anders verhält, 00:07:37.440 --> 00:07:39.920 als du das jetzt erwarten würdest, dann kannst du halt auch sagen, okay, 00:07:40.000 --> 00:07:44.960 du lieferst mit deinem Bugreport gleich einen Test Case mit, der fehlschlägt, 00:07:45.040 --> 00:07:50.160 sodass die Entwickler halt auch gleich wissen, was du erwarten würdest, 00:07:50.240 --> 00:07:56.800 weil so ein ausführbarer Test-Case, der sagt oft mehr aus wie irgendwie geschriebene Prosa in gebrochen im 00:07:56.800 --> 00:07:57.360 Englisch. 00:07:57.600 --> 00:08:01.120 Und wäre dann auch gleich einen Regressionstest bedeutet, die könnten den Test, 00:08:01.200 --> 00:08:04.160 den du geschrieben hast, auch einfach zu ihren Standardtests mit reinwerfen, 00:08:04.240 --> 00:08:07.200 um sicherzugehen, dass, ich meine, wenn einmal jemand den Fehler gemacht hat, 00:08:07.280 --> 00:08:10.080 kann es ja gut sein, dass der in zwei Monaten noch irgendwie mal sich versucht, 00:08:10.160 --> 00:08:11.120 wieder einzuschleichen. 00:08:11.200 --> 00:08:13.120 Und so ein Regressionstest hilft da. 00:08:13.520 --> 00:08:19.440 Ja, Zeit ist auch ein guter Punkt, weil, also zumindest ich neige dazu, 00:08:19.600 --> 00:08:23.280 ich bin nicht in der Lage, große Codebases auf Dauer in meinem Kopf zu behalten, 00:08:23.360 --> 00:08:24.560 ist, glaube ich, niemand. 00:08:25.120 --> 00:08:31.520 Und dann hat man halt oft das Problem, man arbeitet irgendwie an einem komplexen Code für eine gewisse Zeit 00:08:31.520 --> 00:08:34.480 und macht dann eine gewisse Zeit irgendwas anderes und kommt dann wieder zurück, 00:08:34.560 --> 00:08:37.600 um irgendwelche Dinge zu erweitern oder zu fixen oder sonst irgendwas. 00:08:37.680 --> 00:08:41.680 Und plötzlich weiß man nicht mehr, wie man seine Klassen, die man selber geschrieben hat oder die Kollegen 00:08:41.680 --> 00:08:44.880 oder Freunde geschrieben haben, weiß man nicht mehr, wie man die zu benutzen hat. 00:08:44.960 --> 00:08:49.280 Und da sind Tests halt auch ein Mittel der ausführbaren Dokumentation, 00:08:50.320 --> 00:08:54.880 wo man quasi einen Use Case überhaupt mal sieht, 00:08:56.160 --> 00:09:00.080 wie die Dinge zu benutzen sind und wie das erwartete Verhalten ist. 00:09:00.160 --> 00:09:04.080 Und man kann sie ausführen und sieht, aha, dieses Verhalten ist tatsächlich so, 00:09:04.400 --> 00:09:06.320 wie es jetzt hier in den Tests beschrieben ist. 00:09:06.480 --> 00:09:12.240 Also Tests sind halt für Programmierer, finde ich, auch eigentlich das wichtigste Mittel der Dokumentation von 00:09:12.240 --> 00:09:12.720 Software. 00:09:12.880 --> 00:09:15.520 Genau, und oft ist es auch so, gerade bei so Open Source-Geschichten, 00:09:15.600 --> 00:09:20.160 die Leute bauen halt sich die Bibliotheken, aber um dann nachher nochmal irgendwie zwei Stunden hinzusitzen 00:09:20.160 --> 00:09:23.600 und wirklich Doku zu schreiben, fehlt halt entweder die Zeit oder die Lust. 00:09:23.760 --> 00:09:28.080 Und ich mache es oft so, wenn ich bei Bibliotheken, wo nicht großartig viel dabei steht, 00:09:28.240 --> 00:09:31.040 meist schaue ich mir das Zeug irgendwie in Ruby an oder so, schaue ich halt, 00:09:31.120 --> 00:09:37.440 ob es einen Spec oder ein Testverzeichnis gibt, gehe einfach rein und Tests sind ja per se auch hoffentlich so 00:09:37.440 --> 00:09:40.960 die minimalsten Arten, diese Bibliothek zu benutzen. 00:09:41.040 --> 00:09:45.280 Also da wird das Ding komplett initialisiert und dann wird eine Sache gemacht und dann wird überprüft, 00:09:45.360 --> 00:09:47.760 ob da auch daraus rauskommt, was rauskommt, soll und dann warst du. 00:09:48.160 --> 00:09:51.760 Du hast einfach den kompletten Code, um so eine bei einer Bibliothek, 00:09:51.840 --> 00:09:54.880 gerade um die zu benutzen, hast du schon in so einem Test Case drin. 00:09:55.360 --> 00:09:58.000 Bedeutet, wenn dir nicht ganz klar ist, ja, was ist denn der Parameter, 00:09:58.080 --> 00:10:04.560 ist das jetzt ein irgendwie der Pfad zum Zertifikat oder muss ich das Zertifikat da als String 00:10:04.560 --> 00:10:05.440 reingeben? 00:10:05.920 --> 00:10:10.960 Normalerweise wäre das ja Teil von einer Doku oder einer API-Doku, aber das gibt es halt oft auch nicht. 00:10:11.120 --> 00:10:17.040 Und so kannst du mit Tests auch vielen Leuten einfach das reinkommen mit deinen Bibliotheken ein bisschen 00:10:17.040 --> 00:10:19.360 erleichternehmen, die die das Zeug einfach durchlesen und sagen, ah ja, 00:10:19.440 --> 00:10:20.640 okay, so muss ich das benutzen. 00:10:20.800 --> 00:10:22.400 So hat der Autor sich das gedacht. 00:10:23.040 --> 00:10:28.720 Ist, glaube ich, auch für die meisten ein sehr, sehr wichtiges Kriterium für Bibliotheken, 00:10:29.040 --> 00:10:30.800 wenn sie jetzt Open Source-Code benutzen. 00:10:30.960 --> 00:10:33.440 Dass man einfach sagen kann, okay, wenn ich jetzt irgendwie ein Projekt habe, 00:10:33.520 --> 00:10:38.080 ich gehe da auf GitHub drauf, ich gucke mir das Projekt an, wenn es keine Tests hat, 00:10:39.200 --> 00:10:40.800 dann kann ich die Seite gleich wieder zumachen. 00:10:40.880 --> 00:10:46.800 Ansonsten gucke ich mir mal so stichprobenartig so ein paar Tests durch und gucke, 00:10:46.880 --> 00:10:51.360 ob die dann irgendwelche sinnvolle Dinge testen, ob sie es vielleicht auch automatisiert ausführen, 00:10:51.520 --> 00:10:55.520 ob sie da irgendwie einen Continuous Integration Server laufen haben, 00:10:55.600 --> 00:10:58.400 wo man dann die Testruns vielleicht mal angucken kann oder so. 00:10:58.960 --> 00:11:05.520 All das ist eigentlich auch mittlerweile sehr wichtig, wenn man dann Sachen auswählt, 00:11:05.680 --> 00:11:07.520 ob man die jetzt unbedingt benutzen will. 00:11:07.840 --> 00:11:10.960 Das ist so, also für mich persönlich, wenn ich eine Open Source Library benutze, 00:11:11.120 --> 00:11:12.240 auch immer so der zweite Schritt. 00:11:12.320 --> 00:11:15.040 Also ich gucke in der Regel so erstmal so zum Beispiel. 00:11:16.080 --> 00:11:16.880 Natürlich, ja. 00:11:17.520 --> 00:11:21.600 Ne, also das erste, was ich mir an der Regel angucke, ist, wann wurde das letzte Mal Code verändert. 00:11:22.240 --> 00:11:26.240 In gewissen Fällen, also wenn es gerade relativ neues Zeug ist und ich weiß, 00:11:26.400 --> 00:11:28.880 da haben sich in letzter Zeit zum Beispiel an der Spec-Sachen verändert, 00:11:28.960 --> 00:11:30.720 dann sollte die Lib auch relativ aktuell sein. 00:11:30.880 --> 00:11:33.040 Natürlich gibt es auch sehr gut abgehangene Software. 00:11:33.200 --> 00:11:35.760 Aber das zweite, was ich dann mir in der Regel zum Beispiel schon angucke, 00:11:35.840 --> 00:11:40.320 ist, ganz viele Projekte haben dann heute so Builds und Tests passing, 00:11:40.560 --> 00:11:44.800 Greenlights von Travis zum Beispiel, dann ihre GitHub-Seite oben drin ist so die genau, 00:11:44.880 --> 00:11:49.920 das ist so die zweite Hürde sozusagen, wenn eine Bibliothek das nicht hat, 00:11:50.000 --> 00:11:52.560 dann okay, dann kann ich darauf erstmal keine Aussage treffen. 00:11:52.640 --> 00:11:56.560 Aber wenn da zum Beispiel eine rote Lampe ist, ein rotes Badge, dann sage ich einfach, 00:11:56.640 --> 00:12:02.240 okay, Library, die ihre Tests so schon nicht in Griff bekommt, speziell wenn es dann irgendwie noch der 00:12:02.240 --> 00:12:05.120 Masterbranch ist, ja, nicht so gut. 00:12:05.680 --> 00:12:09.440 Für mich persönlich ist Testing im Unternehmen irgendwie vor allem so eine, 00:12:09.520 --> 00:12:12.880 ja, so eine Versicherung, so eine Garantie, also dass ich weiterarbeiten kann. 00:12:13.040 --> 00:12:18.720 Also weil sowohl in meinem früheren Job als auch jetzt ist es so, dass ich sehr oft zum Beispiel deployen 00:12:18.800 --> 00:12:24.960 muss, sehr häufig neue Anforderungen habe und da gehören für mich einfach gewisse Systematiken dazu, 00:12:25.040 --> 00:12:27.920 sodass ich eine Versicherung habe, dass ich schnell arbeiten kann. 00:12:28.560 --> 00:12:32.480 Also ich habe zum Beispiel eben dann eben meine IDE und so weiter, alles meinen Workflow, 00:12:32.640 --> 00:12:34.240 mir persönlich eingerichtet. 00:12:34.560 --> 00:12:38.000 Auf der anderen Seite habe ich zum Beispiel einen sehr stabilen Deployment-Stack. 00:12:38.080 --> 00:12:42.240 Also dass ich mit einem Kommando im Idealfall die komplette Anwendung deployen kann, 00:12:42.320 --> 00:12:46.400 nicht irgendwie pack das ZIP, schieb es per FTP auf den Server und so weiter, 00:12:46.480 --> 00:12:47.840 wie das manche Leute tun. 00:12:48.080 --> 00:12:51.680 Und genau das ist für mich Testing dann auch, dass ich, bevor ich das Ganze mache, 00:12:51.760 --> 00:12:55.200 noch einmal mindestens einmal vorher die Test-Suite durchlaufen lassen kann. 00:12:55.360 --> 00:12:59.600 Und dadurch eine Versicherung habe, okay, ich habe jetzt keine Regression eingebaut oder anderes. 00:12:59.760 --> 00:13:04.160 Also ja, es ist so ein, es gibt mir so ein Peace of Mind im Prinzip, 00:13:04.240 --> 00:13:08.080 dass ich weiß, okay, ich kann weitermachen und ich kann nachts gut schlafen. 00:13:08.160 --> 00:13:12.960 Und was Plydi auch gesagt hat mit dem Faktor Zeit und der Komplexität, 00:13:13.680 --> 00:13:17.120 die Komplexität ist ja einmal genau durch Zeit und durch, sag ich mal, 00:13:17.200 --> 00:13:23.040 ja, Vergessen sozusagen geprägt, aber zum anderen auch, gerade wenn andere Leute an deiner Software beteiligt 00:13:23.040 --> 00:13:28.960 sind, wenn du ein Stück Software hast, das hochverteilt entwickelt worden ist, 00:13:29.040 --> 00:13:29.760 sage ich mal. 00:13:30.080 --> 00:13:35.680 Egal wie gut der Code von denen dokumentiert ist und wie sehr der gewissen Anforderungen gehorcht, 00:13:35.840 --> 00:13:42.080 wie Style Guides oder so, es ist nie dein eigener Code und deshalb wirst du ihn nie ganz so verstehen können 00:13:42.080 --> 00:13:45.120 oder so behalten können und deshalb ist es super, wenn man Tests dafür hat, 00:13:45.280 --> 00:13:49.840 weil das einen gemeinsamen Nenner im Prinzip dafür bildet. 00:13:50.400 --> 00:13:55.040 Also Kunden sind auch ein interessantes Thema, weil letzten Endes ist es ja schon so, 00:13:55.120 --> 00:14:01.360 wenn man dann irgendwie ein Projekt für einen Kunden macht, der Kunde weiß meistens nicht mal selbst, 00:14:01.440 --> 00:14:02.880 was er denn jetzt tatsächlich will. 00:14:02.960 --> 00:14:05.920 Und wenn man dann jetzt irgendwie, sagen wir mal, ein neues Feature implementiert, 00:14:06.080 --> 00:14:10.240 dann gibt es mittlerweile halt auch Möglichkeiten, dass man sagt, okay, 00:14:10.960 --> 00:14:17.440 in so einer Art sehr restriktiven Prosa-geschriebene Testspezifikation an den Kunden 00:14:18.480 --> 00:14:21.280 auszuliefern, die man aber tatsächlich ausführen kann. 00:14:21.680 --> 00:14:27.280 Und dem Kunden dann mal die Frage zu stellen, hey, ist das so ungefähr, wie du dir das Feature vorstellst? 00:14:27.360 --> 00:14:32.320 Und das kann man sich dann irgend im Endeffekt so vorstellen, so ich bin ein User und ich öffne jetzt die 00:14:32.320 --> 00:14:39.200 Seite und ich klicke jetzt auf Login und ich tippe jetzt in mein Benutzerfeld ein und irgendwas in 00:14:39.200 --> 00:14:42.240 mein Passwort und dann klicke ich auf Login und dann sollte ich eingeloggt sein. 00:14:42.640 --> 00:14:45.600 So kann man sich ein einfaches Feature vorstellen. 00:14:45.680 --> 00:14:48.000 Da gibt es ein paar Frameworks, die sowas anbieten. 00:14:48.080 --> 00:14:53.840 Also das Bekannteste, was mir jetzt gerade oder mit dem ich bereits gearbeitet habe, ist jetzt Cucumber. 00:14:55.760 --> 00:14:59.120 Und das wäre dann im Endeffekt auch so eine Art, dass man sagen kann, 00:14:59.200 --> 00:15:03.600 okay, das ist jetzt auch so ein bisschen eine Versicherung für den Entwickler selber gegenüber dem Kunden, 00:15:03.680 --> 00:15:07.200 weil der Kunde ja quasi diesen Test Case abgesegnet hat und man sagt, 00:15:07.280 --> 00:15:09.760 okay, ich implementiere das jetzt so, dass dieser Test Case durchläuft. 00:15:10.000 --> 00:15:15.520 Du kannst es, genau, also der Name Kunde ist ja auch ein bisschen vielleicht für manche Leute irreführend. 00:15:15.680 --> 00:15:20.160 Viele sehen darin zum Beispiel jetzt in meiner Rolle eben einen Kunden im Sinne von ein anderes Unternehmen, 00:15:20.320 --> 00:15:21.440 das mich beauftragt hat. 00:15:21.600 --> 00:15:27.440 Kunde kann ja aber auch zum Beispiel gerade im agilen Projektmanagement dein Produktmanager oder 00:15:28.880 --> 00:15:31.680 dein Project Owner in Scrum zum Beispiel sein. 00:15:31.920 --> 00:15:35.040 Und das ist natürlich eine super Möglichkeit, genau, wenn der auf dem ähnlichen, 00:15:35.120 --> 00:15:40.480 also wenn der ein ähnliches Sachverständnis hat, dass er mit dir zusammen dann zum Beispiel mal da sitzen kann 00:15:40.480 --> 00:15:45.440 und die Test Cases vorformuliert und dann musst du nur noch dagegen implementieren. 00:15:45.840 --> 00:15:50.240 Dann ist es genau, wie der FlyDy gesagt hat, eine sehr gute Versicherung deinem Kunden gegenüber. 00:15:51.680 --> 00:15:58.000 Und auch generell, also wenn man auch wirklich Testen in den Entwicklungsprozess übernimmt, 00:15:58.160 --> 00:16:00.400 fällt am Ende normalerweise auch Code raus. 00:16:00.480 --> 00:16:04.000 Sobald dein Code testbar ist, bedeutet es, dass er so abstrahiert ist, 00:16:04.160 --> 00:16:09.760 dass er hoffentlich auch nicht so das komplette Produktionssystem braucht, 00:16:10.160 --> 00:16:11.360 um durchzulaufen. 00:16:11.440 --> 00:16:17.280 Bedeutet, du hast alle Klassen, die, wo quasi kommuniziert wird, also deine API normalerweise, 00:16:17.520 --> 00:16:22.960 so abstrakt gehalten, dass du dann, wenn es hard auf hart kommt, auch mal Teile von deinem System austauschen 00:16:22.960 --> 00:16:23.280 kannst. 00:16:23.440 --> 00:16:28.160 Was man bei so Architekturgeschichten immer sagt, so loosely coupled. 00:16:28.720 --> 00:16:33.600 Im Endeffekt ist es, Code, der nicht getestet ist, ist selten, also habe ich selten gesehen, 00:16:33.680 --> 00:16:38.000 dass der wirklich dann auch so gut in der Architektur ist, 00:16:38.080 --> 00:16:40.320 dass man da wirklich Sachen einfach rausmachen könnte. 00:16:40.400 --> 00:16:44.480 Weil wenn du testest, musst du eben teilweise einfach sagen, ja, gut, 00:16:44.560 --> 00:16:47.440 ich habe den Oracle-Hobel jetzt nicht da hinten irgendwo stehen. 00:16:47.680 --> 00:16:51.520 Bedeutet, wenn du dann irgendwie deine Oracle-Datenbanktreiber aufrufst und da irgendwelche Sachen drauf 00:16:51.520 --> 00:16:53.360 machst, dann läuft dein Test einfach nicht. 00:16:53.600 --> 00:16:58.560 Aber wenn du deine Datenbank eventuell in einem Persistenzobjekt oder so verteilt hast, 00:16:58.720 --> 00:17:00.720 irgendwo machst dann Schaltern rum. 00:17:00.960 --> 00:17:02.880 Ich bin leiser aus so einem Grund jetzt. 00:17:03.920 --> 00:17:08.800 Genau, wenn du das irgendwie in ein Persistenzobjekt reingetan hast oder dann wirklich so einen, 00:17:08.880 --> 00:17:14.560 keine Ahnung, objektrelationalen Mapper benutzt und da hinten einfach die Datenbank austauschen kannst, 00:17:14.720 --> 00:17:16.560 das ist dann halt auch Code, der testbar ist. 00:17:16.640 --> 00:17:21.600 Und gerade wenn man zu Projekten kommt, die schon eine Weile laufen und da erstmal Tests reinbringen will, 00:17:21.760 --> 00:17:24.880 dann merkst du erstmal, denkst du so, ja klar, okay, weil ich einen kleinen Test, 00:17:25.040 --> 00:17:29.440 fängst du an zu schreiben und so, ah fuck hier, Datenbank muss ich jetzt auch noch mit übergeben, 00:17:29.520 --> 00:17:32.080 dass ich danach irgendwie meine Fake-Datenbank reinstecken kann. 00:17:32.160 --> 00:17:35.120 Und dann musst du auf einmal anfangen, die komplette API intern zu verändern, 00:17:35.200 --> 00:17:39.920 weil die alle auf irgendwelche globalen Variablen zugreifen oder solche Spielereien. 00:17:40.000 --> 00:17:45.520 Und da hilft Testen eben auch einfach, dass es Leute zwingt, so sauber zu abstrahieren, 00:17:45.760 --> 00:17:48.960 dass einfach ein Test überhaupt möglich sein wird. 00:17:50.160 --> 00:17:56.160 Genau, also du hast am Anfang hast du ja so mehr oder weniger dann zum Beispiel Spaghetti-Gode und das willst 00:17:56.160 --> 00:17:57.120 du einfach nicht haben. 00:17:57.440 --> 00:18:00.960 Aber die nächste Stufe ist genau dieses Loosely Couple, so dass man sagt, 00:18:01.040 --> 00:18:03.600 okay, ich habe halt nur noch Module, die ich miteinander verbinde. 00:18:03.920 --> 00:18:07.920 Und testen zwingt dich, wie wir jetzt schon gehört haben, du willst ja in dem Test, 00:18:08.000 --> 00:18:11.840 das möglichst einfach, also du möchtest den Test möglichst schnell und einfach schreiben können, 00:18:12.000 --> 00:18:15.600 zwingt dich dann im Prinzip genau auch die API, die Schnittstelle zu dem Code, 00:18:15.680 --> 00:18:19.200 den du testest, möglichst einfach zu halten. 00:18:20.480 --> 00:18:26.160 Damit du den Test A einfach schreiben kannst und B zum Beispiel auch entsprechend merkst du auf einmal die 00:18:26.160 --> 00:18:29.600 verschiedenen Aspekte, wie Market gerade zum Beispiel Datenhaltung, 00:18:29.680 --> 00:18:31.040 also Persistenz genannt hat. 00:18:31.200 --> 00:18:33.840 Wenn ich jetzt hier nur einen Controller irgendwie teste und einfach nur wissen will, 00:18:33.920 --> 00:18:36.560 kommt das Richtige danach raus, dann sollte ich eigentlich nicht prüfen, 00:18:36.720 --> 00:18:41.760 wird das in der Datenbank abgelegt an der und der Stelle, weil das kann ja im Live-System zum Beispiel ganz 00:18:41.760 --> 00:18:42.480 anders sein. 00:18:42.640 --> 00:18:47.280 Sondern ich möchte einfach nur testen, kommt das an der richtigen Stelle raus und schon muss ich mich 00:18:47.280 --> 00:18:52.160 automatisch mehr dahin bewegen, ja, die Schnittstellen besser zu definieren. 00:18:52.400 --> 00:18:55.120 Also besser im Sinne von einfacher und offener. 00:18:56.640 --> 00:19:00.720 Ja, da wollte ich noch was anfügen, und zwar das, was ihr gerade beschrieben habt, 00:19:00.880 --> 00:19:06.000 das gilt meiner Meinung eigentlich nur für Unit und zum Teil für Integration-Tests. 00:19:06.160 --> 00:19:10.800 Wenn man jetzt sagt, okay, man hat sowas wie einen Blackbox-Test, der eine Anwendung aus der Sicht von einem 00:19:10.800 --> 00:19:15.520 Benutzer testet, dann ist es eigentlich relativ egal, wie der Code intern strukturiert ist. 00:19:15.600 --> 00:19:20.960 Also es müssen schon Tests sein, die quasi die interne API oder irgendwelche Klassen oder Methoden, 00:19:21.040 --> 00:19:24.240 die man intern geschrieben hat, die die selber benutzen. 00:19:24.320 --> 00:19:30.960 Und in dem Fall ist es ja quasi so, ein Test ist halt eine Wiederverwendung von 00:19:30.960 --> 00:19:32.080 bestehend Code. 00:19:32.320 --> 00:19:37.280 Wenn dein Code jetzt aber so zusammengefrickelt ist, dass der nur in sich selbst funktioniert, 00:19:37.440 --> 00:19:40.720 aber nicht wiederverwendbar ist, dann ist der halt auch schlecht testbar. 00:19:41.680 --> 00:19:42.160 Somit. 00:19:42.970 --> 00:19:49.050 Ist halt in den allermeisten Fällen gut testbarer Code auch sehr viel besser strukturiert, 00:19:49.130 --> 00:19:50.810 sehr viel wiederverwendbarer. 00:19:51.850 --> 00:19:56.650 Und versucht nach Möglichkeit auch Abhängigkeiten, 00:19:57.130 --> 00:20:00.810 also Dependency Injection ist da das Buzzword dazu. 00:20:00.890 --> 00:20:05.690 Also man versucht irgendwie Abhängigkeiten auch aus seinen eigenen Units, 00:20:05.930 --> 00:20:10.250 die man testet, rauszulassen, weil alles, was sich da irgendwann ändert, 00:20:10.490 --> 00:20:14.330 wird dann die Tests wiederbrechen und das will man halt im Endeffekt auch nicht, 00:20:14.410 --> 00:20:17.610 weil oft ist es halt, also oft ist es halt auch so. 00:20:17.770 --> 00:20:20.970 Ich habe schon Geschichten mitbekommen, dass Leute gesagt haben, ja okay, 00:20:21.050 --> 00:20:24.250 sie probieren jetzt ein paar Wochen mal Testgetrieben zu entwickeln und merken dann, 00:20:24.410 --> 00:20:30.490 oh, irgendwie, das funktioniert alles ja gar nicht, ich brauche viel zu viel Zeit für meine Tests und das 00:20:30.490 --> 00:20:36.730 kostet mich alles unglaublich viel Zeit und irgendwie auch Aufmerksamkeit, 00:20:36.810 --> 00:20:40.730 diese ganzen Tests zu pflegen, weil die ständig kaputt gehen und dann ist halt auch die Frage, 00:20:40.810 --> 00:20:42.250 ob das dann wirklich gute Tests sind. 00:20:42.330 --> 00:20:45.850 Und das musste ich halt auch erst selber mal lernen, dass man, so wie man lernen muss, 00:20:46.010 --> 00:20:50.810 Code zu strukturieren und irgendwie guten Produktionscode zu schreiben, 00:20:50.970 --> 00:20:52.810 so muss man halt auch lernen, gute Tests zu schreiben. 00:20:53.050 --> 00:20:57.690 Genau, also du optimierst, müssen wir, muss ich genauso korrigieren oder generalisieren, 00:20:57.770 --> 00:21:01.930 du optimierst nicht unbedingt deinen Code unbedingt, sondern du optimierst immer die Schnittstelle, 00:21:02.010 --> 00:21:03.130 die du zu deinem Test hast. 00:21:03.210 --> 00:21:08.970 Also wenn du jetzt zum Beispiel einen UI-Test mit einem entsprechenden Framework wie Cucumber oder so baust, 00:21:09.210 --> 00:21:14.410 dann optimierst du das, was du hast, dahingehend, dass es auf dieser Ebene einfach geht. 00:21:15.210 --> 00:21:19.370 Und die klassische Vorgehensweise, so wie ich es persönlich kenne, ist halt eben die, 00:21:19.610 --> 00:21:23.130 dass man, also kommt man nachher noch drauf, vielleicht mit Legacy und so, 00:21:23.210 --> 00:21:25.290 das dann testbar zu machen, ist schwierig. 00:21:26.010 --> 00:21:31.290 Deshalb, wenn ich gleich anfange, zum Beispiel Test-Driven zu entwickeln oder gleich am Anfang meine Tests mit 00:21:31.290 --> 00:21:34.410 rein habe, dann fange ich in der Regel eben auf der kleinsten Einheit an, 00:21:34.490 --> 00:21:36.730 weil ich ja, weil ich ja nichts Größeres auch habe. 00:21:36.970 --> 00:21:40.810 Und dann fange ich eben mit Unit-Tests an und dann schreibe ich den Code automatisch so. 00:21:41.050 --> 00:21:44.570 Und das andere ist, in meiner Erfahrung zum Beispiel häufig so ein, 00:21:44.810 --> 00:21:50.010 nee, wir müssen jetzt irgendwie Tests schreiben und der Code, gerade so die Module drunter sind so eng 00:21:50.010 --> 00:21:54.170 verworren, dass es nicht testbar ist, dass ich so viel mocken muss, 00:21:55.450 --> 00:21:58.730 dass es einfach irgendwie auch der Test in dem Falle keinen Sinn mehr macht, 00:21:59.050 --> 00:22:04.570 dass ich dann im Prinzip so als Last Resort auf sowas wie, okay, dann teste ich halt das komplette Frontend 00:22:04.730 --> 00:22:09.690 mit einem entsprechenden Tool und teste, dass ich da vorne die entsprechenden Daten ins Frontend reinhacke. 00:22:10.090 --> 00:22:16.410 Können wir mal ganz kurz, weil ihr redet die ganze Zeit schon über Unit-Tests und Integration-Tests und können 00:22:16.410 --> 00:22:22.170 wir das mal ganz kurz klären, was eigentlich was ist, was ich mit welchem Test erreichen kann? 00:22:22.410 --> 00:22:27.530 Und man muss vielleicht generell sagen zu den ganzen, also wir sagen ja jetzt ein paar Namen, die gängig sind. 00:22:27.610 --> 00:22:30.890 Ich glaube, für jeden von diesen Dingen gibt es irgendwie drei unterschiedliche Namen, 00:22:31.050 --> 00:22:33.050 die vielleicht ein bisschen anders sind. 00:22:33.610 --> 00:22:36.810 Ich glaube, Unit-Test ist schon relativ eindeutig, aber so. 00:22:37.290 --> 00:22:38.410 Sobald es größer wird, heißt dann. 00:22:38.970 --> 00:22:41.610 Sobald es größer wird, da ist es halt dann auch eine Definitionsfrage. 00:22:41.690 --> 00:22:45.530 Also wir nennen jetzt halt einfach mal die Definitionen, die uns so am gängigsten vorkommen, 00:22:45.690 --> 00:22:47.770 aber da gibt es mit Sicherheit auch noch Synonyme. 00:22:48.010 --> 00:22:50.090 Also ich fange halt direkt auch mal mit den Unitests an. 00:22:50.250 --> 00:22:56.250 Du hast ja schon so schön gesagt, am Anfang hat man nur die kleinen Einheiten und Einheit ist ja Unit und das 00:22:56.490 --> 00:22:58.650 sind Unit-Tests normalerweise auch. 00:22:58.810 --> 00:23:05.290 Die testen wirklich entweder deine Methoden selber, die Teil deiner API sind, 00:23:05.690 --> 00:23:08.730 oder halt irgendwie die komplette Klasse als solche. 00:23:09.210 --> 00:23:14.970 Testen also quasi Schnittstellen, die dein Code für anderen Code bereitstellt. 00:23:15.050 --> 00:23:15.770 Genau, würde ich sagen. 00:23:16.250 --> 00:23:18.330 Wichtig daran ist halt in Isolation. 00:23:18.410 --> 00:23:25.370 Das heißt, ein Unit-Test muss laufen können, wenn dein Testsystem nur eine einzige Klasse zur 00:23:25.370 --> 00:23:29.370 Verfügung hat, ohne dass irgendwie Abhängigkeiten zu anderen Klassen bestehen. 00:23:29.690 --> 00:23:30.170 Genau, und das. 00:23:31.050 --> 00:23:33.850 Oft ist halt ein Problem, dass dann irgendwie in deiner Klasse, ich meine, 00:23:34.090 --> 00:23:39.850 eine Klasse an und für sich ist ja, also hat man manchmal, aber oft braucht die halt auch noch irgendwie 00:23:39.850 --> 00:23:44.090 Klassen von außen, wenn du zum Beispiel Logging in deine Anwendung machst, 00:23:44.250 --> 00:23:48.410 dann würdest du nicht in deiner Klasse automatisch auch den Logger rein implementieren, 00:23:48.490 --> 00:23:50.730 sondern der Logger kommt irgendwo von außen rein. 00:23:51.130 --> 00:23:55.850 Und da ist halt das Problem, wo wir auch vorher gesagt haben, wie Code organisiert ist, 00:23:56.090 --> 00:24:00.890 ist der Logger irgendwie so ein komisches Objekt, das irgendwo aus dem Nichts herkommt, 00:24:01.050 --> 00:24:05.530 wird der Logger vielleicht beim Initialisieren mit übergeben, kann ich dann anderen mit reintun. 00:24:06.330 --> 00:24:11.530 Und da denke ich, ist auch, also Unitests sind eine der 00:24:13.450 --> 00:24:18.330 Sachen, die, denke ich, persönlich am meisten Auswirkungen auf deinen Code im Endeffekt haben, 00:24:18.410 --> 00:24:25.370 weil sie halt die von der Initialisierung deiner Klasse bis zum Aufruf komplett alle Parameter in 00:24:25.370 --> 00:24:26.730 einen einzigen Test stecken. 00:24:27.050 --> 00:24:32.970 Bedeutet, wenn es dann wirklich so globalen State gibt, 00:24:33.050 --> 00:24:38.570 wie zum Beispiel eine irgendwo ein Datenbank-Connection-Pool oder einen Logger oder sowas in der Art, 00:24:38.810 --> 00:24:40.570 das muss deinen Test halt irgendwie bereitstellen. 00:24:40.730 --> 00:24:45.610 Und wenn du merkst, dass du irgendwie 28 Mocks da drin hast, und Mocs kommen mir später noch dazu, 00:24:45.690 --> 00:24:48.650 was das sind, die halt quasi so tun, als wären sie irgendwas, irgendeine Klasse, 00:24:48.730 --> 00:24:53.530 aber eigentlich gar nichts machen, dann ist das ein bisschen ein Problem. 00:24:54.570 --> 00:24:57.370 Ich glaube, was wir noch ansprechen sollten, ist, dass wir größtenteils, 00:24:57.450 --> 00:25:02.970 wenn wir hier von Testing und von Unit-Tests und so weiter reden, reden wir von Testing in objektorientierten 00:25:02.970 --> 00:25:03.850 Programmiersprachen. 00:25:04.010 --> 00:25:06.810 Es gibt mit Sicherheit Programmierparadigmen, da sieht es ein bisschen anders aus, 00:25:06.890 --> 00:25:11.130 da wären Unit jetzt in einer funktionalen Programmiersprache, wäre eine Unit halt im Endeffekt eine Funktion 00:25:11.130 --> 00:25:11.450 dann. 00:25:13.450 --> 00:25:16.330 Nur um das mal kurz noch anzureißen, das ist ja halt auch. 00:25:17.770 --> 00:25:20.170 Aber natürlich kann es genau andere Dinge geben. 00:25:20.410 --> 00:25:26.570 Ja, also ich benutze Testing, dadurch, dass ich ja relativ viel mit so komischen 00:25:26.650 --> 00:25:32.090 Fricky-Zeugs zu tun habe, mit so Shell und mit dem ganzen alten Zeugs, 00:25:32.330 --> 00:25:37.210 habe ich da auch, ist es bei mir wirklich nicht so, dass es unbedingt objektorientiert alles ist. 00:25:37.370 --> 00:25:38.810 Und deswegen teste ich auch anders. 00:25:38.890 --> 00:25:40.410 Also da komme ich dann auch später zu. 00:25:42.090 --> 00:25:45.850 Bei mir sind es weniger so Unit-Tests, sondern wirklich, du probierst aus, 00:25:46.010 --> 00:25:47.690 ob das ganze Ding überhaupt noch tut. 00:25:48.170 --> 00:25:52.330 Und dann kommt ein Error-Code raus oder nicht und dann ist es quasi schon gut. 00:25:52.810 --> 00:25:55.610 Sowas wäre dann zum Beispiel ein Acceptance-Test. 00:25:55.850 --> 00:25:58.010 Ein Acceptance-Test oder vielleicht ein Integration-Test. 00:25:58.410 --> 00:25:59.370 Oder End-to-End-Test. 00:25:59.610 --> 00:26:01.290 Ja, genau, da gibt es halt viele Worte. 00:26:01.370 --> 00:26:06.410 Aber Acceptance-Test normalerweise ist halt dafür da, um so, 00:26:06.890 --> 00:26:09.450 normalerweise hast du ja in so einem Programm eine User-Story. 00:26:09.530 --> 00:26:14.010 Also bevor du ein Feature implementierst, du implementierst ja nicht normalerweise so einfach vor dich hin, 00:26:14.090 --> 00:26:14.890 weil es dir Spaß macht. 00:26:14.970 --> 00:26:18.650 Also natürlich machst du das, aber eigentlich, sag mal, beides, ja. 00:26:19.050 --> 00:26:23.290 Wenn du für eine Firma arbeitest, die da irgendwie Geld mit verdienen will und da irgendwie viele Leute drin 00:26:23.290 --> 00:26:25.690 sind, dann macht man das normalerweise nicht, weil dann fragen die Leute, 00:26:25.770 --> 00:26:28.010 was machst du und dann sagst du, ich mache ja so, ganz lustig. 00:26:28.250 --> 00:26:28.810 Und dann sagen die. 00:26:30.410 --> 00:26:35.610 Aber hier der Chef hat gesagt, die Benutzer sollen jetzt Bilder hochladen können in unserer App. 00:26:35.770 --> 00:26:38.650 Also, keine Ahnung, bist du irgendwie Instagram oder so. 00:26:38.890 --> 00:26:43.770 Und dann bekommst du halt den Auftrag, hey, die Benutzer sollen jetzt Bilder hochladen können. 00:26:43.930 --> 00:26:49.130 Und normalerweise ist der Auftrag ein bisschen detaillierter und wird in so einer User-Story festgehalten, 00:26:49.210 --> 00:26:54.330 wo dann drin steht, also der User soll, wenn er die App öffnet, rechts unten einen Button haben, 00:26:54.410 --> 00:26:55.690 wo drauf steht Bilder hochladen. 00:26:55.770 --> 00:26:58.250 Und wenn der da draufklickt, soll er ein Foto machen können. 00:26:58.810 --> 00:27:01.050 Und dann soll der einen Button klicken, ist okay. 00:27:01.130 --> 00:27:07.770 Und dann soll das nachher auf seinem, in seinem Foto-Album verfügbar sein und der soll er mit Sachen machen 00:27:07.770 --> 00:27:08.010 können. 00:27:08.330 --> 00:27:13.130 Das ist so eine User-Story, also die wirklich fast schon Knopfdruck für Knopfdruck durchgeht. 00:27:13.370 --> 00:27:16.330 Muss jetzt nicht ganz so genau sein, aber vom Prinzip her. 00:27:17.850 --> 00:27:24.730 Und da ist dann so ein Acceptance-Test für da, um sicherzustellen, dass der Endbenutzer das Resultat dann auch 00:27:24.730 --> 00:27:28.810 noch quasi akzeptiert, was da rauskommt, dass er dann sagt, ja, so habe ich mir das vorgestellt. 00:27:29.130 --> 00:27:32.010 Und das wäre dann zum Beispiel, was Felix wahrscheinlich gesagt hat, 00:27:32.410 --> 00:27:38.250 so eine Sache wie, ja, ich pipe da was rein und dann soll da am Ende eine Datei auf der Festplatte sein und da 00:27:38.250 --> 00:27:39.930 soll ein Exit-Code null rauskommen. 00:27:40.330 --> 00:27:45.690 Und also wenn der die Datei überprüft, dann ist es wahrscheinlich fast schon ein Acceptance-Test. 00:27:45.770 --> 00:27:51.450 Ansonsten könnte das auch irgendwie, keine Ahnung, ein bisschen mehr Richtung Integration-Test gehen. 00:27:51.610 --> 00:27:55.370 Was würdet ihr denn sagen, was so der Unterschied zwischen Acceptance und Integration-Test ist? 00:27:55.610 --> 00:28:00.010 Also ich würde sagen, einen Integration-Test, 00:28:00.250 --> 00:28:05.370 wie der Name es schon sagt, der versucht dann einzelne Units in Integration miteinander zu testen. 00:28:05.530 --> 00:28:10.250 Das kann jetzt auf einem Spektrum passieren, dass man sagt, okay, ich möchte nur mal zwei, 00:28:10.330 --> 00:28:14.010 drei Klassen in Kombination zueinander testen. 00:28:15.290 --> 00:28:21.690 Tu aber zum Beispiel mal sowas wie die Datenbank aus dem Spiel lassen oder das letzten Endes das Frontend, 00:28:21.770 --> 00:28:22.490 was davor ist. 00:28:22.650 --> 00:28:27.290 Oder man sagt, okay, es gibt dann ja auch so Geschichten wie, jetzt kommen wir vielleicht später nochmal dazu, 00:28:27.450 --> 00:28:33.610 Rack-Test, dass man sagt, okay, jetzt wenn man, man hat irgendwie eine HTTP-Middleware und dann fährt man 00:28:33.610 --> 00:28:40.250 quasi Requests gegen seine API, die man da gebaut hat oder seine Applikation und 00:28:40.250 --> 00:28:45.210 verifiziert da auf einem Request-Response-Prinzip Dinge. 00:28:45.610 --> 00:28:51.530 Das kann sogar dann letzten Endes dann bis zum Persistenzlay, also bis zu einer Datenbank oder was man auch 00:28:51.530 --> 00:28:58.010 sonst da hat, mit durchgehen, aber man lässt zum Beispiel den kompletten Application-Server und das 00:28:58.010 --> 00:29:02.650 komplette sonstige Infrastruktur aus dem Frontend zum Beispiel weg. 00:29:03.610 --> 00:29:09.130 Also das geht schon auf einem Spektrum und ich würde halt sagen, wenn man dann irgendwann mal bei der letzten 00:29:09.130 --> 00:29:16.090 Ausbaustufe ist, wo man von vorne bis hinten die Applikation quasi einer Testumgebung, 00:29:16.170 --> 00:29:22.890 also Staging nennt man sowas normalerweise dann, wenn man sowas dann in einer Staging-Umgebung testet 00:29:24.090 --> 00:29:29.290 und man die Applikation bedient, wie es jetzt ein normaler Benutzer tun würde, 00:29:29.370 --> 00:29:34.890 also man steuert jetzt tatsächlich einen Browser zum Beispiel oder man bedient jetzt irgendwie ein UI von 00:29:34.890 --> 00:29:38.090 einer Mobile App oder sowas, dann würde ich jetzt sagen, es ist ein Acceptance-Test. 00:29:38.330 --> 00:29:44.890 Also quasi ist der Integration-Test technisch gesehen quasi ein Subset von dem 00:29:44.890 --> 00:29:45.770 Acceptance-Test. 00:29:45.930 --> 00:29:50.890 Also wenn du den Integration-Test quasi so weit aufziehst, dass dein Eingangspunkt der Benutzer ist und dein 00:29:50.890 --> 00:29:55.450 Ausgangspunkt auch wieder der Benutzer, dann hast du aus dem Integration-Test quasi einen Acceptance-Test 00:29:55.450 --> 00:29:55.690 gemacht. 00:29:55.930 --> 00:29:56.570 Würde ich so sehen. 00:29:56.890 --> 00:30:00.170 Also das ist wahrscheinlich eine Definitionsfrage, aber so habe ich es verstanden. 00:30:00.250 --> 00:30:03.290 Genau, also von der von der praktischen Erfahrung her teile ich das auch, 00:30:03.370 --> 00:30:07.770 dass ein Acceptance-Test im Prinzip, sage ich mal, ein Spezialfall von einem Integration-Test ist, 00:30:07.850 --> 00:30:10.650 nämlich der, ich teste alle Integrations zusammen. 00:30:10.730 --> 00:30:16.650 Also so bildlich gesprochen im Unit-Test teste ich den Motor von meinem Auto, 00:30:16.730 --> 00:30:20.890 dass wenn da die Zylinder entsprechende Bewegungen machen, dass die Kurbelwelle sich dreht. 00:30:21.050 --> 00:30:25.610 Und ich teste das Getriebe, dass wenn ich da irgendwie am Eingang irgendwie die und die Drehzahl anlege und 00:30:25.610 --> 00:30:29.050 den in den Gang eingelegt habe, hinten die Enddrehzahl rauskommt. 00:30:29.290 --> 00:30:33.850 Ein Integration-Test wäre nun, ich befeuere den Motor und teste, 00:30:34.010 --> 00:30:37.050 dass hinten nach dem Getriebe die richtige Drehzahl rauskommt. 00:30:37.130 --> 00:30:40.330 Und ein Acceptance-Test wäre, ich kombiniere das noch mit Fahrwerk, 00:30:40.410 --> 00:30:44.090 Lenkung und so weiter, habe das komplette Fahrzeug, setzt den Kunden rein und sage, 00:30:44.250 --> 00:30:44.970 fahr mal. 00:30:45.290 --> 00:30:49.210 Genau, oder du setzt in dem Fall vielleicht einen Dummy rein oder einen Roboter, der das Auto steuert. 00:30:50.650 --> 00:30:51.370 Genug zum Risiko. 00:30:51.610 --> 00:30:54.810 Also könnte man vielleicht schon, sagen wir mal, ein Acceptance-Test wäre jetzt, 00:30:55.050 --> 00:30:57.850 du setzt ein Dummy in dein Auto und du fährst es gegen die Wand und guckst, 00:30:57.930 --> 00:30:58.330 was passiert. 00:30:58.410 --> 00:30:59.290 Das wäre vielleicht, könnte man. 00:31:00.890 --> 00:31:05.130 Das hängt halt, das hängt halt von dem ab, wie du zu einem Kunden stehst, wie du einen Acceptance-Test hast. 00:31:06.650 --> 00:31:10.010 Das Schöne ist auch so ein Acceptance-Test ist auch so der, ich sag mal, 00:31:10.170 --> 00:31:14.170 die Krücke unter den Tests, weil selbst wenn du eine komplett ungetestete Codebase hast, 00:31:14.410 --> 00:31:19.210 ist das eins der Sachen, wo du das, also solange das Deployment funktioniert zumindest, 00:31:19.450 --> 00:31:22.730 was du am einfachsten machen kannst, weil du, dann musst du keinerlei Ahnung haben, 00:31:22.810 --> 00:31:27.290 wie das Ding eigentlich intern aussieht, sondern du sagst einfach, gebe ich hier fünf ein und klick den 00:31:27.290 --> 00:31:28.970 Button, sollte da einen neuen rauskommen. 00:31:29.130 --> 00:31:34.890 Und was im Hintergrund passiert, ob das jetzt irgendwie über eine Soap-API an das an BND geht und der da 00:31:34.890 --> 00:31:37.450 irgendwelche Sachen macht und mir was zurückschickt, völlig egal. 00:31:37.930 --> 00:31:39.850 Klick, klack, fertig testen. 00:31:40.010 --> 00:31:44.810 Und das ist so, um auch so Testskelette für bestehende Anwendungen aufzubauen. 00:31:44.890 --> 00:31:50.330 Ist das eine eigentlich ganz angenehme Sache, das dann auch schon Richtung Blackbox-Testing geht, 00:31:50.410 --> 00:31:53.770 weil dir ist völlig egal, wie das aussieht, wenn das Deployment funktioniert. 00:31:53.850 --> 00:31:56.010 Wenn es nicht funktioniert, dann hast du wirklich Pech. 00:31:56.170 --> 00:31:58.650 Dann musst du das erstmal richten. 00:32:01.530 --> 00:32:08.410 Ja, ich glaube, was vielleicht auch ganz gut wäre, bevor wir da noch weiter drüber reden oder uns zu 00:32:08.410 --> 00:32:14.010 anderen, uns anderen Testarten widmen, wäre nochmal so die Trade-offs dieser einzelnen Testarten zu 00:32:14.010 --> 00:32:14.330 besprechen. 00:32:14.410 --> 00:32:15.690 Weil das finde ich immer ganz interessant. 00:32:15.770 --> 00:32:19.370 Man hatte halt jetzt, wir haben jetzt zum Beispiel gelernt, so eigentlich sind diejenigen, 00:32:19.450 --> 00:32:24.090 die Tests, die am einfachsten zu implementieren sind, sind eigentlich Acceptance-Tests. 00:32:24.170 --> 00:32:28.410 Weil da testet man so eine Applikation, spielt da User, 00:32:28.570 --> 00:32:32.170 es ist total egal, wie schlecht dein Code tatsächlich ist. 00:32:32.810 --> 00:32:36.890 Hauptsache, du testest überhaupt irgendwas, ist ja schon mal besser als nichts. 00:32:37.370 --> 00:32:40.410 Der User drückt drauf, es dauert fünf Sekunden und dann kommt was. 00:32:41.770 --> 00:32:43.930 Fünf Sekunden ist schon ein gutes Stichwort. 00:32:44.090 --> 00:32:49.930 Acceptance-Tests sind ihrer Natur wegen, weil sie die komplette Anwendung von vorne bis hinten durchtesten 00:32:49.930 --> 00:32:51.290 müssen, sind sehr langsam. 00:32:51.770 --> 00:32:53.850 Das hat natürlich das Problem, wenn du da. 00:32:54.650 --> 00:32:58.010 Das kostet Zeit, das kostet Rechenleistung, die Tests auszuführen. 00:32:58.170 --> 00:33:02.730 Wenn die Tests irgendwann mal zu lang dauern, dann wirst du die nicht mehr auf deinem lokalen Rechner 00:33:02.730 --> 00:33:03.530 ausführen. 00:33:04.170 --> 00:33:07.850 Beim Entwickeln, wenn du jetzt ein neues Feature implementiert hast, 00:33:08.170 --> 00:33:10.650 weil du sonst anfängst zu prokrastinieren. 00:33:10.730 --> 00:33:15.050 Weil wenn dein Test jetzt irgendwie eine halbe Stunde läuft, dann kannst du auch irgendwie den Kaffee holen, 00:33:15.290 --> 00:33:20.570 irgendwie anfangen, ein Buch zu lesen oder im Internet surfen und dann hast du schon wieder deinen kompletten 00:33:20.570 --> 00:33:22.410 Kontext beim Entwickeln verloren. 00:33:22.490 --> 00:33:23.770 Das macht halt auch irgendwie keinen Sinn. 00:33:24.010 --> 00:33:28.410 Das Problem ist ja auch, dass sie nicht nur per se langsam sind, weil sie als komplette System testen, 00:33:28.570 --> 00:33:33.130 sondern dass auch was Parallelisierbarkeit angeht, du kriegst die auch oft nicht viel schneller. 00:33:33.290 --> 00:33:37.530 Ein Unit-Test, weil der ja theoretisch so komplett eingekapselt ist, 00:33:37.770 --> 00:33:40.250 da kannst du einfach all deine Klassen parallel testen. 00:33:40.330 --> 00:33:42.170 Dann testest halt acht Klassen gleichzeitig. 00:33:42.330 --> 00:33:46.250 Wenn du das bei deinem System machst und du testest halt ja, keine Ahnung, 00:33:46.330 --> 00:33:50.970 da hast du ein blödes Blog oder sowas in der Art und sagst, ja, der Benutzer soll irgendwie einen Beitrag 00:33:50.970 --> 00:33:54.810 schreiben können und der Benutzer soll einen Kommentar anlegen können und der Benutzer soll ein Bild hochladen 00:33:54.970 --> 00:33:57.370 und der Benutzer soll einen Beitrag mit dem Bild schreiben können. 00:33:57.450 --> 00:34:01.130 Wenn du die alle parallel machst, dann kann es auf einmal sein, dass dein einer Test halt sagt, 00:34:01.210 --> 00:34:06.330 klar, lädst ein Bild hoch, schaust dann, was da, keine Ahnung, als erster Eintrag in deiner Liste steht, 00:34:06.410 --> 00:34:08.730 da soll dir jetzt das Bild stehen, das du hochgeladen hast. 00:34:08.890 --> 00:34:12.090 Wenn du parallel einen zweiten Test hast und du hast vielleicht ein System, 00:34:12.250 --> 00:34:15.850 das nicht mehrere Benutzer kann und der zweite Test macht auch irgendwas mit Bildern, 00:34:16.010 --> 00:34:19.930 dann kann es halt passieren, dass der zweite Test dem ersten Test irgendwie das Bild unterm Arsch weglöscht 00:34:20.010 --> 00:34:21.130 oder die Datenbank lockt. 00:34:21.290 --> 00:34:25.050 Oder die Datenbank lockt oder irgendwelche Sachen macht, die einfach nicht parallel gehen. 00:34:25.210 --> 00:34:30.170 Bedeutet, wenn dein System da nicht drauf ausgelegt ist, dann hast du ein Problem. 00:34:30.410 --> 00:34:35.450 Bedeutet, die lässt du auch oft einfach seriell laufen und die sind deswegen noch langsamer, 00:34:35.530 --> 00:34:36.810 als sie eigentlich sein müssten. 00:34:37.610 --> 00:34:39.210 Im Gegensatz zu Unit-Tests. 00:34:39.770 --> 00:34:46.330 Also zudem würde ich halt noch sagen, Integration-Tests sind halt vom Setup her sehr kompliziert, 00:34:46.410 --> 00:34:52.890 weil du dir halt eine komplett, eine komplette zweite Produktionsumgebung mehr oder weniger aufsetzen musst, 00:34:53.210 --> 00:34:54.090 um die laufen zu lassen. 00:34:54.170 --> 00:34:58.010 Es sei denn, du fährst sie gegen die Produktion, was halt dann irgendwie so, 00:34:58.330 --> 00:35:00.890 huch, ich habe aus Versehen mal alle Benutzer gelöscht. 00:35:00.970 --> 00:35:01.770 Das kann ja auch mal sein, wenn man. 00:35:02.250 --> 00:35:03.770 Testing-Aspekten okay, ne? 00:35:04.890 --> 00:35:05.210 Ja. 00:35:05.690 --> 00:35:07.450 Warum konnte ich denn alle Benutzer löschen? 00:35:09.690 --> 00:35:12.490 Ich glaube, das hatten wir auch in irgendeiner unserer Talksendungen schon mal, 00:35:12.570 --> 00:35:14.970 dass das dann irgendwo bei so einer Spielebude mal so ein Fall gab, 00:35:15.050 --> 00:35:20.250 dass irgendeiner aus Versehen mal einen Test geschrieben hat. 00:35:21.450 --> 00:35:22.490 Aus Versehen test geschrieben hat. 00:35:22.570 --> 00:35:25.530 Nee, der hat halt irgendwie mal Code geschrieben und hat den halt gegen eine Umgebung, 00:35:26.490 --> 00:35:30.810 die er von seinem Kollegen diktiert bekommen hat, laufen lassen und dann hat sich herausgestellt, 00:35:30.890 --> 00:35:33.210 das war jetzt keine Testing-Umgebung, sondern es war eine Produktion. 00:35:33.370 --> 00:35:37.050 Plötzlich sind dann halt irgendwie Hunderttausende von Benutzern weg. 00:35:37.130 --> 00:35:41.130 Und sowas will man halt natürlich nicht, deshalb ist es halt dementsprechend sehr aufwendig, 00:35:41.210 --> 00:35:42.890 so eine Testumgebung aufzusetzen. 00:35:42.970 --> 00:35:49.770 Zudem wird es halt so, je höher man in der Abstraktionsebene kommt vom Unit über einen Integration-Test 00:35:50.090 --> 00:35:54.170 zum Acceptance-Test, je mehr Test-Cases hast du, die du abdecken musst. 00:35:54.330 --> 00:36:00.170 Weil wenn du jetzt sagst, okay, du willst alle deine Edge-Cases mit einem Acceptance-Test abdecken, 00:36:00.250 --> 00:36:05.690 dann musst du im Endeffekt alle Edge-Cases von allen Subsystemen, die in deiner kompletten Anwendung 00:36:05.690 --> 00:36:09.850 ineinander verschachtelt sind, musst du im Endeffekt alle über die eine Schnittstelle, 00:36:09.930 --> 00:36:13.850 nämlich über die, die der Benutzer auch testen, also benutzen sollte, 00:36:14.090 --> 00:36:15.210 die musst du dann halt testen. 00:36:15.290 --> 00:36:19.930 Und dementsprechend ist es halt auch, hast du dann halt einen furchtbaren Testwildwuchs, 00:36:20.010 --> 00:36:24.650 der im Zweifelsfall auch dafür sorgt, dass deine Tests oft brechen, 00:36:24.810 --> 00:36:30.090 weil das, was sich am ehesten ändert, ist wahrscheinlich die Schnittstelle, 00:36:30.170 --> 00:36:32.170 mit der der Benutzer interagiert. 00:36:32.730 --> 00:36:37.690 Ich denke, deine Core-Libraries im Hintergrund, die du dir irgendwann mal geschrieben hast, 00:36:37.770 --> 00:36:42.490 die werden wahrscheinlich relativ stabil bleiben, aber wenn neue Features hinzukommen, 00:36:42.570 --> 00:36:45.850 neue Buttons kommen hinzu, das User Interface ändert sich und sonst was, 00:36:45.930 --> 00:36:47.930 das kann alles dazu führen, dass deine Tests brechen. 00:36:48.010 --> 00:36:50.570 Das heißt, sie sind halt auch relativ fragil. 00:36:50.810 --> 00:36:54.730 Richtig, und auch nicht nur, wenn du was änderst, sondern es kann ja auch sein, 00:36:54.890 --> 00:36:59.210 das macht gerade auch Acceptance-Tests noch langsamer teilweise, 00:36:59.290 --> 00:37:02.330 dass du einfach ein System hast, das nicht auf sich selber basiert, 00:37:02.410 --> 00:37:06.730 sondern ja, mein System schickt E-Mails, mein System hat eine Kreditkartenabrechnung noch zwischendrin. 00:37:07.050 --> 00:37:10.570 Erstmal musst du dann hoffen, dass diese Kreditkartenabrechner dir eine Möglichkeit gibt, 00:37:10.650 --> 00:37:15.770 in einer Sandbox-Umgebung zu arbeiten, weil sonst musst du ihn komplett wegnocken und das ist dann auch 00:37:15.770 --> 00:37:19.290 irgendwie doof, weil dann ändert der seine API und auf einmal Spam Protection. 00:37:20.170 --> 00:37:22.410 Du hast plötzlich einen Capture drin und du hast halt entweder, oh, 00:37:22.810 --> 00:37:27.530 mache ich jetzt OCR oder programmiere ich irgendwie meinem Testsystem eine KI rein, 00:37:27.610 --> 00:37:29.210 dass der Captures knacken kann. 00:37:29.850 --> 00:37:31.610 Oder was machst du dann? 00:37:31.770 --> 00:37:36.330 Ja, das ist alles blöde Sachen und auch gerade so Sachen wie E-Mails schicken oder so, 00:37:36.410 --> 00:37:41.290 dann wartet dein Test einfach mal 30 Sekunden für jedes Mal, wenn dein Benutzer sich irgendwie registrieren 00:37:41.290 --> 00:37:42.410 soll mit einer E-Mail. 00:37:42.570 --> 00:37:48.650 Oder also ich persönlich muss recht viel Tests schreiben, die die Amazon orchestrieren. 00:37:49.290 --> 00:37:53.930 Unsere Tests dauern irgendwie, ich glaube, jetzt sind wir bei 14 Stunden angekommen, wenn die durchlaufen. 00:37:54.090 --> 00:37:57.610 Weil du brauchst halt allein den Server hochzufahren und da Zeug drauf zu installieren, 00:37:57.850 --> 00:38:01.130 dauert halt einfach mal 15 Minuten, da kannst du recht wenig gegen tun. 00:38:01.290 --> 00:38:06.890 Und dann machst du das irgendwie während deinen Tests 28 Mal und du kannst halt Sachen, 00:38:07.050 --> 00:38:09.610 so Sachen kannst du, du kannst das Betriebssystem nicht wegmocken. 00:38:09.850 --> 00:38:13.130 Aber du kannst es parallelisieren, du nimmst einfach mehr und nimmst dann die Hälfte von den Tests. 00:38:13.450 --> 00:38:16.890 Deswegen laufen unsere Tests auch nicht mehr in 14 Stunden durch, sondern in drei, 00:38:16.970 --> 00:38:20.570 aber dann laufen eben 100 Server gleichzeitig und verbrennen Geld beim Testen. 00:38:21.370 --> 00:38:23.770 Das ist halt immer so eine Sache. 00:38:24.010 --> 00:38:29.450 Ja, gleichzeitig, also wir hatten ja auch den Punkt, also Tests sind ja zum einen mal eine Sicherstellung, 00:38:29.530 --> 00:38:34.970 zum anderen eine Dokumentation und zum anderen kann man Tests auch als eine Art Arbeitsanweisung verwenden. 00:38:35.290 --> 00:38:39.690 Also, dass ich eben den Test mit meinem Project Owner zum Beispiel bespreche und dann sage, 00:38:39.770 --> 00:38:41.850 okay, diesen Test muss ich erfüllen. 00:38:41.930 --> 00:38:46.090 Und je weiter unten ich da im Level bin, also so ein Acceptance-Test, 00:38:46.170 --> 00:38:51.130 ist von der To-Do-Beschreibung, also von dem, wie viel ich weiß danach, 00:38:51.210 --> 00:38:54.010 wie ich jetzt, was ich jetzt bauen muss, sehr fuzzy. 00:38:54.170 --> 00:38:57.370 Also ich weiß danach, ich muss jetzt irgendwie ein Login-System bauen. 00:38:57.530 --> 00:39:01.450 Wenn ich aber zum Beispiel einen Unit-Test definiert bekomme, in dem steht, 00:39:01.530 --> 00:39:07.210 okay, der User mit dem Passwort in das Einloggen, Return true oder false, 00:39:07.370 --> 00:39:11.850 musste muss so funktionieren, dann kann ich relativ genau danach losbauen. 00:39:12.170 --> 00:39:17.130 Und kann, also ganz häufig habe ich in solchen Situationen auch erlebt, 00:39:17.210 --> 00:39:23.690 wenn man so Acceptance-Tests macht, wenn man mit denen anfängt, dass man so Illusions of Agreement hat. 00:39:23.770 --> 00:39:29.450 Also man denkt, man bespricht das Gleiche mit dem Kunden, ist aber an unterschiedlicher Meinung oder vergisst 00:39:29.450 --> 00:39:32.890 zum Beispiel auch ganz schnell mal irgendwelche Sachen, wie zum Beispiel, 00:39:33.050 --> 00:39:35.530 die Tests sollen aber auch bitte schnell durchlaufen oder so, ja. 00:39:35.610 --> 00:39:37.610 Und dann muss ich mir ein anderes Mittel aussuchen. 00:39:37.690 --> 00:39:40.170 Dann muss ich zum Beispiel zu Unit-Tests greifen. 00:39:40.490 --> 00:39:45.290 Oder ja, also dass der Kunde eben, für den sieht immer alles relativ einfach aus, 00:39:45.370 --> 00:39:51.370 der guckt das halt aus seiner Vogelperspektive an, aber dafür muss ich halt eben aufpassen, 00:39:52.250 --> 00:39:57.210 dass ich danach weiß, was ich baue und dass ich auch das richtig baue. 00:39:58.950 --> 00:40:01.030 Und oft ist er auch dem Kunden ja nicht klar, was er will. 00:40:01.110 --> 00:40:04.310 Das merkt er dann erst beim Entwickeln, dass er dann sagt, ja, keine Ahnung, 00:40:04.470 --> 00:40:09.350 wir wollen ein Rate Limiting einbauen, dass der Kunde auf unsere API nur irgendwie alle fünf Sekunden einen 00:40:09.350 --> 00:40:10.390 Request schicken kann. 00:40:10.630 --> 00:40:14.550 Und dann baust du das auf und dann kommt irgendwann natürlich während dem Testen irgendwie so raus und so, 00:40:14.630 --> 00:40:17.590 ah ja, richtig, unsere Premium-Kunden, da geht es natürlich nicht. 00:40:17.750 --> 00:40:21.430 Und so, ja, jetzt muss ich Ihnen nur ein Rate Limiting bauen, jetzt muss ich auch noch irgendwie einen Filter 00:40:21.430 --> 00:40:26.630 bauen, der vorher abfragt, was denn der Kunde, der gerade anfragt, für eine Klasse bei uns ist und das dann da 00:40:26.630 --> 00:40:28.070 irgendwie wieder rein und rausholen. 00:40:28.230 --> 00:40:32.630 Und da hilft es dann auch wirklich bei der Entwicklung einfach mit dem Kunden zu kommunizieren. 00:40:33.190 --> 00:40:34.150 Erstens das. 00:40:34.390 --> 00:40:39.510 Und zweitens ist es halt wirklich so, wenn man jetzt sagt, okay, wir machen Unit-Tests, 00:40:40.230 --> 00:40:43.910 dann ist es halt auch so, dass ein allein schon, dass man sagt, okay, 00:40:44.550 --> 00:40:47.830 meine Units, die sollen in Isolation laufen können. 00:40:47.910 --> 00:40:52.630 Da ist, würde ich mal sagen, die Wahrscheinlichkeit, dass du das so weit abstrahieren kannst, 00:40:52.710 --> 00:40:56.230 dass du so ein Feature einfach implementiert bekommst, ist sehr viel höher, 00:40:56.390 --> 00:41:02.630 als wenn man jetzt sagt, okay, ich code die Codebase einfach mal nur so runter und hab vielleicht nur 00:41:02.630 --> 00:41:05.670 Integration-Tests oder vielleicht nur Acceptance-Tests. 00:41:07.190 --> 00:41:13.750 Weil dich allein schon dein Coding-Style mehr oder weniger dazu zwingt, 00:41:15.190 --> 00:41:20.390 testbaren Code zu schreiben und der dementsprechend auch einfacher wiederverwendbar und einfacher miteinander 00:41:21.030 --> 00:41:22.150 kombinierbar ist. 00:41:22.790 --> 00:41:26.070 Ich meine, jetzt hat man auch über, also Unit-Tests haben wir jetzt schon genug gesagt, 00:41:26.150 --> 00:41:30.390 was es eigentlich ist und der Unterschied Integration und Acceptance-Test sollte jetzt eigentlich auch so grob 00:41:30.390 --> 00:41:33.910 klar sein, wo die eventuell überlappen oder was da der Unterschied ist. 00:41:34.070 --> 00:41:39.670 Aber also das war jetzt ja bisher nur, dass man, sag ich mal, Funktionalität sicherstellt, 00:41:39.750 --> 00:41:41.430 die man vorher definiert hat. 00:41:42.230 --> 00:41:46.870 Sachen, die mit den wahrscheinlich der Felix ein bisschen öfter zu tun hat, 00:41:47.190 --> 00:41:51.750 sind Tests, die Sachen feststellen sollen, die du nicht definiert hast, 00:41:51.830 --> 00:41:55.430 dass du da einfach irgendwie so, ich sag mal, direkt drauf wirfst und schaust, 00:41:55.590 --> 00:41:56.550 was kleben bleibt. 00:41:57.190 --> 00:42:00.470 Genau, also diese Art von Tests gibt es auch noch. 00:42:01.430 --> 00:42:05.030 Allgemein jetzt bei mir zusammengefasst unter Vulnerability Testing. 00:42:05.270 --> 00:42:11.270 Das heißt, alles, was damit zusammengehört, wäre zum Beispiel, 00:42:12.230 --> 00:42:17.510 also wenn man jetzt ein wirklich Produktivsystem hat, dann hat man solche Sachen wie ein Vulnerability 00:42:17.510 --> 00:42:21.670 Assessment, das heißt, man fäst gar nicht so viel an, sondern probiert nur ein bisschen aus, 00:42:21.830 --> 00:42:23.190 will aber nichts kaputt machen. 00:42:24.070 --> 00:42:29.110 Es gibt natürlich für echtes Testing, also quasi, wenn man selber programmiert hat, 00:42:29.190 --> 00:42:35.670 hat man sowas wie Fuss-Testing oder Fuzzing, wo zum Beispiel Microsoft 00:42:35.670 --> 00:42:40.790 relativ viel Aufmerksamkeit für bekommen hat, dass sie das für ihre Produkte jetzt auch einsetzen. 00:42:42.550 --> 00:42:48.150 Und Penetration Testing ist natürlich dann der aggressivere Weg, 00:42:48.390 --> 00:42:54.710 quasi ein System zu was zu bringen, wofür es nicht gedacht war und was potenziell auch 00:42:55.190 --> 00:42:57.350 Daten zu Datenverlust führen kann. 00:42:57.990 --> 00:43:01.350 Die ganzen Sachen kann man unendlich weit ausführen. 00:43:01.430 --> 00:43:06.550 Also speziell oder im besonderen Penetration Testing gibt es tausende von Millionen von Sachen, 00:43:06.630 --> 00:43:08.310 was man sich da alles überlegen kann. 00:43:08.630 --> 00:43:13.270 Und eigentlich müsste das alles auch von normalen Tests abgefangen werden können. 00:43:13.670 --> 00:43:20.550 Aber die Sache ist, bei solchen Tests versucht man immer so ein bisschen out of the box zu 00:43:20.550 --> 00:43:20.950 decken. 00:43:21.270 --> 00:43:26.950 Man versucht die Sachen so zu verwenden, wie der Entwickler nicht gedacht hat, 00:43:27.030 --> 00:43:29.990 dass es eigentlich funktionieren kann oder funktionieren soll. 00:43:30.710 --> 00:43:36.390 Und dafür denke ich, braucht man auch ein bisschen anderes Mindset. 00:43:36.470 --> 00:43:43.270 Also es ist nicht so, dass 015 indischer Programmierer für 1,50 Dollar die Stunde unbedingt 00:43:43.270 --> 00:43:46.710 solche Gedanken hat, weil er es halt auch gar nicht muss und gar nicht soll, 00:43:46.870 --> 00:43:50.710 weil er soll schnell irgendwie Code produzieren und dann irgendwie soll das Ding funktionieren. 00:43:51.030 --> 00:43:52.070 Was wäre denn so ein Beispiel? 00:43:52.150 --> 00:43:55.830 Also gerade was wir gesagt haben vorher, das war ja alles recht, ich sag mal, 00:43:55.990 --> 00:44:00.070 in Code gegossen, bedeutet es ist, wenn der Test am Ende rauskommt, 00:44:00.230 --> 00:44:03.350 dann ist das ein Stück Source-Code, den du immer und immer wieder ausführen kannst. 00:44:03.670 --> 00:44:09.110 Ich denke, Fuzz-Testing oder Fuzzing geht ja auch in die Richtung, was wäre denn zum Beispiel, 00:44:09.190 --> 00:44:13.910 oder wie sieht denn so ein Fuzzing aus, was teste man da und wie läuft da so ein Test ab? 00:44:14.310 --> 00:44:19.110 Typischer Fall von Fuzzing ist, du hast einen Standard, 00:44:19.910 --> 00:44:21.510 der ein Protokoll beschreibt. 00:44:21.670 --> 00:44:27.190 Und das Protokoll sagt, das und das darf in den und den Feldern drin stehen. 00:44:28.790 --> 00:44:33.430 Und der beschreibt auch, wenn das ist, dann musst du halt was anderes machen. 00:44:33.510 --> 00:44:37.270 Und wenn es einen Fehlerfall gibt, dann musst du halt diese Sache zurückgeben. 00:44:38.230 --> 00:44:44.470 Und jetzt machst du beim Fuzzing genau das, du probierst quasi alle möglichen Werte, 00:44:44.790 --> 00:44:47.990 die potenziell Probleme machen, in diesem Protokoll aus. 00:44:48.310 --> 00:44:54.950 Das heißt, zum Beispiel, du hast besondere Charakters, die so in dem 00:44:54.950 --> 00:44:57.670 Standard zum Beispiel auch nicht gar nicht definiert sind, dass es sowas gibt. 00:44:57.750 --> 00:45:03.270 Du hast irgendwelche Metacaracters, die potenziell 00:45:04.550 --> 00:45:05.670 Probleme machen können. 00:45:05.750 --> 00:45:12.150 Du hast zum Beispiel ein Protokoll, wo drin steht, die Länge des nächsten Dings 00:45:12.550 --> 00:45:14.390 ist halt 100. 00:45:14.550 --> 00:45:18.950 Und dann machst du, die Länge ist eins, aber du machst den Text, der dahinter kommt, 00:45:19.030 --> 00:45:20.230 machst du halt viel, viel länger. 00:45:20.630 --> 00:45:25.190 Und wenn du dann beim Fuzzing mitbekommst, dass das System gecrasht ist, 00:45:25.510 --> 00:45:30.070 dann hast du quasi gezeigt, dass es dort ein potenzielles Problem gibt. 00:45:31.430 --> 00:45:36.790 Und das macht man speziell jetzt beim Vulnerability Testing, weil genau solche Probleme 00:45:37.670 --> 00:45:43.990 besonders das Potenzial haben, auch sicherheitstechnisch relevant zu sein. 00:45:44.390 --> 00:45:47.590 Und das, also da ist auch das Stichwort oft einfach Input Validation. 00:45:47.750 --> 00:45:52.790 Bedeutet beim Fuzzing ist halt immer, du gibst entweder eine Funktion oder einfach auf einen Port oder 00:45:52.790 --> 00:45:55.750 irgendwie in einem HTTP-Paket, du gibst da irgendwelche Daten rein. 00:45:55.910 --> 00:46:00.230 Und im Normalfall hast du halt irgendwie zwei Sachen, wie das ausgehen kann, 00:46:00.310 --> 00:46:03.430 nämlich die API gibt dir irgendwie, keine Ahnung, es ist die blödeste API der Welt, 00:46:03.510 --> 00:46:04.950 die irgendwie zwei Zahlen zusammenzählt. 00:46:05.110 --> 00:46:09.030 Du denkst dir dann, ja, gut, zwei Zahlen rein, eine Zahl raus. 00:46:09.750 --> 00:46:11.910 Oder irgendeine Fehlermeldung. 00:46:11.990 --> 00:46:15.110 Und gut, dann kannst du anfangen, Buchstaben reinzuwerfen, kriegst Fehlermeldungen, 00:46:15.270 --> 00:46:19.270 dann kannst du anfangen, irgendwie negative Zahlen reinzuwerfen, kriegst Fehlermeldungen vielleicht. 00:46:19.750 --> 00:46:25.030 Und dann fängst du mal an, irgendwie eine Newline reinzuwerfen und in Anführungszeichen oben und ein 00:46:25.030 --> 00:46:27.350 Strichkomma und dann noch irgendwie ein RAMS hinten reinzuschreiben. 00:46:28.390 --> 00:46:31.110 Genau, Sachen, und dann schaust du halt, was passiert denn dann? 00:46:31.270 --> 00:46:34.710 Gib dir mir dann immer noch eine Fehlermeldung zurück, gibt der vielleicht irgendwas Komisches zurück. 00:46:34.870 --> 00:46:37.430 Also SQL-Injection ist so der Standard, dass da. 00:46:37.910 --> 00:46:41.990 Genau, das wäre tatsächlich gar nicht so viel Fuzzing, weil bei Fuzzing ist es wirklich so, 00:46:42.070 --> 00:46:46.310 dass du alles rein wirfst, wirklich alles, was so ein Computer halt schon errechnen kann. 00:46:46.390 --> 00:46:49.190 Und du haust es alles dagegen und irgendwo explodiert es dann mal. 00:46:49.350 --> 00:46:52.070 Genau, und in dem Fall wäre halt, wenn du Glück hast, merkst du beim Fuzzing, 00:46:52.150 --> 00:46:55.830 dass wenn du ein Hochkomma rein gibst und rein zu wenig im String explodierst. 00:46:56.230 --> 00:46:57.990 Und das wird dann halt oft auch als Grundlage. 00:46:58.070 --> 00:47:02.630 Genutzt du Fuss einfach und sagst dann so, oh, hier ist irgendwas komisch, mal schauen, was der Input war. 00:47:02.710 --> 00:47:05.190 Und dann kannst du, dann geht normalerweise halt der Mensch ran und sagt, 00:47:05.270 --> 00:47:06.630 okay, ich schaue jetzt, was der Input ist. 00:47:06.710 --> 00:47:11.190 Und so, ah, komisch, der hat zum ersten Mal ein Komma hier benutzt, scheint wohl nicht so zu klappen. 00:47:11.350 --> 00:47:13.030 Genau, oder sein Nachname ist Null oder so. 00:47:13.590 --> 00:47:15.510 Genau, also der Standard, was war es? 00:47:15.590 --> 00:47:16.550 Soap-Encoder, der hat. 00:47:16.710 --> 00:47:18.950 Soapencoder, sorry, null ist, wird zu null. 00:47:19.190 --> 00:47:19.510 Geht nicht. 00:47:19.750 --> 00:47:20.150 Geht nicht. 00:47:21.510 --> 00:47:23.910 In Sachen Fussing ist mir gerade auch noch was eingefallen. 00:47:23.990 --> 00:47:27.590 Ich habe vor einer Weile mal einen Vortrag von einem der Menschen von Beshow, 00:47:27.910 --> 00:47:30.390 die diese React-Datenbank machen, gesehen. 00:47:30.550 --> 00:47:35.750 Und der hat da so ein bisschen beschrieben, dass die auch noch so neben Unit und Integration-Tests machen, 00:47:35.830 --> 00:47:39.430 die noch auch sowas wie Fußing, allerdings ein bisschen anders. 00:47:39.510 --> 00:47:45.030 Die benutzen ja Erlangen und die haben da sowas Implementiertes, nannten die Quick-Check. 00:47:45.350 --> 00:47:50.790 Da ist es quasi so, dass wenn man irgendwelche Funktionen hat, dann tut man da als Code-Annotation 00:47:51.750 --> 00:47:56.070 Bedingungen davor schreiben, die Inputs erfüllen müssen. 00:47:56.230 --> 00:48:02.790 Und was dann dieses Quick-Check-System macht, ist, es generiert Hunderttausende von Test Cases, 00:48:02.870 --> 00:48:06.390 die diese Bedingungen erfüllen und fertigegen die API. 00:48:06.550 --> 00:48:13.030 Und bei denen war es halt im Endeffekt so, dass selbst bei gut getestetem Open Source Code mit hoher Test 00:48:13.030 --> 00:48:19.190 Coverage sind denen reihenweise Systeme explodiert. 00:48:19.350 --> 00:48:25.030 Also einfach durch, indem man mal einen Computer blöd 00:48:26.710 --> 00:48:31.190 einfach Dinge einfach mal generieren lässt, da kommen oft dann Sachen zustande, 00:48:31.270 --> 00:48:34.230 die sich so ein Mensch wahrscheinlich nicht ohne weiteres ausgedacht hat. 00:48:34.550 --> 00:48:36.790 Ja, aber er könnte sich ja trotzdem ausgedacht haben und ausprobieren. 00:48:37.030 --> 00:48:42.470 Ja, genau, also das Problem an der Sache ist ja, dass viele Leute, also das ist bei Testing noch immer 00:48:42.470 --> 00:48:47.510 wichtig, also gerade auch wenn ich auch Unit-Tests eben mache, dass viele Leute die Sachen nur so testen, 00:48:47.590 --> 00:48:48.870 dass sie funktionieren. 00:48:49.590 --> 00:48:52.710 Also ich habe jetzt hier meine Methode gebaut und ich teste im Prinzip nur, 00:48:52.790 --> 00:48:55.270 kommt das hinten bei raus und dann bin ich glücklich und gehe weiter. 00:48:55.510 --> 00:49:00.390 Und das ist für eine Methode, die einfach nur so steht, okay, 00:49:00.630 --> 00:49:04.950 erstmal, natürlich sollte man Edge Cases testen, aber sobald ich Input habe, 00:49:05.030 --> 00:49:11.990 ja, wie zum Beispiel extrem User-Input, dann muss ich da erstmal ganz viel Validation machen und muss mit 00:49:11.990 --> 00:49:12.950 allem rechnen. 00:49:13.590 --> 00:49:19.510 Und das vergessen viele in dem Fall und deshalb sollte man A immer Edge Cases testen. 00:49:20.070 --> 00:49:26.870 Ich fange zum Beispiel persönlich in der Regel mit den Edge Cases an und arbeite mich dann zu dem Zielcase 00:49:26.870 --> 00:49:27.110 vor. 00:49:27.350 --> 00:49:30.550 Und Fuzzing ist ja im Prinzip ja so die automatisierte Version davon, 00:49:30.630 --> 00:49:32.550 dass man sagt, wir lassen uns mal einen Rechner probieren. 00:49:33.510 --> 00:49:34.870 Alles, was geht drauf. 00:49:35.190 --> 00:49:38.870 Genau, das macht man halt meistens auch, wo dann wirklich externe Input kommt. 00:49:38.950 --> 00:49:41.830 Also man würde jetzt nicht versuchen, gegen alle Funktionen, die man hat, 00:49:41.910 --> 00:49:44.870 einfach alles gegenzuwerfen, weil das explodiert ja einfach viel zu oft. 00:49:45.110 --> 00:49:45.510 Ja, klar. 00:49:45.990 --> 00:49:46.390 Der Code. 00:49:46.870 --> 00:49:47.110 Genau. 00:49:47.510 --> 00:49:50.550 Das Problem ist halt, du hast zum Beispiel irgendwie so einen Flow, 00:49:50.630 --> 00:49:53.750 so einen Prozessflow und am Anfang validierst du und danach validierst du nicht mehr, 00:49:53.830 --> 00:49:56.950 weil du es ja davor schon gemacht hast und weil es nicht anders verwendet werden kann. 00:49:57.750 --> 00:50:02.710 Und dann macht es auch nicht unbedingt so viel Sinn, alles gegen alle Funktionen zu werfen. 00:50:02.870 --> 00:50:08.230 Ja, also ich meine, im Normalfall, da ist dann auch so, teilweise unterstützen die dich der Programmiersprache 00:50:08.230 --> 00:50:14.950 mit so checked Exceptions, wo dann halt gut fuzzing Inputvalidierung vielleicht nicht so sehr, 00:50:15.190 --> 00:50:19.830 aber wenn man Java programmiert, dann musst du halt irgendwie, sobald du irgendwo Netzwerk anfasst, 00:50:19.990 --> 00:50:22.950 dann sagt er dir halt so, ja, was denn mit Time-out? 00:50:24.550 --> 00:50:26.150 Implementieren wir irgendwas für Time-out. 00:50:26.630 --> 00:50:29.270 Die meisten Leute sagen dann halt auch, ja, Catch-Exception. 00:50:29.590 --> 00:50:33.430 Ja, entweder die machen so Pokémon-Exceptions, gotta catch them all und dann ist mal gut. 00:50:33.590 --> 00:50:36.150 Oder sie sagen eben so, ja, nicht mein Problem, sorry. 00:50:36.230 --> 00:50:40.790 Und dann sagen dann, ja, meine Klasse wirft übrigens auch hier den Time-out-Error. 00:50:40.870 --> 00:50:41.670 Da mache ich nichts mit. 00:50:41.990 --> 00:50:46.710 Irgendwie wirft man es halt bis zur Main-Methode weiter und dann stirbt halt die VM. 00:50:46.870 --> 00:50:47.110 Richtig. 00:50:47.510 --> 00:50:52.230 Oder die arme Sau, die dann die Bibliothek anfasst, muss dann erstmal 38 Exceptions implementieren. 00:50:52.310 --> 00:50:54.470 Oder er sagt halt auch, ich bin sorry, nicht mein Problem. 00:50:54.710 --> 00:50:56.630 Und dann wird einfach Enterprise Loop drum gebaut. 00:50:56.790 --> 00:50:57.430 Why True. 00:50:57.750 --> 00:50:59.190 Einfach für immer funktioniert es. 00:50:59.590 --> 00:50:59.830 Genau. 00:51:00.310 --> 00:51:00.870 Genau so. 00:51:01.190 --> 00:51:04.630 Die Frage dabei ist ja immer so, wie wahrscheinlich ist, dass das auftritt. 00:51:04.870 --> 00:51:07.910 Also gerade so, wenn ich halt Network-IO mache, dann kann es halt einfach mal sein, 00:51:07.990 --> 00:51:10.230 dass der gegnerische Host down ist. 00:51:10.390 --> 00:51:14.870 Oder zum Beispiel eben File-IO, File Not Found Exception, der Klassiker, 00:51:15.190 --> 00:51:21.750 aber andersrum zum Beispiel ein Fall, der sehr, sehr häufig nicht bedacht wird und der immer für 00:51:21.750 --> 00:51:24.550 Voodoo sorgt auf System, ist das Thema Platte voll. 00:51:24.950 --> 00:51:29.910 Also das habe ich zum Beispiel, es gibt dann zwar eine bei Java zum Beispiel eine I.O.-Exception, 00:51:30.230 --> 00:51:35.110 die man immer fangen muss, wenn man schreiben will, eine Pfeil. 00:51:35.430 --> 00:51:38.790 Aber ich glaube, das ist zum Beispiel so ein Fall, mit dem rechnen irgendwie die wenigsten Leute so, 00:51:38.870 --> 00:51:41.350 was, die Platte kann voll sein, das ist man irgendwie nicht gewohnt. 00:51:41.430 --> 00:51:43.910 Und da passieren tatsächlich in der Regel richtig hässliche Sachen. 00:51:44.070 --> 00:51:50.550 Ja, also ganz ehrlich, da ist es auch, da ist dann die Frage, wie gut muss deine Applikation sein. 00:51:50.630 --> 00:51:53.670 Also ich persönlich für alle Apps, die ich schreibe, mir ist es völlig egal, 00:51:53.750 --> 00:51:55.190 ob der Minute die Platte verläuft. 00:51:55.270 --> 00:51:59.750 Weil wenn das passiert, dann ist das meine Anwendung abstürzt, wahrscheinlich sein kleinstes Problem. 00:51:59.990 --> 00:52:03.590 Also ich habe irgendwie, keine Ahnung, ich habe blöden kleinen Video-Downloader. 00:52:03.750 --> 00:52:07.670 Natürlich könnte ich vor jedem Download schauen, wie groß ist denn der Download, 00:52:07.750 --> 00:52:09.510 wie viel Festplattenplatz hat der noch. 00:52:09.670 --> 00:52:10.470 Aber da musst du eben. 00:52:11.030 --> 00:52:12.230 Ich crashe einfach in der Mitte. 00:52:12.390 --> 00:52:16.950 Ja, oder es crasht in der Mitte und es ist mir völlig egal, weil sonst kann ich natürlich meine Anwendung, 00:52:17.350 --> 00:52:22.230 das ist auch so teilweise eine Kritik an diesen Checked Exception, dass du teilweise ist es halt echt so, 00:52:22.310 --> 00:52:27.030 dass du, dass es dir völlig egal ist, du kannst ja nicht immer gegen alles absichern, 00:52:27.110 --> 00:52:30.310 sonst musst du deine Netzwerk-Timeouts, dann musst du schauen, was passiert, 00:52:30.390 --> 00:52:33.990 wenn dein System out of memory geht, was ist, wenn da eine Platte vollläuft. 00:52:34.790 --> 00:52:36.550 Was ist, wenn ein Bit im RAM flippt? 00:52:36.630 --> 00:52:36.790 Genau. 00:52:39.910 --> 00:52:45.190 Richtig, oder was ist, wenn der da in dein Safe-Game nimmt und im Hexeditor reingeht und 28 Zahlen ändert und 00:52:45.190 --> 00:52:49.750 es wieder rauslädt, dann kannst du entweder anfangen, Checksummen zu bauen und dann irgendwo reinzuschreiben, 00:52:49.830 --> 00:52:51.270 ja, sorry, ist korrupt. 00:52:51.670 --> 00:52:54.070 Oder wenn es halt so ein Singleplayer-Ding ist, dann sagst du einfach, 00:52:54.150 --> 00:52:58.470 ja gut, da hast du irgendwas gemacht, das ist mir aber egal, dann stürzt sich halt ab, 00:52:58.630 --> 00:53:01.270 sorry, hör mal auf, an meinen Safegames rumzudoktoren. 00:53:01.430 --> 00:53:06.310 Ja, also dieses Bitz-Flippen ist speziell ein Problem, was überall alles einfach kaputt macht, 00:53:06.390 --> 00:53:10.950 weil du kannst dagegen nicht so richtig viel machen und wenn du was dagegen machen wolltest, 00:53:11.270 --> 00:53:14.550 dann hast du quasi unendlich viel Boiler-Pro-Code zum Testen. 00:53:14.870 --> 00:53:19.910 Ein Kumpel, der das gerade macht, der in seiner Abschlussarbeit H265, 00:53:19.990 --> 00:53:26.150 also den Videocodec, optimieren soll im Bereich Resilience, 00:53:26.230 --> 00:53:32.150 also gegen halt so komische Fehler von außen, dass man ein Bit im RAM flippt und also der schreibt ja seine 00:53:32.150 --> 00:53:36.470 komplette Abschlussarbeit über einen Simulator, der quasi Bitfehler im Bitstream erzeugt, 00:53:36.550 --> 00:53:38.470 auf irgendeinem gewissen Random Pattern. 00:53:39.190 --> 00:53:42.150 Und sowas kann sein, dass du das machen musst. 00:53:42.230 --> 00:53:46.710 Wenn du Atomkraftwerke zum Beispiel baust, da hätte ich gern, dass du vielleicht überall Checksum benutzt oder 00:53:47.190 --> 00:53:50.550 wenn du Dateisysteme implementierst in so einem ZFS, dann macht er halt Checksuming, 00:53:50.630 --> 00:53:53.190 ist gut, weil das ist eigentlich seine Hauptaufgabe. 00:53:53.350 --> 00:53:57.670 Aber MS Paint muss echt nicht schauen, ob, keine Ahnung, der Pixel immer noch grün ist, 00:53:57.750 --> 00:53:58.710 nachdem ich es wieder geladen habe. 00:53:58.950 --> 00:54:01.350 Die Sache ist halt, ob du nicht das viel früher schon abfangen willst, 00:54:01.430 --> 00:54:05.190 ob du da nicht einfach zweimal den Rahmen haben willst und dann beides mal nachschaust und wenn es kaputt ist, 00:54:05.350 --> 00:54:08.710 dann guckst du halt im dritten RAM nach oder so, keine Ahnung. 00:54:09.190 --> 00:54:11.670 Ich meine, so ist es ja wirklich so. 00:54:11.910 --> 00:54:15.270 Bei Flugzeugen ist es ja so, die haben dann meistens drei oder vier Computer an Bord, 00:54:15.350 --> 00:54:22.310 die sich gegenseitig überprüfen, weil du halt einen einzelnen Computer nicht so absichern kannst, 00:54:22.470 --> 00:54:25.510 dass es ohne weiteres irgendwie entdeckbar ist. 00:54:25.590 --> 00:54:28.710 Ich meine, klar, du kannst jetzt irgendwie sagen, du hast Checksumme im RAM und so weiter. 00:54:28.950 --> 00:54:31.350 Aber irgendwann geht es dann halt aufs Meta-Level hoch. 00:54:31.430 --> 00:54:35.590 Was passiert denn, wenn du dann OSB-Fahr-Cecksuming? 00:54:35.670 --> 00:54:37.750 Genau, was passiert denn dann, wenn du Double Checksumming. 00:54:39.430 --> 00:54:40.390 Double the Trouble, nein. 00:54:40.630 --> 00:54:44.390 Genau, was passiert denn, wenn irgendwie ein Bit in deiner Checksumme flippt? 00:54:44.470 --> 00:54:47.990 Und da ist es halt, da ist Redundanz in dem Sinne dann schon besser. 00:54:48.150 --> 00:54:50.710 Ja, das ist auch die Frage, wer testet denn deine Tests überhaupt? 00:54:50.870 --> 00:54:51.990 Ja, das ist halt, das ist halt. 00:54:52.310 --> 00:54:54.630 Tests sind auch nur Software, aber Test, Tester. 00:54:55.030 --> 00:54:59.830 Und da ist dann, um wieder vielleicht den Bogen nochmal zu kriegen, 00:55:00.870 --> 00:55:05.030 da ist Fußing sowas, was dir eventuell hilft, so Sachen zu erkennen, 00:55:05.350 --> 00:55:06.790 die auch wirklich passieren können. 00:55:06.870 --> 00:55:10.630 Also gerade bei Netzwerk-Input, weil bei Netzwerk-Input da kann wirklich alles reinkommen, 00:55:10.710 --> 00:55:14.150 weil da gibt es irgendeinen kleinen 14-Jährigen, der sich gut mit Computern auskennt, 00:55:14.230 --> 00:55:15.190 dem ist langweilig. 00:55:15.270 --> 00:55:17.670 Und dann knackt er sonst deine Box und löscht all deine Daten. 00:55:17.750 --> 00:55:18.550 Und das willst du nicht. 00:55:18.630 --> 00:55:22.550 Und deswegen, sobald du User-Input hast, da lohnt sich es dann auch wieder, 00:55:23.030 --> 00:55:25.190 vielleicht ein bisschen defensiver zu programmieren. 00:55:25.270 --> 00:55:27.110 Alles, was Parser sind zum Beispiel. 00:55:27.510 --> 00:55:31.350 Hier mal erinnert sich irgendwie das iPhone, der erste iPhone Jailbreak, 00:55:31.430 --> 00:55:36.070 wo es irgendwie einen LibTIF-Exploit gab, weil da irgendwie der TIF-Parser halt hochgegangen ist und du gehst 00:55:36.070 --> 00:55:38.070 auf die Webseite, der installiert dir Software. 00:55:38.150 --> 00:55:39.030 Sollte vielleicht nicht sein. 00:55:39.190 --> 00:55:39.990 Ja, oder praktisch. 00:55:40.230 --> 00:55:45.430 Oder noch besser, Android 1.1, der halt alles, was du in ein Textfeld eingegeben hast, 00:55:45.510 --> 00:55:46.710 vorher, bevor das Ding hat. 00:55:48.390 --> 00:55:50.950 Er hat es als Root evaluiert und dann konntest du halt ein Jailbreak machen, 00:55:51.030 --> 00:55:56.470 indem du Telnet-D in ein Textfeld eintippst, Enter drückst und dann dich mit einem Telnet-Client auf dein 00:55:56.470 --> 00:55:57.430 Handy verbindest. 00:55:57.510 --> 00:56:02.790 Also so trivial kann sowas schon sein und dass sowas passierte, sehen wir in Produkten wie jetzt iOS oder 00:56:02.790 --> 00:56:04.150 Android, dass sowas einfach passiert. 00:56:04.310 --> 00:56:05.830 Ja, das war aber auch Debugging-Code. 00:56:06.310 --> 00:56:08.230 Im Gegensatz zu dem Lib-Tipp, das war wirklich so. 00:56:08.710 --> 00:56:09.670 Die haben das ernst gemeint. 00:56:09.750 --> 00:56:11.030 Und bei dem anderen haben sie gesagt, lol, die haben wir nicht. 00:56:11.270 --> 00:56:12.950 Das haben sie halt auch ein bisschen angelassen. 00:56:13.510 --> 00:56:13.910 Lustig. 00:56:14.070 --> 00:56:16.710 Ja, ich glaube, man könnte das halt vielleicht auch zu den restlichen Tests, 00:56:16.790 --> 00:56:19.270 den wir gerade besprochen haben, so abgrenzen, dass man sagt, okay, 00:56:19.510 --> 00:56:22.230 im Englischen gibt es für dieses Wort Sicherheit zwei Worte. 00:56:22.470 --> 00:56:27.190 Da gibt es einmal Security und da gibt es Safety und das, was wir bisher besprochen haben, 00:56:27.270 --> 00:56:32.470 waren eigentlich mehr so Safety-Geschichten, dass man sagt, okay, unter normalen Bedingungen funktioniert mein 00:56:32.470 --> 00:56:33.030 Test. 00:56:33.750 --> 00:56:40.710 Und das, was Felix jetzt angesprochen hat, ist dann mehr so, wir geht in Richtung 00:56:40.710 --> 00:56:46.470 Security, also wir wollen uns quasi gegen böse Absichten schützen und nicht gegen Sachen, 00:56:46.550 --> 00:56:47.830 die einfach so passieren können. 00:56:48.470 --> 00:56:53.990 So in der Auto-Analogie, wenn das dann irgendwie die Wegfahrsperre gegenüber dem Airbags ist. 00:56:55.110 --> 00:56:58.790 Also ein Safety-Test, in dem Fall, so ein Unit-Test, dient eher dazu, 00:56:59.030 --> 00:57:03.030 dass ich keinen Denkfehler gemacht habe, als ich meinen Code zusammengeschnittselt habe. 00:57:03.270 --> 00:57:10.150 Und ein Security-Test sorgt einfach dafür, dass nicht von außen irgendwelche Zustände 00:57:10.470 --> 00:57:15.670 eintreten, die auf einmal auch dafür sorgen, dass mein iPhone jetzt Software installieren kann, 00:57:15.750 --> 00:57:16.870 weil das geht einfach nicht. 00:57:17.270 --> 00:57:17.830 Das geht schon. 00:57:17.990 --> 00:57:19.190 Oder Website geht schon. 00:57:20.310 --> 00:57:24.150 Den zweiten Punkt, worüber ich jetzt nicht reden will, so viel, weil es echt, 00:57:24.230 --> 00:57:30.870 echt viel ist, Penetration Testing ist quasi, der Mensch ist einfach mal in der Runde kreativ mit der 00:57:30.870 --> 00:57:35.990 Software und überlegt sich, was gibt es denn so für coole Sachen, die vielleicht schon in der Vergangenheit 00:57:35.990 --> 00:57:39.750 mal funktioniert haben gegen Software, dass sie bestimmte Sachen tut, 00:57:40.630 --> 00:57:42.630 für die sie vielleicht nicht ausgelegt ist. 00:57:43.750 --> 00:57:49.110 Oder einfach mal komplett anders kreativ an das Problem reingehen. 00:57:49.190 --> 00:57:54.710 Zum Beispiel kann Computer mit Fuzzing relativ schwierig erkennen. 00:57:55.350 --> 00:58:00.630 Zum Beispiel, du hast Rechte, Problematik und das heißt, du bist irgendwie ein normaler User, 00:58:00.790 --> 00:58:04.230 aber du kannst irgendwie von anderen Benutzern auch die Daten sehen, 00:58:04.470 --> 00:58:05.910 wenn du da irgendwo eine Zahl änderst. 00:58:06.630 --> 00:58:08.790 Und das ist genau Penetration Testing. 00:58:09.110 --> 00:58:15.110 Du schaust ja an, wie ist es strukturiert und werden die Rechte zum Beispiel korrekt eingehalten? 00:58:15.270 --> 00:58:17.910 Oder was passiert, wenn ich da jetzt irgendwie ein Hochkomma reinmache? 00:58:18.150 --> 00:58:20.950 Ja, es sind dann so die, da hatten auch die meisten Penetration-Tester, 00:58:21.110 --> 00:58:25.670 haben da auch einfach viel Erfahrung, so Sachen wie ja, schau mal, wie das System mit Simlings umgeht. 00:58:25.750 --> 00:58:29.030 Was ist denn, wenn nicht auf irgendwie, hatten wir irgendwann mal so einen Fehler, 00:58:29.110 --> 00:58:35.030 wo wir einfach gesagt haben, ja klar, der User deployt was, das deployen wir und chonen CHO das dann einfach 00:58:35.030 --> 00:58:37.670 auf die Rechte von dem User, dass der da auch wieder schreiben kann und so. 00:58:38.550 --> 00:58:44.070 Die Sache war, wenn der in dem Zeitpunkt, wo er deployt hat, bevor wir gechoned haben, 00:58:44.150 --> 00:58:47.590 nochmal einen Simlink reingefrickelt hat irgendwie, indem er live auf dem System drauf war, 00:58:47.670 --> 00:58:51.270 dann kam halt unsere Root-Prozess vorbei, jetzt bin ich alles um. 00:58:51.430 --> 00:58:55.430 Und hat es irgendwie mit, keine Ahnung, einer PHP-Funktion glaubt sie ja ungemacht. 00:58:55.590 --> 00:58:57.270 Die ist ein bisschen komisch, was Simlings angeht. 00:58:57.350 --> 00:59:02.150 Und der Benutzer hätte sich dann damals halt einfach alles, was er so gesimlingt hat, 00:59:02.230 --> 00:59:03.350 sich einverleiben können. 00:59:04.150 --> 00:59:08.550 Und da ist es aber auch die Sache, dass Penetrationstests halt selten automatisiert sind, 00:59:08.630 --> 00:59:12.150 außer du hast was, das quasi nur eine Liste von Regressionstests ist, 00:59:12.310 --> 00:59:16.070 wie, wie heißt denn dieses Ruby-Framework mit Exploits, Metasploit. 00:59:16.710 --> 00:59:22.070 Genau, das ist ja quasi automatisierte Penetrationstests, aber im Endeffekt nur Regressionstests für bekannte 00:59:23.270 --> 00:59:23.510 Probleme. 00:59:23.670 --> 00:59:29.190 Das sind speziell interessant für SQL-Injection, weil du kannst einfach nicht alle Dinge ausprobieren. 00:59:29.350 --> 00:59:32.790 Also du kannst es schon, aber es dauert unendlich lang und da kannst du auch einfach einen Computer das machen 00:59:32.790 --> 00:59:33.190 lassen. 00:59:33.270 --> 00:59:35.270 Aber du kannst den Einstiegspunkt finden. 00:59:35.430 --> 00:59:37.750 Du kannst dir das anschauen. 00:59:38.310 --> 00:59:40.390 Wo sind denn Sachen, die potenziell 00:59:41.250 --> 00:59:42.130 immer kaputt sind. 00:59:42.210 --> 00:59:48.530 Zum Beispiel, was weiß ich bei den WordPress-Teilen irgendwie die ID oder so ein Shit. 00:59:48.690 --> 00:59:49.650 Was ist ständig kaputt? 00:59:50.050 --> 00:59:50.770 Wenn besonders ist. 00:59:51.090 --> 00:59:54.290 Endest du mal die ID vom Benutzer in der URL und schaust dann, was passiert. 00:59:54.370 --> 00:59:55.570 Oh ja, jetzt kann ich andere Daten sehen. 00:59:56.770 --> 01:00:00.370 Oder so die ID von der Indexpage oder sowas. 01:00:00.610 --> 01:00:05.010 Und da ist halt, dann sagst du deinem Programm, 01:00:05.090 --> 01:00:09.090 okay, jetzt wirft alle SQL-Dinge dagegen und vielleicht kommt was raus. 01:00:09.330 --> 01:00:14.450 Und das ist relativ cool zu automatisieren, aber den Einstiegspunkt selber wirst du immer selber suchen. 01:00:15.330 --> 01:00:18.690 Gerade in der Hinsicht, da gibt es ja halt auch immer so ganz nette Kombinationen, 01:00:18.770 --> 01:00:21.890 die man so ein bisschen automatisiert vielleicht sogar finden kann. 01:00:22.450 --> 01:00:29.330 Wir hatten es vor einer Weile in der Talksendung schon mal so mit einem Suchrequest bei GitHub, 01:00:29.410 --> 01:00:35.010 der irgendwie Code, der Get, Post, Exec und Sudo 01:00:36.210 --> 01:00:41.570 zusammen ausführt, da kannst du eigentlich quasi davon ausgehen, 01:00:41.650 --> 01:00:43.410 dass das irgendwie exploitable ist. 01:00:43.730 --> 01:00:48.050 Das ist zwar im Zweifelsfall kein Code, der irgendwie öffentlich auf einem Server verfügbar ist, 01:00:48.290 --> 01:00:50.450 den man ausführen könnte, aber vielleicht doch. 01:00:50.610 --> 01:00:51.250 Ja, richtig. 01:00:51.730 --> 01:00:57.010 Und gerade bei vielen Web-Anwendungen, da findet man das heute, also mittlerweile weniger, 01:00:57.170 --> 01:01:02.930 aber doch immer noch relativ häufig, dass man einfach mit ein paar Google-Suchanfragen zur Rande kommt. 01:01:03.730 --> 01:01:04.370 Google-Hacking halt. 01:01:04.530 --> 01:01:07.010 Ja, genau, du kannst jetzt einfach mal irgendwo einen Browser, bla bla bla, 01:01:07.090 --> 01:01:14.050 such mal nach Innen-URL, also irgendwo wo in der URL, die man von der Webseite Warenkorb oder 01:01:14.050 --> 01:01:20.290 irgendwie sowas Webcam, irgendwie geheime Webcam ist entdeckt mit Google. 01:01:20.530 --> 01:01:26.370 Also wenn man einfach mal sagt, hier so Warenkorb und Preis taucht in einer URL zusammen auf. 01:01:29.810 --> 01:01:30.770 Gratis Pizza bestellen. 01:01:30.850 --> 01:01:34.690 Also wir hatten da mal, wir hatten da mal irgendwie aus der Gegend so einen Penetrationstester, 01:01:34.850 --> 01:01:37.810 der da mal an unserer Hochschule so einen Vortrag gehalten hat. 01:01:37.890 --> 01:01:42.530 Und vor ein paar Jahren würde das, wäre es theoretisch noch möglich gewesen, 01:01:43.970 --> 01:01:48.050 irgendwie hier in Stuttgart Pizza für negative Beträge zu bestellen. 01:01:48.610 --> 01:01:50.050 Die Frage ist, ob er es dir liefert. 01:01:50.370 --> 01:01:52.690 Ja, ich meine, das hat das auch eine negative Pizza dann. 01:01:52.770 --> 01:01:54.370 Ich meine, du kannst ja sagen, das ist strecken möglich. 01:01:54.850 --> 01:01:56.370 Der kommt und klaut dir Pizza. 01:01:56.610 --> 01:01:58.290 War ein Gutschein, war ein Gutschein. 01:01:58.610 --> 01:01:58.850 Natürlich. 01:01:59.010 --> 01:02:01.330 Ja, kann man sagen, mit zwei kommen wir nicht punchen einfach. 01:02:01.650 --> 01:02:02.770 Das ist halt einfach so. 01:02:03.170 --> 01:02:05.410 Das ist halt das Problem, dass er dir immer noch Pizza bringen muss. 01:02:06.050 --> 01:02:08.290 Außer natürlich, das ist so ein komplett automatisiertes System. 01:02:08.850 --> 01:02:09.570 Autopizza, glaube ich. 01:02:10.690 --> 01:02:14.610 Wenn du bei Amazon findest, wo du deinen Preis ändern kannst, da könntest du davon ausgehen, 01:02:14.690 --> 01:02:15.330 die schicken dir das wirklich. 01:02:15.570 --> 01:02:16.610 Wir schicken das auf jeden Fall. 01:02:16.770 --> 01:02:17.010 Richtig. 01:02:17.250 --> 01:02:22.450 Also wenn das so komplett vollautomatisiert ist, dass da kein Mensch mehr reinguckt und Sanity-Checks macht, 01:02:22.530 --> 01:02:24.210 die Frage ist, wer macht dir die Pizza? 01:02:25.090 --> 01:02:29.010 Da gab es zum Beispiel ein anderes Beispiel, da gab es, ich mag ja immer, 01:02:29.090 --> 01:02:35.090 oder ich habe einen Freund, der mag ja so E-Mail-Services und mein Freund hat da natürlich sich irgend so 01:02:35.090 --> 01:02:40.370 eine, was war's, Cloud, Admail, sonst irgendwas, so eine nette Oberfläche und die hatten einen Cloud-Service, 01:02:40.450 --> 01:02:46.610 aber das Problem war, dass mein Freund gemerkt hat, dass die immer nur ihre Accounts in Fünferblöcken abgeben. 01:02:46.770 --> 01:02:51.570 Und mein Freund hatte natürlich nur einen Account gebraucht und dann kannst du dir einfach mal den Post 01:02:51.570 --> 01:02:54.610 ansehen, der da bei dem Bestellfolger abgeschickt wird. 01:02:54.770 --> 01:02:58.850 Und dann stand da einfach so Anzahl mal Preis gleich Final Result. 01:02:58.930 --> 01:03:03.330 Und wenn du die Anzahl auf 1 gestellt hast, dann hat mein Freund natürlich gesagt, 01:03:03.410 --> 01:03:07.010 ja, das System hat dem dann auch einzelne Accounts verkauft, um mal zu testen. 01:03:07.250 --> 01:03:12.930 Bedeutet, es gibt also auch selbst in Produktionssystemen von großen internetaffinen Anbietern so 01:03:14.530 --> 01:03:21.330 Probleme, wo Input-Validierung einfach nicht so ernst genommen wird und so ein Penetrationstester 01:03:21.490 --> 01:03:22.690 hätte das dann wahrscheinlich auch versucht. 01:03:22.850 --> 01:03:28.530 Tatsächlich ist es dann ja gar nicht so sehr Validierung, sondern auch Logik, die da kaputt geht. 01:03:28.690 --> 01:03:33.810 Ja, also Logik-Validierung jetzt nicht nur Syntax korrekt, sondern die Semantik von dem Ganzen. 01:03:34.370 --> 01:03:37.890 So korrekte Syntax, da kann man dann irgendeine Web Application Firewall oft davor setzen, 01:03:37.970 --> 01:03:41.410 die dann sagt, komische Charakter in deinem Namen, lass mal. 01:03:41.970 --> 01:03:43.330 Oder so Spielereien. 01:03:43.490 --> 01:03:45.330 Dafür muss die aber auch erstmal trainiert werden und so. 01:03:45.570 --> 01:03:48.210 Das ist auch alles scheiße eigentlich, aber eine ganz andere Sache. 01:03:48.610 --> 01:03:48.770 Richtig. 01:03:49.010 --> 01:03:52.450 Ich glaube, das wäre dann mal ein Thema für die IT-Security 2-Sendung, 01:03:52.530 --> 01:03:55.490 die wir seit ungefähr fünf Jahren für E-Mail haben. 01:03:55.810 --> 01:04:01.090 Also die haben wir glaube ich schon angerückt, als wir noch nicht, als wir nur Binärgewitter hießen und das 01:04:01.090 --> 01:04:04.290 ein Spezialformat von Radio Tux war. 01:04:05.010 --> 01:04:05.330 Damals. 01:04:05.650 --> 01:04:05.970 Damals. 01:04:06.210 --> 01:04:07.890 Also können wir vielleicht noch nachreichen. 01:04:08.130 --> 01:04:09.330 Nein, NoSQL war die erste. 01:04:09.570 --> 01:04:10.370 NoSQL war die erste. 01:04:10.610 --> 01:04:11.170 Dann war sie die zweite. 01:04:12.770 --> 01:04:17.570 Was anderes, was ja auch noch, ich sag mal, etwas schwammiger ist, 01:04:17.650 --> 01:04:23.250 also diese ganz harten Unitests, wo Zahl rein, Zahl rauskommt, Performance-Testing kann man ja auch machen. 01:04:23.410 --> 01:04:24.770 Und das auch automatisiert. 01:04:24.850 --> 01:04:29.330 Also so im Gegensatz zu Penetrationstest, wo man meist ein bisschen Fingerspitzengefühl braucht, 01:04:29.490 --> 01:04:36.130 einen Performance-Test, den kannst du quasi fast an deinen, entweder Unit-Test oder an deinen Acceptance-Test 01:04:36.210 --> 01:04:37.010 mit dranhängen. 01:04:37.330 --> 01:04:41.330 Einfach sagen, ich will, dass mein Sign-Up irgendwie immer unter 10 Sekunden dauert, 01:04:41.650 --> 01:04:43.170 wenn der schnell tippen kann. 01:04:43.250 --> 01:04:48.050 Oder vom Klicken bis zum E-Mail bekommen sollen, irgendwie 10 Sekunden vergehen. 01:04:48.530 --> 01:04:51.330 Und sowas kannst du dann auch über Tests festlegen. 01:04:51.570 --> 01:04:55.250 Weil teilweise ist es einfach so, dass du irgendwas eincheckst oder irgendjemand checkt halt einen riesigen 01:04:55.330 --> 01:05:02.130 neuen Codebatzen ein und dann stellt sich raus, dass du irgendwie seit Neustem nicht einfach nur die E-Mail 01:05:02.210 --> 01:05:06.050 schickst, sondern dass du über all deine User drüber iterierst, anstatt vor, 01:05:06.130 --> 01:05:07.890 irgendwie eine Hash-Lookup zu machen. 01:05:07.970 --> 01:05:10.210 Und das geht in deinen Tests normalerweise echt gut. 01:05:10.450 --> 01:05:14.290 Das Problem ist, wenn du sowas im Produktionssystem machst, dann hast du ein Problem, 01:05:14.370 --> 01:05:18.690 weil du dann irgendwie über so einen riesen Array-Iterierten wahrscheinlich pro User nochmal einen 01:05:18.690 --> 01:05:20.130 Datenbank-Request macht. 01:05:20.370 --> 01:05:26.530 Und da kannst du Performance-Tests, also entweder wirklich auf Unit-Tests auf Code-Ebene einbauen, 01:05:26.770 --> 01:05:31.250 wo du dann sagst, ja, cool, mache ich, teste ich halt mal, 01:05:31.330 --> 01:05:37.570 dass irgendwie der Algorithmus, den ich da baue, von 1 bis 1 Million als Inputs wunderbar skaliert und schnell 01:05:37.570 --> 01:05:37.810 ist. 01:05:38.050 --> 01:05:43.570 Oder du machst es halt einfach so, dass du diese Performance-Testing als Tracer nennt man sie teilweise da 01:05:43.570 --> 01:05:49.490 auch wie D-Trace oder so als Framework, wenn das System nahe ist, dass du die einfach als Tracer in deine 01:05:49.490 --> 01:05:55.890 laufende Applikation machst und quasi in der Produktion noch Tests drin hast, 01:05:55.970 --> 01:06:01.170 die sicherstellen, dass irgendwie die Ladezeit der Webseite für den Benutzer nicht irgendwie acht Sekunden ist 01:06:01.170 --> 01:06:04.610 und die dich dann alarmieren, wenn irgendwas fehlschlägt. 01:06:04.770 --> 01:06:10.850 Also das ist dann auch so ein Teil, wo Unitests zum Beispiel eher nicht in der Produktionsumgebung ablaufen, 01:06:11.010 --> 01:06:16.450 aber so Performance-Testing, so kleine Beacons und Traces, die kannst du halt auch in eine laufende 01:06:16.450 --> 01:06:21.810 Applikation rein und einfach sagen, okay, wir machen ein Sampling, jeder hundertste Request wird die 01:06:21.810 --> 01:06:28.530 Request-Zeit aufgezeichnet und entweder irgendwie in eine Nagios per Alarm gecheckt oder in ein Graphite 01:06:28.610 --> 01:06:32.130 reingeworfen und dann kannst du zumindest schön sehen, ah ja, hier korreliert, 01:06:32.210 --> 01:06:36.050 hier habe ich die neue Version deployed und auf einmal gingen die Request-Seiten alle irgendwie sechs Sekunden 01:06:36.050 --> 01:06:36.610 hoch. 01:06:37.250 --> 01:06:43.570 Das ist auch so eine Sache, wo du dann quasi die Qualität deiner Software über Performance-Tests 01:06:43.570 --> 01:06:44.610 sicherstellen kannst. 01:06:45.170 --> 01:06:46.210 Du hast eine weitere Test. 01:06:46.610 --> 01:06:51.650 Genau, also das, was du gerade beschrieben hast, wird oft auch als so Tracer-Bullet bezeichnet. 01:06:51.970 --> 01:06:52.850 Leuchtspurmunition. 01:06:53.090 --> 01:06:55.250 Genau auf Deutsch, dass du siehst, wo du hinschießt. 01:06:55.490 --> 01:06:59.090 Genau, man sieht dann halt auch, wenn man bestimmte Dinge verändert, 01:06:59.170 --> 01:07:02.770 dann sieht man auch, was für einen Effekt das hat und das ist so ähnlich wie wenn man irgendwie im Dunkeln 01:07:02.850 --> 01:07:04.370 rumballert und dann sieht, wo seine Kugeln geht. 01:07:04.690 --> 01:07:08.370 Gewehrlauf nach oben, dann siehst du auf einmal, dass der Leuchtstrich, wo jede 20. 01:07:08.530 --> 01:07:11.170 Kugel halt irgendwie so leuchtende Phosphor ist oder so. 01:07:11.650 --> 01:07:16.850 Dann kannst du eben nachvollziehen, was deine Applikation macht, wenn deine Applikation Maschinengewehr ist. 01:07:17.010 --> 01:07:19.330 Leuchtschuhe Munition, bei uns in der Software. 01:07:19.810 --> 01:07:20.770 Sieht auf jeden Fall cool aus. 01:07:20.850 --> 01:07:22.130 Also cool, das kann man nicht sagen. 01:07:22.290 --> 01:07:24.130 Genau, und Graphite sieht auf jeden Fall cool aus. 01:07:24.210 --> 01:07:26.370 Also wenn es eins tut, dann cool aussehen. 01:07:26.690 --> 01:07:27.890 Kann cool Graphen machen auf jeden Fall. 01:07:28.130 --> 01:07:28.450 Richtig. 01:07:29.090 --> 01:07:33.330 Genau, und das ist auch einer von diesen etwas, ich sag mal, 01:07:35.170 --> 01:07:37.330 weniger was, was man immer und immer wieder ausführt. 01:07:37.410 --> 01:07:40.450 Außer du bist natürlich irgendwie High-Frequency Trader und musst wissen, 01:07:40.530 --> 01:07:43.490 dass der Algorithmus sauschnell ist und wenn der dann ein Bit flippt, 01:07:43.570 --> 01:07:44.930 dass der nicht auf einmal langsam wird. 01:07:45.250 --> 01:07:48.690 Aber für so, ich sag mal, die normalen Leute, da schaust du dir halt an, 01:07:48.770 --> 01:07:52.450 wie schnell die Seite lädt oder wie schnell dein JavaScript ausgeführt wird im Browser. 01:07:54.130 --> 01:07:59.330 Das wäre dann auch noch eine weitere Art von Testen, die man in einem Produktionsprozess machen kann. 01:08:01.490 --> 01:08:04.770 Flydi, hast du nicht irgendwie mal so Zeugs auch mal gemacht? 01:08:06.210 --> 01:08:07.250 So Performance Testing. 01:08:07.490 --> 01:08:08.690 Performance Testing. 01:08:09.090 --> 01:08:10.930 Muss ich jetzt gerade drüber nachdenken, habe ich das mal gemacht? 01:08:11.170 --> 01:08:14.290 Du hast auf jeden Fall mal Skripte dafür geschrieben irgendwie. 01:08:14.770 --> 01:08:15.970 Ich habe mal ein Beispiel. 01:08:17.010 --> 01:08:18.370 Achso, Load-Testing hast du gemacht mal. 01:08:19.570 --> 01:08:22.210 Was ja quasi so die umgekehrte Performance-Test-Art ist. 01:08:22.290 --> 01:08:26.530 Du schaust nicht, wie schnell ein Request ist, sondern du schaust, wie viele Requests du da drauf werfen 01:08:26.530 --> 01:08:27.890 kannst und dann sind die immer noch schnell. 01:08:28.130 --> 01:08:33.490 Ja, genau, also im Endeffekt ist es halt schon so, achso, jetzt weiß ich wieder, was du spart, spart da genau. 01:08:33.570 --> 01:08:35.490 Das war ein Load-Testing im Endeffekt. 01:08:35.810 --> 01:08:42.130 Also worum es da halt geht, ist, zeig mir mal, dass deine Applikation vielleicht nicht nur mit zwei, 01:08:42.290 --> 01:08:49.250 drei Benutzern von dem Laptop aus umgehen kann, sondern dass deine Applikation vielleicht auch von 200, 01:08:49.330 --> 01:08:56.130 300 tatsächlichen wirklichen Maschinen im Internet, die mehrere tausend Benutzer 01:08:56.130 --> 01:08:59.410 jeweils simulieren, umgehen kann. 01:08:59.570 --> 01:09:03.970 Ja, und das, also das ist auch, also wie du gesagt hast, ist auch ein Unterschied dann wirklich, 01:09:04.450 --> 01:09:08.770 wo eventuell deine Applikation gar nichts für kann, sondern eventuell auch die Ausführungsumgebung. 01:09:08.930 --> 01:09:12.770 Ja, und die Architektur generell nicht nur den Code selbst, sondern halt auch, 01:09:12.850 --> 01:09:16.850 wie viele Server hast du jetzt da stehen und wie sehen deine Loadbalancer aus und was macht dein, 01:09:17.010 --> 01:09:19.970 was macht dein Rechenzentrum eigentlich, wenn da mal ein Haufen Requests reingehen. 01:09:20.050 --> 01:09:22.530 Ich meine, ich habe ja schon früher so Geschichten gehört mit Leuten, 01:09:22.690 --> 01:09:26.530 die dann irgendwelche Bitterrent-Tracker betrieben haben, die haben irgendwie den umgezogen, 01:09:26.610 --> 01:09:31.250 DNS geswitcht, im neuen Rechenzentrum hochgefahren und plötzlich war das komplette Rechenzentrum aus. 01:09:32.530 --> 01:09:35.250 Da stützt der Edge-Router ab, wenn er zu viele Connections reingeht. 01:09:35.330 --> 01:09:35.650 Sorry. 01:09:35.810 --> 01:09:40.130 Ja, also sowas ist, das ist dann halt auch ein Load-Test für die Infrastruktur außenrum. 01:09:40.690 --> 01:09:45.970 Wenn dann deine Software sowas wegstecken kann, vielleicht nicht die Infrastruktur des Rechenzentrums. 01:09:46.290 --> 01:09:49.250 Und damit testest du dann halt auch Sachen, die du gar nicht selber gemacht hast. 01:09:49.330 --> 01:09:55.730 Das ist so im Grunde mein täglich Brot zur Zeit, dass Sachen testen, wo ich eigentlich nichts für kann. 01:09:55.890 --> 01:10:00.770 Wo du dann merkst, so, ja, stellt sich raus, der Linux-Kernel-Select-Call, 01:10:00.930 --> 01:10:06.050 wenn du das irgendwie so und so viele Sachen in so eine Geschwindigkeit anrödeln lässt, 01:10:06.130 --> 01:10:07.810 dann performt der total scheiße. 01:10:07.970 --> 01:10:12.530 Oder hier, ja, deine MySQL-Datenbank, die im Testen funktioniert, die immer super, 01:10:12.690 --> 01:10:18.530 aber stellt sich raus, wenn du gleichzeitig in der Produktion die Backups anwirfst und rein zufällig deinen 01:10:18.530 --> 01:10:21.090 Cron-Job noch so getheimt hast, dass es nicht nur die Backups kommen, 01:10:21.170 --> 01:10:26.290 sondern auch irgendwie was anderes, dann stellt sich raus, dass dein API-Server auf der anderen Seite der Welt 01:10:26.290 --> 01:10:27.730 nicht mehr so gut reinkommt. 01:10:27.970 --> 01:10:33.410 Und das sind halt so Sachen, wo dann Low-Testing quasi auch eine Art Acceptance-Test ist, 01:10:33.490 --> 01:10:36.850 in dem Sinne, dass du dein komplettes System von vorne bis hinten testest, 01:10:37.010 --> 01:10:40.530 aber dass dann halt auch so Sachen wie, wie performt denn dein Dateisystem, 01:10:40.610 --> 01:10:43.410 wie performt er dein TCP-IP-Stack. 01:10:43.810 --> 01:10:46.850 Und das ist so im Normalfall ist Low-Testing dann eher interessant für, 01:10:46.930 --> 01:10:51.410 also weniger für Desktop-Software, also MS-Word, weiß ich nicht, ob die Low-Testing machen, 01:10:51.730 --> 01:10:57.490 aber für Sachen, die entweder sehr viele Daten haben oder wenig Daten, 01:10:57.650 --> 01:10:59.810 aber sehr schnelle Antwortzeiten haben müssen. 01:11:00.690 --> 01:11:05.810 Also, keine Ahnung, ich denke, so ein Motorsteuergerät oder so, 01:11:05.890 --> 01:11:09.970 das kannst du natürlich auch testen, indem du einfach unendlich viele Inputs dranhängst und sagen, 01:11:10.050 --> 01:11:15.730 was passiert denn, wenn ich ganz schnell irgendwie so ein flatterndes Signal habe oder so Geschichten, 01:11:15.810 --> 01:11:21.570 dass du einfach, ich sag mal, ähnlich wie bei einem Fuzzing einen Extremwert anlegst, 01:11:21.650 --> 01:11:26.930 also ganz viele Connections oder einfach ganz große Pakete, um dann einfach mal zu sehen, 01:11:27.090 --> 01:11:31.170 was könnte denn noch explodieren, woran ich gar nicht schuld bin, aber wo ich mich halt trotzdem drum kümmern 01:11:31.170 --> 01:11:31.330 muss. 01:11:31.410 --> 01:11:36.450 Ja, oder du hast plötzlich ein paar Clients, die simuliert vielleicht an der ISDN-Leitung hängen und total 01:11:36.450 --> 01:11:41.170 langsam sind und dann einfach mal nach jedem Request ganz lange warten müssen. 01:11:41.650 --> 01:11:43.170 Das ist der Slow Loris. 01:11:43.490 --> 01:11:44.450 Genau, Slow Loris. 01:11:44.610 --> 01:11:47.890 Slow Loris ist auch so eine typische Attacke, wo die meisten Leute, 01:11:47.970 --> 01:11:53.250 also wenn du so normal Software programmierst, da denken die meisten auch gar nicht dran. 01:11:53.330 --> 01:11:56.610 Und da fängt es dann auch an, wo du dann merkst, wie gut ein Programmierer ist, 01:11:56.690 --> 01:12:00.770 ob der dann gesagt hat, ja, also erstmal die Anwendung läuft jetzt, 01:12:00.850 --> 01:12:02.850 aber was passiert denn, wenn jetzt irgendwie? 01:12:03.650 --> 01:12:06.690 Also haben wir aktuell zum Beispiel so ein Thema, wir haben so ein Produkt, 01:12:07.090 --> 01:12:13.490 nennt sich Cloud API, da können User über eine REST-Anfrage mit einem JSON-Body irgendwelche Sachen in so 01:12:13.490 --> 01:12:14.450 einem System ändern. 01:12:14.610 --> 01:12:19.010 Und diese API kann auf mehrere Produktionsumgebungen zugreifen, je nachdem, 01:12:19.330 --> 01:12:21.410 was der Benutzer halt von Account hat. 01:12:21.570 --> 01:12:23.650 Und jetzt haben wir uns auch dann gefragt, so ja, was passiert denn, 01:12:23.730 --> 01:12:26.610 wenn eine von unseren Produktionsumgebungen rein zufällig down ist? 01:12:27.330 --> 01:12:30.850 Kann ja passieren, dass dein Server irgendwie, Amazon friert die Maschine ein. 01:12:31.090 --> 01:12:33.810 Hin und wieder gehen Maschinen einfach weg, ist Amazon, kann man nichts machen. 01:12:33.970 --> 01:12:35.970 Aber was passiert dann mit allen anderen Servern? 01:12:37.650 --> 01:12:42.610 Wie ist denn dein TCP-IP-Stack eingestellt, wenn eine SSH-Connection zum Beispiel einfach nicht mehr da ist? 01:12:42.770 --> 01:12:44.690 Was für Keep-Alive-Intervalle hast du da? 01:12:44.770 --> 01:12:46.290 Bleibt dann einfach die Connection offen? 01:12:46.450 --> 01:12:51.890 Bedeutet 20 User pollen da einfach und auf einmal hast du deine 20 Connection-Slots von deinem Web-Server 01:12:51.890 --> 01:12:53.810 irgendwie belegt und da geht gar nichts mehr. 01:12:53.970 --> 01:12:58.530 Und das ist eben auch so eine Sache, die du bei Load Testing eventuell rausfinden kannst, 01:12:58.610 --> 01:13:03.250 indem du dann einfach Load Testing noch kombinierst mit, wie heißt denn das immer so? 01:13:03.330 --> 01:13:08.050 Also die Chaos-Monkey-Geschichten, wenn du einfach Sachen in deinem System wegschießt, 01:13:08.130 --> 01:13:09.890 gibt es da einen Namen für die Tests? 01:13:10.450 --> 01:13:11.250 Magic Tests. 01:13:11.570 --> 01:13:12.530 Magic Tests, genau. 01:13:13.330 --> 01:13:17.090 Also das macht bei uns netterweise, brauchen wir keinen Chaos Monkey, gerade weil wir viel Amazon benutzen. 01:13:17.170 --> 01:13:18.530 Das machen Amazon für uns, das ist ein Feature. 01:13:18.610 --> 01:13:20.770 Manchmal sind Sachen einfach weg, manchmal kommt ein Paket nicht an, 01:13:20.850 --> 01:13:22.450 manchmal ist die Netzwerkverbindung kaputt. 01:13:22.610 --> 01:13:23.810 Haben die da einen Service dafür? 01:13:25.490 --> 01:13:26.210 Amazon selber. 01:13:27.330 --> 01:13:29.330 Amazon ist der Free Service dabei. 01:13:29.650 --> 01:13:30.530 Amazon Web Services. 01:13:30.930 --> 01:13:35.010 Amazon Web Services hat integriert schon den Magic Tests. 01:13:36.290 --> 01:13:40.130 Das macht den Futter, aber auf Infrastructurebene. 01:13:40.210 --> 01:13:41.410 Was passiert denn, wenn die Connection weg ist? 01:13:41.570 --> 01:13:42.370 Eigentlich ist ein Power. 01:13:44.530 --> 01:13:46.850 Pwnetesting nennen wir das jetzt, sind wir einfach Sachen wegponen. 01:13:47.010 --> 01:13:51.810 Okay, ich würde jetzt mal gerne dieses Kapitel Testarten abschließen oder habt ihr da jetzt noch irgendwas, 01:13:51.970 --> 01:13:53.570 was wir ganz, ganz doll vergessen haben? 01:13:53.810 --> 01:13:55.650 Ich denke eine vielleicht, die Code-Matrix. 01:13:55.890 --> 01:14:01.810 Wir könnten noch über Matrix reden oder also unter dem Punkt sind auch noch andere Dinge zusammengefasst, 01:14:01.890 --> 01:14:04.370 die man im weitesten Sinne als Metrics bezeichnen kann. 01:14:04.530 --> 01:14:05.250 Ja, das heißt. 01:14:05.890 --> 01:14:11.890 Also zum Großen ist halt der große Punkt, ich glaube, der Marc hat es angesprochen oder reingeschrieben, 01:14:11.970 --> 01:14:13.090 deshalb darf es mal erzählen. 01:14:13.330 --> 01:14:14.210 Komplexität. 01:14:14.850 --> 01:14:15.490 Genau, dass du. 01:14:15.970 --> 01:14:17.810 Also wie ich Code messe oder was mache ich. 01:14:18.050 --> 01:14:22.050 Metriken, genau, indem du einfach sagst, ja gut, dein Code funktioniert jetzt wunderbar, 01:14:22.210 --> 01:14:27.250 aber vielleicht willst du auch sehen, ob du eventuell so diesen typischen Big Ball of Mutt hast. 01:14:27.330 --> 01:14:30.770 Bedeutet das so ein kleines, nettes System und dann brauchst du neue Sachen und dann klatschst du einfach 01:14:30.770 --> 01:14:35.090 immer so mehr Dreck an dein schönes kleines System dran, bis du am Ende so einen riesigen Dreckball hast. 01:14:35.170 --> 01:14:39.010 Und der funktioniert zwar immer noch, aber damit kannst du im Endeffekt gar nichts mehr machen und alles wird 01:14:39.010 --> 01:14:39.650 sau schwer. 01:14:39.890 --> 01:14:45.650 Deswegen gibt es da so Metriken im Sinne von, ja, die schauen dann einfach, wie sehen denn deine Methoden aus? 01:14:45.730 --> 01:14:49.170 Haben die vielleicht 900 Zeilen-Code oder haben die alle neun Zeilen-Code? 01:14:49.330 --> 01:14:52.850 Weil wenn du eine Methode 900 Zeilen-Code hast, dann ist die Chance, 01:14:52.930 --> 01:14:56.850 dass du die eventuell mehrere kleine aufsplitten solltest, wo die Leute auch noch was verändern können, 01:14:56.930 --> 01:15:00.850 ohne irgendwie total Angst haben zu müssen, die ist recht groß. 01:15:01.010 --> 01:15:05.250 Bedeutet, Metriken könnten dann zum Beispiel so die üblichen sein. 01:15:05.410 --> 01:15:09.490 Ja, wie komplex, wie groß sind deine Methoden, wie tief ist dein Zeug verschachtelt, 01:15:09.650 --> 01:15:13.890 wenn du deine Abstract Bean Factory Injection Library hast, 01:15:14.210 --> 01:15:15.090 da denkst du dir. 01:15:15.650 --> 01:15:17.250 Enterprise, du hast Enterprise vergessen. 01:15:17.490 --> 01:15:22.690 Richtig, allein auf mein 82-Zeilen-Zeichen-Terminal, da passt der Klassenname gar nicht mehr. 01:15:22.850 --> 01:15:24.290 Dann hast du auch ein Problem. 01:15:24.450 --> 01:15:28.290 Und das sind so Metriken, die da eventuell helfen können. 01:15:29.730 --> 01:15:34.370 Und also es gibt dann auch noch irgendwie Test Coverage, dass du, also ich mache es jetzt mal einfach halbwegs 01:15:34.370 --> 01:15:38.210 schnell durch, ich denke, so viel reden müssen wir da nicht, dass du zum Beispiel sagen kannst, 01:15:38.370 --> 01:15:42.370 ja, welche Code-Pfade werden denn überhaupt von meinen Test angesprochen? 01:15:42.530 --> 01:15:44.210 Gibt es Sachen, die ich noch gar nicht getestet habe? 01:15:44.290 --> 01:15:47.410 Das kann man auch über so statische Analysen, indem du einfach anschaust, 01:15:47.570 --> 01:15:51.170 welche Methodennamen ruft denn dein Test auf, und dann schaust du in den Methoden, 01:15:51.250 --> 01:15:53.810 welche Methoden werden in dieser Methode aufgerufen. 01:15:53.970 --> 01:15:57.170 Und am Ende hast du halt eine Liste von allen Methoden und eine Liste von allen Methoden, 01:15:57.250 --> 01:15:58.610 die der Test anfasst. 01:15:58.850 --> 01:16:02.050 Und dann kannst du schauen, sind es dieselben oder fehlen da vielleicht noch welche? 01:16:02.130 --> 01:16:05.090 Gibt es acht Methoden, die ich niemals in einem Test ausführe? 01:16:05.890 --> 01:16:08.770 Das wäre dann gerade so eine Test-Coverage-Geschichte. 01:16:09.010 --> 01:16:13.170 Also nochmal zur Begriffserläuterung mit statischer Analyse meint der Mark, 01:16:13.490 --> 01:16:19.090 eine Software, die quasi deinen Code auswertet, ohne ihn selbst auszuführen. 01:16:19.250 --> 01:16:19.410 Genau. 01:16:19.570 --> 01:16:26.450 Also das ist quasi ein Tool, was nur auf deinen Code guckt und nach irgendwelchen Patterns sucht, 01:16:26.770 --> 01:16:30.690 um dir vielleicht zu sagen, hey, du hast hier eine Methode, die ist 900 Zeilen lang, 01:16:30.770 --> 01:16:31.410 mach mal kleiner. 01:16:31.490 --> 01:16:36.690 Oder du hast hier eine Klasse, die ist irgendwie 1000 Zeilen oder 1500 Zeilen lang. 01:16:37.970 --> 01:16:41.730 In der Java-Welt mag das vielleicht irgendwie noch okay sein, aber wenn man eine Programmiersprache hat, 01:16:41.810 --> 01:16:46.370 die jetzt nicht so super verbos ist, dann gibt es halt wenig Gründe, 01:16:46.450 --> 01:16:50.770 dass eine Klasse so groß sein muss oder eine Methode so groß sein muss. 01:16:51.570 --> 01:16:58.290 Weil das würde auch dann im Endeffekt auch dem ersten Prinzip von diesem Solid, 01:16:58.450 --> 01:17:01.330 wie nennt man das Solid-Prinzip widersprechen. 01:17:01.490 --> 01:17:07.570 Das wird oft in vielen Programmierbüchern genannt oder auch Vorträgen und ist eigentlich ganz nett. 01:17:07.650 --> 01:17:11.410 Und das erste Prinzip ist halt das Single Responsibility Principle. 01:17:11.810 --> 01:17:16.770 Das heißt halt, deine Klasse soll da eine Sache machen, die soll für eine Sache zuständig sein und das soll 01:17:16.770 --> 01:17:17.650 sie gut machen. 01:17:17.890 --> 01:17:21.730 Und da gibt es eigentlich, es sei denn, diese eine Sache ist furchtbar komplex und du kannst, 01:17:21.810 --> 01:17:27.490 also sagen wir es mal so, wenn du diese, was die Klasse macht, in einem Satz schlüssig erklären kannst, 01:17:27.570 --> 01:17:29.250 dann ist es wahrscheinlich okay so. 01:17:29.490 --> 01:17:35.010 Aber dann gibt es wahrscheinlich auch wenig Gründe, warum die Klasse irgendwie 2000 Zeilen lang sein muss. 01:17:37.410 --> 01:17:41.410 Ansonsten, also ich habe hier mal den Wikipedia-Beitrag verlinkt. 01:17:41.490 --> 01:17:46.930 Ich weiß jetzt nicht, ob mir das alles besprechen müssen, was da bei Solid bei diesem Akronym drankommt, 01:17:47.010 --> 01:17:48.690 aber das kann sich jeder mal selber angucken. 01:17:48.770 --> 01:17:50.610 Das ist eigentlich sehr sinnvoll. 01:17:50.770 --> 01:17:55.090 Und das ist auch schon, man muss sagen, das ist auch eine von den, ich sag mal, 01:17:55.250 --> 01:17:56.930 das ist die B-Note, würde ich sagen. 01:17:57.010 --> 01:18:01.490 Also, wenn du wirklich, ehnen wieder in Produktionscode, wirst du gegen so Sachen verstoßen. 01:18:01.650 --> 01:18:06.610 Also wenn du eine Codebase hast, die komplett clean ist, wo alles da super abgedeckt wird, 01:18:06.690 --> 01:18:10.290 dann Respekt, dann haben das echt Leute gemacht, die da viel Erfahrung mit haben. 01:18:10.610 --> 01:18:15.650 Dasselbe, ich habe auch noch die Sandy Metz Rules for Developers verlinkt, 01:18:15.730 --> 01:18:18.770 dass irgendwie so Klassen können nicht länger als 100 Zeilen Code sein, 01:18:19.010 --> 01:18:23.010 Methoden können nicht länger als 5 Zeilen Code sein, was halt auch schon Respekt. 01:18:23.490 --> 01:18:27.170 Es gibt nicht mehr als vier Parameter, die du in eine Methode reintun kannst. 01:18:27.490 --> 01:18:31.090 Es sind alles so Sachen, die kannst du über Codemährigen abdecken. 01:18:31.330 --> 01:18:37.570 Und ich denke mal, die schlimmsten Verstöße solltest du versuchen zu beseitigen, wenn du dennoch Zeit hast. 01:18:37.890 --> 01:18:41.010 Ganz clean wirst du wahrscheinlich nicht kommen. 01:18:41.410 --> 01:18:46.370 Ja, ich weiß nicht, ob wir das jetzt schon besprechen wollen oder später noch in der Diskussion. 01:18:47.730 --> 01:18:53.970 Ja, es ist die B-Note und ja, ich gehe davon aus, dass keiner, der irgendwie so einen Code in Produktion hat, 01:18:54.210 --> 01:18:57.170 den in der Form ursprünglich mal so geschrieben hat. 01:18:57.410 --> 01:18:58.930 Das ist ja das Schöne, wenn man Tests hat. 01:18:59.010 --> 01:19:00.450 Wenn man Tests hat, kann man refactoren. 01:19:00.530 --> 01:19:04.930 Und Refactorings bedeuten eigentlich, du fügst keine Funktionalität hinzu, 01:19:05.010 --> 01:19:11.570 du lässt deine Schnittstellen stabil und du tust die interne Struktur deiner Klassen und deiner Units so 01:19:11.570 --> 01:19:16.770 aufpimpen, dass du bessere Abstraktionen hast, dass du bessere Wartbarkeit hast, 01:19:17.410 --> 01:19:22.290 dass du besser vielleicht sogar Tests dafür schreiben kannst, aber du versuchst halt eigentlich die Funktion 01:19:22.290 --> 01:19:29.090 genau gleich zu lassen, sodass deine bestehenden Tests genau weiter weiter durchlaufen und mit sowas 01:19:29.090 --> 01:19:32.930 erreichst du dann quasi schöne Codemetriken, dass du dann sagst, okay, 01:19:33.170 --> 01:19:37.810 du hast jetzt einen Code, der funktioniert, du hast einen Code, 01:19:38.370 --> 01:19:42.130 der ist getestet und dann kannst du anfangen, denen schön zu machen. 01:19:42.370 --> 01:19:47.010 Also es gibt auch da dieses Prinzip von Onkel Bob, also Robert C. 01:19:47.170 --> 01:19:53.250 Martin hat es, glaube ich, mal gemeint, so first make it work, then make it right, then make it fast. 01:19:53.490 --> 01:19:56.050 Und das sind im Endeffekt so die Geschichten. 01:19:56.130 --> 01:19:59.410 Also da waren wir jetzt bei Punkt 2, wenn wir Performance Testing noch dazu nehmen, 01:19:59.490 --> 01:20:06.210 dann hätte man so den letzten Punkt, dass man sagt, okay, erstmal du sollst überhaupt tun und dann. 01:20:07.190 --> 01:20:14.070 Soll es schön sein und erweiterbar sein und dann können wir es schnell machen, dann können wir optimieren. 01:20:14.390 --> 01:20:19.910 Das ist auch halt dieses, dieses Premature Optimization ist the root of all evil, 01:20:19.990 --> 01:20:21.670 was der, na, wie heißt er? 01:20:21.990 --> 01:20:22.550 Der Mr. 01:20:22.950 --> 01:20:23.910 Dude Tech? 01:20:24.630 --> 01:20:24.790 Was? 01:20:25.030 --> 01:20:25.270 Tech? 01:20:25.510 --> 01:20:25.590 Was? 01:20:25.830 --> 01:20:25.990 Tech. 01:20:26.310 --> 01:20:26.550 Tech. 01:20:26.950 --> 01:20:27.990 Der, der Tech geschrieben hat. 01:20:28.710 --> 01:20:31.510 Ach, Donald Knuth, genau. 01:20:33.030 --> 01:20:39.510 Der hat ja mal diesen Satz gekoint, dass frühzeitige Optimierung die Wurzel allen 01:20:39.510 --> 01:20:40.390 Übels ist. 01:20:41.750 --> 01:20:47.830 Was halt auch dafür sorgt, was halt im Endeffekt so ein bisschen das Problem daran ist, 01:20:47.990 --> 01:20:52.790 ist, dass oder das grundlegende Problem, warum ist schnell, 01:20:53.350 --> 01:20:57.590 warum ist es böse, vorzeitig zu optimieren, 01:20:57.910 --> 01:21:03.510 weil in den meisten Fällen schneller Code nicht unbedingt schöner Code ist. 01:21:03.990 --> 01:21:09.830 Und man meistens, wenn man schon mal abstrahiert hat, viel besser optimieren kann als im Kleinen. 01:21:09.910 --> 01:21:13.590 Also wenn man dann sagt, okay, ich habe jetzt eine Architektur, ich habe eine schöne Abstraktion, 01:21:13.750 --> 01:21:18.710 dann kann man meistens sehr, sehr viel genauer und sehr viel effizienter Dinge optimieren, 01:21:18.790 --> 01:21:21.990 als wenn man jetzt sagt, okay, ich messe jetzt, wie lange eine Methode braucht, 01:21:22.070 --> 01:21:27.510 um zwei Zahlen zu addieren und versucht dann noch oder zu multiplizieren und versucht dann noch mit Bitshiften 01:21:27.510 --> 01:21:30.870 und sonst irgendwas Performance rauszuholen, was mein Compiler vielleicht nicht kann. 01:21:31.110 --> 01:21:31.990 Inline Functions. 01:21:32.150 --> 01:21:34.310 Oder Inline Functions oder was auch immer. 01:21:35.030 --> 01:21:41.750 Sowas sollte man halt tunlichst dann nur tun, wenn man auch tatsächlich Zahlen dafür hat, 01:21:41.990 --> 01:21:47.510 wenn man es gemessen hat und wenn man generell schon eine schöne Architektur außenrum hat. 01:21:48.390 --> 01:21:49.430 Ja, genau. 01:21:51.830 --> 01:21:53.110 Ja, was haben wir denn sonst noch? 01:21:53.430 --> 01:21:54.070 Test Coverage? 01:21:54.150 --> 01:21:54.790 Haben wir das, das haben wir schon. 01:21:55.110 --> 01:21:58.310 Test Coverage habe ich gesagt, also das mit den Methoden und Methoden, bla bla. 01:21:58.550 --> 01:21:58.790 Genau. 01:21:58.870 --> 01:22:00.950 Also zu schauen und vielleicht noch so Sachen. 01:22:01.030 --> 01:22:03.910 Es gibt dann auch noch so Sachen, die Richtung Penetration Testing gehen, 01:22:03.990 --> 01:22:07.110 hat man ja auch schon gesagt, dass du, also Valgrind ist so eine Geschichte, 01:22:07.430 --> 01:22:11.270 das dann auf ziemlich Low Level basiert, wo du dann halt sagst, ja, 01:22:11.430 --> 01:22:16.390 hier greifst du irgendwie einen Pointer, der eventuell noch gar nicht irgendwie da dereferenziert wird, 01:22:16.470 --> 01:22:17.510 bla bla bla. 01:22:18.390 --> 01:22:22.310 Natürlich kann man sowas, wie gesagt, Halteproblem, man kann nicht sagen, 01:22:22.390 --> 01:22:24.550 wo ein Fehler in der Applikation auftreten wird. 01:22:24.870 --> 01:22:31.430 Man kann aber so Patterns erkennen, die öfter mal schief gehen und dann könnte man da vielleicht den Benutzer 01:22:31.430 --> 01:22:37.990 darauf hinweisen, wenn du zum Beispiel ganz, ganz einfache Klassiker irgendwie if 01:22:38.230 --> 01:22:42.950 blah gleich fünf statt if bla ist gleich ist gleich fünf, da sagt er dann, 01:22:43.030 --> 01:22:45.990 ja, du hast hier eine Zuweisung in einem If-Statement. 01:22:46.150 --> 01:22:48.790 Rein syntaktisch ist das völlig in Ordnung. 01:22:49.030 --> 01:22:52.630 Aber vielleicht willst du da nochmal drüber schauen, ob das auch wirklich so gemeint ist, 01:22:52.710 --> 01:22:53.750 weil sonst explodiert alles. 01:22:54.070 --> 01:22:58.710 Oder wie beim Debian Random Number Generator, so ja, 01:22:58.790 --> 01:23:02.470 du hast hier irgendwie Sachen, die noch nicht initialisiert sind und du greifst darauf zu, 01:23:02.550 --> 01:23:04.470 willst du das nicht vielleicht nicht machen? 01:23:04.630 --> 01:23:07.670 Und dann sagt man okay, und dann kriegst du mal 5 als Antwort. 01:23:09.190 --> 01:23:15.590 Also das war genau das Ding, wo dann die Zufallszahl quasi dann nur noch die ID von dem Prozess war. 01:23:15.830 --> 01:23:16.870 Keine Zufallszahl mehr war. 01:23:17.510 --> 01:23:17.910 Nicht so richtig. 01:23:18.070 --> 01:23:19.830 Also war schon noch Zufall, aber halt nicht viel Zufall. 01:23:20.950 --> 01:23:24.710 Und das war, das war, also die Geschichte war halt, dass Wilegrind da wirklich gesagt hat, 01:23:24.790 --> 01:23:26.390 ja, das ist aber irgendwie Burse, was du da machst. 01:23:26.470 --> 01:23:28.790 Und dann hat er gedacht, okay, fix ich das, kein Problem. 01:23:29.030 --> 01:23:29.590 Kann ich alles. 01:23:29.830 --> 01:23:35.270 Aber Wilegrind ist auch cool, wenn du so komischen Frick-C-Code hast und der einfach super hart Memory leak, 01:23:35.430 --> 01:23:37.110 weil Valgrind kann solche Sachen finden. 01:23:37.270 --> 01:23:43.510 Genau, also Valgrind ist so ein Memory-Analyzer für, ich glaube, einen beliebigen Code oder für die Karte. 01:23:43.750 --> 01:23:44.790 Kombinierst du den mit rein? 01:23:45.670 --> 01:23:48.230 Nee, nee, also du lässt es dann damit laufen, quasi. 01:23:49.110 --> 01:23:52.950 Es wird alles dann zehnmal langsamer, aber dafür wird es auch zehnmal cooler, wenn du es dann mitgefixt hast. 01:23:53.030 --> 01:23:54.550 Ja, macht Sinn auf einmal. 01:23:54.790 --> 01:23:58.390 Es gibt ja bestimmte Arten, wie man entwickeln kann. 01:23:58.550 --> 01:24:02.790 Also ich meine, na neu ist auch nicht mehr agile Methoden, 01:24:02.870 --> 01:24:09.510 aber trotzdem, und in dem Sinne gibt es ja auch was, wo man dann beim Entwickeln direkt sogleich auf dieses 01:24:09.510 --> 01:24:13.270 Testing ein bisschen aufbauen kann oder einbauen kann. 01:24:13.830 --> 01:24:17.430 Dieses Test-Driven Development zum Beispiel. 01:24:17.510 --> 01:24:18.470 Worum geht es denn da? 01:24:18.710 --> 01:24:23.750 Genau, also wir hatten es jetzt von Arten zu testen, jetzt haben wir es, 01:24:23.990 --> 01:24:26.550 komm mal zu Arten, testgetrieben zu entwickeln. 01:24:27.350 --> 01:24:29.830 Ja, der Marc hat schon Luft geholt, willst du? 01:24:31.110 --> 01:24:33.350 Hier gehen Sachen kaputt, ich muss ganz kurz. 01:24:33.590 --> 01:24:33.830 Okay. 01:24:36.150 --> 01:24:36.950 Tests are failing. 01:24:37.110 --> 01:24:37.750 Tests are failing. 01:24:37.990 --> 01:24:40.950 Nee, wirklich, das ist Buttonsnack, der schickt mir Exception Service. 01:24:42.630 --> 01:24:43.750 Da passieren Dinge. 01:24:44.070 --> 01:24:44.870 Dann fange ich mal an. 01:24:44.950 --> 01:24:49.910 Also Test-Driven Development ist im Endeffekt ja die Disziplin, dass du sagst, 01:24:49.990 --> 01:24:56.710 okay, bevor du eine Zeile produktiven Code schreibst willst du erstmal einen Test schreiben, 01:24:57.030 --> 01:25:01.670 der soll fehlschlagen, dann implementierst du deinen Code, 01:25:01.750 --> 01:25:05.750 sodass du diesen Test zufriedenstellst und dann iterierst du dich daran weiter. 01:25:05.830 --> 01:25:12.390 Jedes Mal, wenn du eine neue Bedingung in diesen Code einbaust oder 01:25:12.630 --> 01:25:16.710 wenn du irgendwie ein neues Feature, ein anderes Verhalten dazu implementieren willst, 01:25:18.150 --> 01:25:24.070 updatest du deinen Test oder implementierst du einen neuen und dann implementierst du deinen Code. 01:25:24.230 --> 01:25:31.110 Das hat Gründe, das so zu tun und die sind wahrscheinlich für 01:25:31.110 --> 01:25:32.790 jeden persönlich unterschiedlicher. 01:25:32.950 --> 01:25:38.550 Für mich ist es so, dass es mir hilft, meine API so minimal wie möglich zu halten, 01:25:38.630 --> 01:25:42.630 dass ich sagen kann, okay, ich mache mir gar keine Gedanken, so was wäre wenn, 01:25:42.870 --> 01:25:48.070 weil das kann ich dann in die Zukunft mal zu, in Sachen Refactoring oder Erweiterung, 01:25:48.470 --> 01:25:52.230 kann ich mal zu irgendeinem beliebigen Zeitpunkt in der Zukunft verschieben, 01:25:52.310 --> 01:25:53.830 wenn es denn tatsächlich gebraucht wird. 01:25:53.910 --> 01:25:59.590 Das heißt, ich implementiere immer nur diesen Code, der einen Test zufriedenstellt, 01:25:59.670 --> 01:26:04.230 sodass ich sagen kann, okay, jeder Code, den ich nicht habe und jeder Code, 01:26:04.310 --> 01:26:09.190 der nicht implementiert ist, ist guter Code, weil den muss ich weder testen noch ausführen, 01:26:09.270 --> 01:26:12.630 noch hat er Sicherheitsprobleme, noch hat er sonstige Bugs. 01:26:13.830 --> 01:26:17.030 Aber ist es nicht langweilig, aus keinem Code zu schreiben? 01:26:17.110 --> 01:26:20.630 Nee, nee, das so rumzudenken, weiß ich nicht. 01:26:20.950 --> 01:26:24.150 Nee, das ist tatsächlich, ist es, wenn man das mal, da mal drin ist, 01:26:24.230 --> 01:26:26.870 ist es jedes Mal ein Erfolgserlebnis, da sagt man, oh, zum einen ist. 01:26:27.110 --> 01:26:28.470 Es ist wieder Code nicht geschrieben. 01:26:29.510 --> 01:26:35.910 Zum Beispiel ist es halt auch so, man soll ja tunlichst vermeiden, Testcode zu duplizieren. 01:26:36.710 --> 01:26:41.910 Weil jeder Test, der schon mal einen bestimmten Code-Pfad testet, 01:26:42.230 --> 01:26:47.190 den braucht man nicht doppelt oder dreifach, weil wenn man irgendwann mal was ändert, 01:26:47.270 --> 01:26:50.790 dann muss man halt auch dementsprechend so viele Tests updaten. 01:26:52.790 --> 01:26:56.790 Und das hilft halt auch dabei, die Anzahl der Tests zu reduzieren, dass man sagt, 01:26:56.870 --> 01:27:01.030 okay, ich implementiere jetzt mal einen Test und wenn der Code dazu noch nicht vorhanden ist, 01:27:01.110 --> 01:27:05.990 aber der Test plötzlich trotzdem grün ist und trotzdem durchläuft, dann hat man irgendwie, 01:27:06.310 --> 01:27:13.110 entweder man hat einen Fehler im tatsächlichen Code oder man hat irgendwie sowas 01:27:13.110 --> 01:27:14.150 schon mal implementiert. 01:27:14.390 --> 01:27:17.430 Ja, man hat den neuen Test im Prinzip nicht sauber spezifiziert. 01:27:17.510 --> 01:27:17.670 Genau. 01:27:17.830 --> 01:27:21.430 Also man hat dabei nicht bemerkt, oh genau, also ich habe das schon. 01:27:21.910 --> 01:27:24.390 Oder ich habe das durch einen Nebeneffekt schon. 01:27:24.470 --> 01:27:27.350 Also ich habe das entweder bewusst schon mal gebaut und habe es halt vergessen, 01:27:27.430 --> 01:27:30.550 oder ich habe es durch einen anderen Nebeneffekt, so soll ja Sachen geben, 01:27:30.630 --> 01:27:32.310 die ergeben sich einfach so implizit. 01:27:34.070 --> 01:27:37.670 Was mir noch wichtig ist bei dem Test-Driven Development, ist der Ansatz, 01:27:37.990 --> 01:27:42.870 das ist bisher noch nicht, glaube ich, so ganz rausgekommen, wenn ich so einen Test habe und der schlägt fehl, 01:27:43.030 --> 01:27:47.430 dann benutze ich die simpelste Möglichkeit, den Test grün zu machen. 01:27:47.510 --> 01:27:50.470 Also nehmen wir hier den tollen Debian Random Number Generator. 01:27:50.950 --> 01:27:56.390 Wenn der Test-Case halt sagte, wenn ich das aufrufe, dann muss da hinten eine Zahl rauskommen und ich schreibe 01:27:56.390 --> 01:27:59.590 da Return 5 rein, dann ist der Test erfüllt. 01:27:59.910 --> 01:28:00.230 Okay. 01:28:00.630 --> 01:28:02.470 Also dann ist halt mein Test nicht gut. 01:28:02.710 --> 01:28:07.110 Aber so ist die Vorgehensweise und dann sage ich mir, okay, gut, jetzt muss ich meinen Test irgendwie besser 01:28:07.110 --> 01:28:09.190 machen, also dass er die Aufgabe besser löst. 01:28:09.590 --> 01:28:13.830 Und dann muss ich entsprechend wieder die Implementierung anpassen. 01:28:13.910 --> 01:28:18.950 Also da geht man tatsächlich auch häufig so vor, dass man halt mal relativ einfach anfängt, 01:28:19.030 --> 01:28:22.710 also einfach wie möglich anfängt und sich dann ein bisschen weiter vorhangelt. 01:28:23.830 --> 01:28:25.830 Das klingt erstmal ein bisschen langweilig, stimmt. 01:28:25.990 --> 01:28:29.590 Das klingt auch langsam, weil man viel Testcode schreibt. 01:28:29.910 --> 01:28:33.270 Aber die persönliche Erfahrung ist zum Beispiel auch die, wenn ich das mache, 01:28:33.430 --> 01:28:36.630 wenn ich das gewohnt bin, dann bin ich vielleicht ein Ticken langsamer, 01:28:36.950 --> 01:28:38.070 aber dafür stetiger. 01:28:38.310 --> 01:28:42.150 Also ich komme beständiger voran, weil jeder kennt das, wenn der Coach schreibt, 01:28:42.230 --> 01:28:46.310 dann schreibt man irgendwie kurz 20, 30 Zeilen oder 200, 300 Zeilen der Klasse irgendwie zusammen, 01:28:46.390 --> 01:28:49.990 die macht irgendwie Voodoo Magic ganz viel, ganz schnell, ganz toll. 01:28:50.950 --> 01:28:55.670 Aber dann, wenn man auf einmal irgendwie dann noch Funktionalität X reinbauen soll, 01:28:56.470 --> 01:28:59.670 denkt man sich, oh verdammt, ich hab mir das gar nicht so gedacht dabei. 01:28:59.750 --> 01:29:04.870 Und wenn man stattdessen in dem kontinuierlichen Prozess drin ist, dass man sich überlegen muss, 01:29:05.830 --> 01:29:10.070 wie man das Ganze weitergestaltet, dass man, dass man die ganze Zeit, 01:29:10.470 --> 01:29:14.870 also dass es eher so ein, sag ich mal, dass es eher so ein Marathon ist als ein Sprint, 01:29:15.430 --> 01:29:18.950 dann ist das eine eigentlich ja sehr, sehr zufriedenstellende Arbeitsweise. 01:29:19.110 --> 01:29:22.630 Also es klingt erstmal langweilig, aber es ist halt hochproduktiv im Endeffekt nachher. 01:29:23.350 --> 01:29:27.590 Es hat zudem halt auch noch den Nebeneffekt, das hat zwei Nebeneffekte. 01:29:27.670 --> 01:29:30.630 Zum einen haben wir vorhin schon gesagt, jeder Test, den du schreibst, 01:29:30.710 --> 01:29:35.030 ist eine Wiederverwendung von bestehend Code, nämlich dem Code, den du testest. 01:29:35.590 --> 01:29:40.630 Das heißt, dein Test wird automatisch, dadurch, dass er getestet oder testbar ist, 01:29:42.070 --> 01:29:46.070 eher flexibler und eher besser wiederverwendbar. 01:29:46.950 --> 01:29:51.910 Der zweite Fall ist dadurch, dass du, was wollte ich denn jetzt eigentlich sagen? 01:29:51.990 --> 01:29:54.870 Ich glaube, ich habe schon ein paar Faden verloren. 01:29:55.350 --> 01:29:57.190 Ich bin gerade am überlegen. 01:29:58.230 --> 01:29:59.030 Ich bin gleich wieder da. 01:29:59.670 --> 01:30:00.790 Redet einfach mal kurz weiter. 01:30:01.110 --> 01:30:02.310 Ich denke nochmal kurz drüber. 01:30:02.550 --> 01:30:04.630 Du warst gerade mit dem Satz, wir können dich jetzt nicht abbrechen. 01:30:04.710 --> 01:30:05.670 Ich weiß, ich weiß. 01:30:07.030 --> 01:30:10.070 Ich habe gerade meinen Faden verloren. 01:30:12.630 --> 01:30:13.830 Ich habe nicht mehr gute Tests fahren. 01:30:14.710 --> 01:30:18.870 Also was bei dem Test-Driven Development eben wichtig festzustellen, 01:30:18.950 --> 01:30:25.350 ist eben, dass ich eben genau so vorgehe, dass ich erst Tests schreibe und dann produktiven Code, 01:30:25.590 --> 01:30:29.830 was eben auch mich schon mal davor bewahrt, keine Tests zu schreiben. 01:30:30.310 --> 01:30:33.190 Das klingt jetzt erstmal simpel, aber das passiert nachher eben ganz häufig, 01:30:33.270 --> 01:30:37.190 dass man den Code erst schreibt und sagt, ach was, da brauche ich keine Tests für. 01:30:37.430 --> 01:30:40.710 Beim TDD geht es halt genau so rum los, dass man den Test schreibt. 01:30:40.790 --> 01:30:43.590 Das heißt, man hat den, man hat mindestens ein bisschen Test. 01:30:44.310 --> 01:30:49.590 Und das ein bisschen Test sorgt eben dafür, dass man den Rest, wie wir schon mehrfach festgestellt haben, 01:30:49.830 --> 01:30:53.830 den Rest dann auch so schreibt, dass es weiter in die Richtung geht. 01:30:54.390 --> 01:31:00.550 Und aus persönlicher Erfahrung ist das eben ein ganz guter Start, so rum anzufangen, 01:31:00.870 --> 01:31:03.750 das nicht von vornherein unter den Tisch fallen zu lassen. 01:31:05.030 --> 01:31:08.230 Mir ist mittlerweile auch mein Faden wieder begegnet. 01:31:08.470 --> 01:31:08.790 Das ist gut. 01:31:09.110 --> 01:31:10.870 Jetzt hätte ich jetzt anfangen müssen zu tanzen, oder? 01:31:11.430 --> 01:31:12.950 Aber das können die Leute doch gar nicht sehen. 01:31:13.430 --> 01:31:19.350 Was ich nämlich sagen wollte, ist der zweite große Faktor oder der zweite große Vorteil, 01:31:19.590 --> 01:31:25.750 wenn man Testgetrieben entwickelt, ist, wenn, dass man auch dann gleich schon mal 01:31:25.750 --> 01:31:29.350 automatisiert, was heißt nicht automatisiert, aber dass man gleich im Prozess, 01:31:29.430 --> 01:31:33.350 während man einen Test implementiert, sich Gedanken drüber machen muss, 01:31:33.430 --> 01:31:36.710 wie soll denn eigentlich meine Schnittstelle, die ich jetzt da testen will, 01:31:36.790 --> 01:31:37.510 aussehen. 01:31:37.750 --> 01:31:41.830 Das heißt, du, allein dadurch, dass du da schon mal den Code runterschreibst und denkst, 01:31:41.910 --> 01:31:45.750 oh, wie soll denn jetzt mal meine API aussehen und wie soll sie sich verhalten, 01:31:46.310 --> 01:31:51.510 fallen dir Inkonsistenzen auf, da fallen dir Probleme auf, da fallen dir Sachen auf, 01:31:51.670 --> 01:31:54.470 dass man denkt, oh, da übergebe ich jetzt aber ganz schön viele Parameter, 01:31:54.550 --> 01:31:57.750 das kann ich mir ja eigentlich gar nicht merken, wenn ich das irgendwann mal benutzen will. 01:31:57.910 --> 01:32:00.550 Oder das fühlt sich irgendwie unintuitiv an oder sowas. 01:32:00.630 --> 01:32:07.430 Da kann man dann quasi schon, bevor man überhaupt seinen Produktivcode schreibt und dann später bemerkt, 01:32:07.510 --> 01:32:12.230 oh, der lässt sich jetzt aber ganz schön blöde benutzen, bekommt man schon mal ein Gefühl dafür, 01:32:12.310 --> 01:32:14.550 wie es denn aussehen wird, den zu benutzen. 01:32:14.710 --> 01:32:19.110 Und das ist halt auch schon ein ganz schöner Vorteil, wenn man Tests hat. 01:32:19.430 --> 01:32:23.270 Oder wenn man Tests, wenn man vor allem die Tests zuerst schreibt. 01:32:25.110 --> 01:32:28.470 Genau, was ich mir auch noch notiert habe, was du jetzt auch schon erwähnt hast, 01:32:28.550 --> 01:32:33.590 Matt, ist so dieses Test-Driven Development versus Spike-Coding. 01:32:33.750 --> 01:32:36.950 Also ich meine, das haben auch sehr erfahren Entwickler ab und zu, dass sie mal sagen, 01:32:37.030 --> 01:32:39.430 okay, ich muss jetzt irgendwas ausprobieren, da habe ich keinen Nerv dafür, 01:32:39.590 --> 01:32:40.550 Tests zu schreiben. 01:32:40.870 --> 01:32:45.510 Dann sollte man das aber vielleicht in einem extra Branch machen, den man danach wieder löscht. 01:32:45.590 --> 01:32:49.270 Das heißt, man sagt, okay, ich möchte jetzt eine Idee ausprobieren, 01:32:49.510 --> 01:32:53.030 da möchte ich, ich bin gerade total kreativ, ich habe gerade total Bock, 01:32:53.110 --> 01:32:54.230 ich bin super motiviert. 01:32:54.470 --> 01:32:58.230 Dann mache ich mir in meinem Versionskontrollsystem einen neuen Branch auf, 01:32:58.470 --> 01:33:04.630 implementiere das Zeug mal komplett dreckig runter und dann switche ich wieder zu einem anderen Branch, 01:33:05.110 --> 01:33:09.270 habe im Kopf, wie es denn funktionieren soll, und fange dann an, die Tests zu implementieren, 01:33:09.350 --> 01:33:14.550 dass man sagt, okay, oder im Zweifelsfall könnte man es auch so machen, 01:33:14.630 --> 01:33:17.510 dass man sagt, okay, ich habe jetzt mal hier so einen Produktivitätsspike, 01:33:17.750 --> 01:33:20.870 ich implementiere mal ein paar hundert Zeilen Code runter, ich schraube die Tests danach, 01:33:20.950 --> 01:33:25.830 das sorgt aber im Zweifelsfall dafür, dass du bei den Tests was vergisst, 01:33:25.990 --> 01:33:29.270 dass deine Test-Coverage schlechter wird, dass du Code implementierst, 01:33:29.430 --> 01:33:34.870 den du vielleicht gar nicht brauchen würdest, weil er gar nicht irgendwie benötigt wird. 01:33:36.950 --> 01:33:43.590 Daher ist es eigentlich, also es ist halt so ein Disziplinding, wenn man damit mal angefangen hat und damit 01:33:43.590 --> 01:33:50.470 gute Erfahrungen macht, dann macht man das auch gerne und oft und ständig 01:33:50.710 --> 01:33:54.310 und erwartet es von seiner Arbeitsumgebung sogar, dass man dann sagt, 01:33:54.390 --> 01:33:58.390 okay, ich möchte jetzt Testgetrieben entwickeln und wenn mir da jemand irgendwie Steine in den Weg wirft, 01:33:58.470 --> 01:34:00.870 dann suche ich mir halt einen anderen Job oder sowas. 01:34:02.790 --> 01:34:06.230 Aber ich meine, es kann auch die Fälle den Fall geben, dass man sagt, 01:34:06.310 --> 01:34:13.190 okay, ich möchte jetzt einfach mal ein Ergebnis sehen und der andere Weg ist dir zu langweilig 01:34:13.430 --> 01:34:15.430 oder zu langwierig, sagen wir so. 01:34:15.670 --> 01:34:21.590 Ja, ich meine, es gibt ja neben diesen Test-driven Development auch noch andere Wege, 01:34:21.910 --> 01:34:24.070 zum Beispiel Behavior-Driven Development. 01:34:24.310 --> 01:34:24.710 Genau. 01:34:25.510 --> 01:34:31.190 Ist im Endeffekt die andere Seite der Test-Driven Development Medaille. 01:34:31.510 --> 01:34:37.670 Also man, Behavior-Driven Development, da geht man im Endeffekt nicht von einer Unit als 01:34:37.990 --> 01:34:44.950 einzelnes Element aus, sondern man fängt halt mal an, äußere Funktionalität zu 01:34:44.950 --> 01:34:45.430 definieren. 01:34:45.750 --> 01:34:51.590 Wie soll denn mein, also wie soll mein System an den äußeren Grenzen funktionieren und nicht in den inneren 01:34:51.590 --> 01:34:52.790 Kernklassen? 01:34:53.270 --> 01:34:58.230 Und dann löst man das im Endeffekt so, dass man sagt, okay, ich tue jetzt mal erstmal meine äußeren APIs 01:34:58.230 --> 01:35:03.590 definieren, ersetzt dann die ganzen anderen Elemente durch Mocks oder Stubs, 01:35:04.070 --> 01:35:09.910 kommen wir später noch dazu, was das ist, und fängt dann an, 01:35:09.990 --> 01:35:15.670 quasi sich von außen nach innen zu arbeiten und sein System auch von außen nach innen zu implementieren, 01:35:15.750 --> 01:35:21.750 statt dass man sagt, okay, ich fange jetzt mit den inneren Komponenten an und arbeite mich dann nach außen. 01:35:21.990 --> 01:35:27.590 Also ist vielleicht, wenn man dann sagt, okay, man kann sich das jetzt in der physikalischen Welt schlecht 01:35:27.590 --> 01:35:33.030 vorstellen, weil keiner baut ein Auto von außen nach innen oder irgendwie ein Haus oder sonst irgendwas. 01:35:35.190 --> 01:35:36.870 Aber doch, ja. 01:35:37.110 --> 01:35:37.830 Denke ich schon, oder? 01:35:37.990 --> 01:35:38.310 Zum Beispiel? 01:35:39.030 --> 01:35:41.750 Jetzt baust du die Karosserie und dann baust du den Shit da drin oder so? 01:35:41.910 --> 01:35:43.750 Ja, aber du baust ja die Karosserie. 01:35:43.990 --> 01:35:46.470 Du brauchst ja auch erst die Wände und dann machst du ihn rein. 01:35:46.550 --> 01:35:50.710 Ja, aber du baust ja irgendwie den Keller und sonst irgendwas und die Leitung musst du ja reinziehen und dann 01:35:50.710 --> 01:35:52.390 ziehst du irgendwann Wände rein und dann. 01:35:53.030 --> 01:35:54.470 Du machst erst die Leitung und dann mit der Rednerin. 01:35:54.630 --> 01:35:56.150 Ja, die Wände, nee, egal, egal. 01:35:56.550 --> 01:35:58.470 Drahtgerüst und dann die Wände drumrum. 01:35:59.030 --> 01:36:03.510 Ja, okay, also wir haben vielleicht teilweise Beispiele, wo sowas funktioniert. 01:36:05.590 --> 01:36:08.790 Ist ja auch Softentwicklung, muss ja nicht immer was mit der reellen Welt zu tun haben. 01:36:10.950 --> 01:36:13.430 Aber ist nicht Software meistens eine Abbildung? 01:36:13.830 --> 01:36:18.630 Also man kann es nicht, weil das ist ja das, was du nicht in Hardware machen willst, kannst oder musst. 01:36:18.870 --> 01:36:21.510 Ja, aber doch, ich glaube, so ein Haus ist vielleicht eine ganz gute Analogie. 01:36:21.590 --> 01:36:27.030 Man baut erst die Wände außenrum, dann zieht man da Sachen rein und dann baut man erst letzten Endes so die 01:36:27.030 --> 01:36:29.750 Küche rein und das Bad und sonstige Geschichten. 01:36:29.910 --> 01:36:35.910 Und du fängst ja nicht damit an, ein Bad zu bauen und eine Küche und sonst irgendwas und baust dann irgendwann 01:36:35.910 --> 01:36:36.790 das Haus außen rum. 01:36:36.950 --> 01:36:40.390 Daher ist die Analogie vielleicht gar nicht so schlecht. 01:36:41.350 --> 01:36:42.230 Genau. 01:36:45.670 --> 01:36:48.390 Dann hatten wir noch Feature-Driven Development. 01:36:48.710 --> 01:36:51.030 War das dein Thema, Marc? 01:36:51.350 --> 01:36:53.190 Ich habe es reingeschrieben, aber ich habe keine Ahnung davon. 01:36:53.430 --> 01:36:54.310 Feature-driven. 01:36:55.510 --> 01:36:57.350 Das klingt ein bisschen wie halt die Q-Commer-Geschichte, wo du sagst. 01:36:57.910 --> 01:37:02.470 Es könnte vielleicht sowas wie Behavior-Driven Development sein, auf Feature-Basis. 01:37:03.190 --> 01:37:05.430 Also ich kann mir es vielleicht so vorstellen, dass man sagt, okay, 01:37:05.510 --> 01:37:09.510 man hat jetzt eine User-Story, die einen Feature wieder gibt. 01:37:09.750 --> 01:37:13.670 Also gerade so die Geschichten, die wir vorhin schon hatten, ich bin jetzt ein User und ich klicke auf diesen 01:37:13.670 --> 01:37:15.910 Button und dann will ich, dass mein Bildschirm rot wird. 01:37:16.790 --> 01:37:17.830 Vielleicht sowas. 01:37:17.990 --> 01:37:21.270 Aber Feature-Driven Development ist mir tatsächlich noch nicht besonders oft untergekommen. 01:37:21.430 --> 01:37:22.950 Vielleicht sollten wir noch nicht weiter drüber reden. 01:37:24.230 --> 01:37:25.990 Könnt ihr euch das in der Wikipedia durchleben. 01:37:26.230 --> 01:37:30.630 Wir entwickeln ja alle Features, von dem her ist alles irgendwie Feature-Driven Development. 01:37:33.670 --> 01:37:38.070 Ja, ihr habt die ganze Zeit vorhin schon über Mogs und sowas geredet. 01:37:38.390 --> 01:37:42.710 Vielleicht kommen wir dazu als nächstes, was heißt das? 01:37:43.670 --> 01:37:45.510 Also wie kann ich mir das vorstellen? 01:37:45.590 --> 01:37:51.270 Ich baue mir irgendwas zusammen, was dann schon mal so ein bisschen Abbild gibt. 01:37:51.510 --> 01:37:58.070 Oder ich damit ich es dann so später richtig baue. 01:37:58.230 --> 01:38:01.110 Also ich male mir erstmal was und mache es dann richtig oder so? 01:38:01.430 --> 01:38:04.630 Genau, also wir hatten ja vorher bei den Unit-Tests, hat Flydy erwähnt, 01:38:04.790 --> 01:38:07.270 dass die im Idealfall in Isolation sind. 01:38:07.350 --> 01:38:11.510 Also ich teste im Idealfall wirklich nur, was die Klasse tut. 01:38:11.910 --> 01:38:16.150 Jetzt wäre Software natürlich langweilig, wenn alles immer nur etwas tun würde, 01:38:16.230 --> 01:38:19.110 sondern das Entscheidende ist ja dann, dass es irgendwann was zusammentut. 01:38:19.350 --> 01:38:23.590 Also habe ich Abhängigkeiten voneinander und die kann ich nur bis zu einem gewissen Grad, 01:38:23.670 --> 01:38:27.990 sag ich mal, rauslösen, sodass jedes für sich eigenständig ist. 01:38:28.070 --> 01:38:34.630 Und mit einem Stup und einem Mock wird es mir ermöglicht, in einem Test mir gewisse Teile meines 01:38:34.630 --> 01:38:39.670 Environments, so wie ich sie brauche, so wie ich von ihnen ausgehe, 01:38:39.990 --> 01:38:40.870 hinzustellen. 01:38:41.030 --> 01:38:43.270 Also zu simulieren gewissermaßen. 01:38:43.350 --> 01:38:47.030 Also beispielsweise die Datenbank, ja, also ich eine Persistenzschicht. 01:38:47.430 --> 01:38:51.990 Ich brauche einfach in meiner Unit brauche ich eine Möglichkeit, Sachen in was zu speichern. 01:38:52.070 --> 01:38:57.030 Es ist mir aber egal, ob das nachher in eine Datenbank gespeichert wird oder einfach nur irgendwie in einen 01:38:57.510 --> 01:38:59.910 Key-Value-Store irgendwie in einem Objekt. 01:39:00.790 --> 01:39:03.590 Und weil ich das einfach in dem Aspekt nicht testen will. 01:39:03.670 --> 01:39:06.790 Ich muss da jetzt aber irgendwas reinreichen, weil sonst die Klasse nicht funktioniert, 01:39:06.870 --> 01:39:09.510 weil ich das so gebaut habe und weil es nicht anders geht. 01:39:09.670 --> 01:39:16.230 Und jetzt kann ich mir mit einem Stub oder einem Mock entsprechend das Environment so ein Stück weit 01:39:16.230 --> 01:39:16.630 simulieren. 01:39:16.710 --> 01:39:18.950 Also ich tue so, als hätte ich die Datenbank. 01:39:19.110 --> 01:39:19.590 Genau. 01:39:19.910 --> 01:39:22.630 Oder sagen wir mal vielleicht noch ein einfacheres Beispiel. 01:39:23.510 --> 01:39:28.790 Wir haben eine Klasse, die benötigt eine Datei, 01:39:29.430 --> 01:39:34.150 aus der sie Dinge lesen kann, um zum Beispiel, was weiß ich, einen Blogpost zu generieren. 01:39:34.710 --> 01:39:38.070 Dann haben wir schon gesagt, okay, wir wollen das Ding in Isolation testen. 01:39:38.150 --> 01:39:44.710 Das heißt, man übergibt quasi eine Referenz zu diesem Dateiobjekt beim Erstellen der Klasse als 01:39:44.710 --> 01:39:51.670 Parameter mit und sagt dann, okay, ich habe jetzt hier irgendwas, das antwortet 01:39:51.670 --> 01:39:54.470 auf den Message Call. 01:39:55.610 --> 01:39:56.330 Read zum Beispiel. 01:39:56.490 --> 01:39:58.570 Man hat eine Datei, aus der kann man lesen. 01:39:58.890 --> 01:40:03.610 Und wenn ich jetzt von Message Call oder Message Send rede, dann meine ich so viel wie ein Methodenaufruf. 01:40:03.690 --> 01:40:09.050 Also es wird auch gerne als MessageSend bezeichnet, weil im Endeffekt da eine Nachricht an ein Objekt 01:40:09.050 --> 01:40:10.010 geschickt wird. 01:40:11.530 --> 01:40:14.970 Und jetzt kann man halt sagen, okay, ich möchte einfach nur irgendwie, 01:40:15.210 --> 01:40:18.250 ich implementiere mir jetzt vielleicht in meinem Test. 01:40:19.130 --> 01:40:20.330 Kann man machen. 01:40:20.570 --> 01:40:26.090 Eine Klasse, die nenne ich jetzt zum Beispiel FileMock und die hat nur eine Methode read und die gibt einen 01:40:26.090 --> 01:40:29.770 definierten String, den ich zum Testen muss, zurück. 01:40:30.090 --> 01:40:36.090 Das wäre dann, naja, das wäre schon wieder die falsche Bezeichnung. 01:40:36.250 --> 01:40:41.610 Es müsste nämlich FileStub heißen, weil ein Stub ist im Endeffekt ein Objekt, 01:40:41.770 --> 01:40:47.370 was das Verhalten von einem richtigen Objekt in einem richtigen System simuliert, 01:40:48.170 --> 01:40:49.530 aber eben nur das. 01:40:50.010 --> 01:40:54.730 Wohingegen ein Mog tatsächlich die ein Message-Send verifiziert. 01:40:54.810 --> 01:41:01.370 Das heißt, der wirft dann auch einen Fehler, wenn nach dem Test eine bestimmte Methode bei diesem Mog-Objekt 01:41:01.370 --> 01:41:02.490 nicht aufgerufen wurde. 01:41:02.810 --> 01:41:07.450 Oder du kannst auch sagen, es soll irgendwie mindestens achtmal die Methode Blub aufgerufen worden sein, 01:41:07.530 --> 01:41:08.330 wenn ich fertig bin. 01:41:08.810 --> 01:41:09.210 Genau, genau. 01:41:09.530 --> 01:41:10.970 Im Grunde hält der auch nur Counter. 01:41:11.050 --> 01:41:14.730 Also ich habe jetzt nichts anderes in einem Mock gesehen, bis auf das der halt zählt. 01:41:16.650 --> 01:41:18.250 Ich kann auch Input-Parameter validieren. 01:41:18.330 --> 01:41:22.490 Du kannst zum Beispiel validieren, also wenn ich jetzt irgendwie die Klasse File mit einem neuen Dateinamen 01:41:22.570 --> 01:41:27.850 oder so aufrufe, dann kann ich auch validieren, dass die Methode, mit der und den Parametern aufgerufen wurde, 01:41:28.010 --> 01:41:28.650 beispielsweise. 01:41:29.450 --> 01:41:34.570 Also das ist halt immer eine Sache des entsprechenden Testing, Stubbing und Mocking-Frameworks, 01:41:34.650 --> 01:41:35.610 was es mir anbietet. 01:41:35.770 --> 01:41:42.010 Genau, also was man mit einem Mock macht, ist, man validiert die Message-Sends zu einer 01:41:42.010 --> 01:41:47.850 Abhängigkeit in seiner Unit, um jetzt mal maximal viele Fachworter zu benutzen. 01:41:48.490 --> 01:41:52.330 Was man tatsächlich auch machen kann, es gibt Mocking-Frameworks, die können so, 01:41:53.290 --> 01:41:57.290 ich weiß jetzt gar nicht, wie nennt man das, die können so Abläufe definieren. 01:41:57.370 --> 01:42:03.290 Also du kannst sagen, ich möchte, dass bei diesem Objekt zuerst Methode A mit Parametern XY, 01:42:03.610 --> 01:42:08.090 dann Methode B mit Methode XY und dann Methode C mit Parametern, 01:42:08.250 --> 01:42:15.210 was weiß ich, AB aufgerufen werden in genau dieser Reihenfolge und dann bekommst du halt im Endeffekt einen 01:42:15.210 --> 01:42:21.610 Fehler, wenn deine Tests laufen, der Test Case ist abgeschlossen und 01:42:22.250 --> 01:42:28.890 die Methoden deiner Dependency wurden dann nicht in dieser Reihenfolge aufgerufen. 01:42:30.650 --> 01:42:34.970 Genau, also das ist im Endeffekt, also Stubs und Mocs, da gibt es dann letzten Endes, 01:42:35.290 --> 01:42:38.330 könnte man sich das eigentlich auch selber bauen, da gibt es aber halt Frameworks, 01:42:38.410 --> 01:42:42.090 die einem die Arbeit abnehmen, da sagt man dann halt je irgendwo nur noch Methodenaufruf, 01:42:42.170 --> 01:42:46.330 irgendwie bla Mock oder Mock.new oder NewMock oder was auch immer, je nachdem, 01:42:46.410 --> 01:42:48.490 was für eine Programmiersprache man verwendet. 01:42:48.890 --> 01:42:51.210 Und dann wird schon das Richtige passieren. 01:42:51.770 --> 01:42:55.530 Also ein Anwendungsfall für speziell zum Beispiel jetzt einen Stub, 01:42:55.850 --> 01:42:58.890 den wir noch nicht angesprochen hatten, ist auch, wir hatten jetzt den Fall, 01:42:58.970 --> 01:43:02.810 okay, die Abhängigkeiten sind zu komplex und ich muss mir deshalb einen Stub davon ziehen, 01:43:02.970 --> 01:43:05.210 statt das komplette System anzubinden. 01:43:05.450 --> 01:43:09.210 Der andere Anwendungsfall ist der, oder ein anderer Anwendungsfall ist der. 01:43:09.610 --> 01:43:11.770 Na, das andere System gibt es noch nicht. 01:43:12.090 --> 01:43:16.730 Also gerade so, wir haben irgendwie zehn Entwickler-Teams und die einen arbeiten halt an der 01:43:16.730 --> 01:43:19.930 Datenbankpersistenz und die Persistenz ist einfach nur nicht fertig. 01:43:20.250 --> 01:43:23.050 Ich brauche aber das in meinem Code schon, weil ich möchte ja schon verifizieren, 01:43:23.130 --> 01:43:28.490 dass wenn sie dann nachher da ist, also dass die anderen Module funktionieren und auch damit funktionieren. 01:43:28.570 --> 01:43:31.130 Und dann kann ich mir auch das super hinstabben bzw. 01:43:31.450 --> 01:43:36.010 hinmocken, ja, um das so testen zu können. 01:43:36.250 --> 01:43:41.130 Genau, also hatten wir ja vorhin auch, wenn man dann sagt, okay, ich habe jetzt Behavior-Driven Development 01:43:41.130 --> 01:43:44.330 und ich fange mal an, meine Anwendung von außen nach innen zu bauen, 01:43:44.490 --> 01:43:51.050 dann kann ich halt auch sagen, okay, ich definiere jetzt erstmal die APIs an meiner Applikationsgrenze 01:43:52.890 --> 01:43:57.930 und fange dann quasi an, alle Abhängigkeiten erstmal durch MOX zu ersetzen, 01:43:58.090 --> 01:43:59.930 die ich dann erst später implementiere. 01:44:00.010 --> 01:44:04.170 Weil durch Mox ersetzen muss ich sie so oder so, weil wir schreiben ja Unit-Tests. 01:44:05.930 --> 01:44:10.650 Aber so kann man dann halt auch sagen, okay, wenn ich jetzt außen anfange und mich nach innen arbeite, 01:44:10.810 --> 01:44:13.530 dann gibt es dieses Innen ja eigentlich noch nicht. 01:44:13.610 --> 01:44:16.890 Und alles, was halt weiter innen als die Unit, die man gerade testet, 01:44:17.210 --> 01:44:21.930 liegt, wird man dann halt dementsprechend durch Mocs oder Stubs ersetzen. 01:44:22.090 --> 01:44:26.330 Genau, also so mal auf unser Themengebiet speziell zugeschnitten, 01:44:26.410 --> 01:44:31.130 so ich gehe davon aus, ich simuliere einen Internetanschluss, den wird es bestimmt nach ergeben. 01:44:31.690 --> 01:44:38.490 Ist ja Deutschland hier und darauf basierend kann ich dann die komplette Lichtsteuerung im Haus, 01:44:38.570 --> 01:44:44.170 die über Internet funktioniert oder die Heizungssteuerung entsprechend schon planen und bauen. 01:44:46.010 --> 01:44:46.970 Ich bin übrigens wieder da. 01:44:47.130 --> 01:44:47.850 Ja, das ist schön. 01:44:50.010 --> 01:44:51.530 Funktioniert dein Test wieder. 01:44:52.410 --> 01:44:53.770 Er wirft keine Feder mehr. 01:44:54.890 --> 01:44:56.090 Alles weggestuppt. 01:44:56.890 --> 01:45:00.650 Okay, sind Stub und Mox jetzt irgendwie durch die Stadt. 01:45:00.890 --> 01:45:05.770 Ja, ich glaube, das Wichtige ist, Mox validieren Message Sends, Stubbs nicht. 01:45:06.090 --> 01:45:07.690 Was sind Data Factories? 01:45:08.490 --> 01:45:11.690 Das habe ich mal ein bisschen so reingeschrieben. 01:45:12.570 --> 01:45:15.690 Es gibt Libraries, mit denen man quasi, also es gibt das, glaube ich, 01:45:15.770 --> 01:45:18.970 für Ruby hauptsächlich, da gibt es so eine Library, gerade für Testing, 01:45:19.050 --> 01:45:20.410 die nennt sich Factory Girl. 01:45:20.650 --> 01:45:26.010 Da kann man und damit kann man quasi relativ einfach 01:45:29.050 --> 01:45:35.690 Stub-Objekte definieren, aus denen aber tatsächliche Klassen und Methoden und sonst was generiert werden. 01:45:35.770 --> 01:45:41.850 Also das ist quasi so Metaprogramming auf die Spitze getrieben, 01:45:42.010 --> 01:45:48.490 nämlich indem man so eine komplette Objektstruktur quasi bauen kann, 01:45:48.570 --> 01:45:51.770 indem man eine programmatische Beschreibung davon hat. 01:45:52.090 --> 01:45:54.410 Und die für Testzwecke benutzen kann. 01:45:56.650 --> 01:46:00.410 Was man ansonsten gerne macht, ist halt sowas wie Fixtures zu benutzen. 01:46:00.490 --> 01:46:07.130 Das heißt, ich habe vielleicht schon bestimmte Klassen für Tests allein vordefiniert oder bestimmte Dateien, 01:46:07.210 --> 01:46:13.610 aus denen ich lesen will oder bestimmte sonstige Dinge, die halt als Datei im Dateisystem vorliegen, 01:46:14.090 --> 01:46:18.490 die ich dann halt selektiv in meinen Tests lade, 01:46:18.570 --> 01:46:19.850 um damit irgendwelche Dinge zu tun. 01:46:20.090 --> 01:46:24.090 Wir kommen nachher kommen auch noch zu, gerade HTTP bietet sich natürlich da total für an, 01:46:24.170 --> 01:46:27.370 weil das ja ein zustandsloses Protokoll ist. 01:46:27.690 --> 01:46:33.690 Bedeutet, da kannst du quasi Fixtures so interpretieren, als dass du das komplette HTTP-Antwort-Paket schon 01:46:33.690 --> 01:46:38.970 vorformuliert nimmst und dann quasi nicht wirklich mit deinem Web-Service sprichst, 01:46:39.050 --> 01:46:45.610 sondern dass du einfach quasi deine HTTP-Library vorspielst, 01:46:45.770 --> 01:46:46.650 dass sie das tun würde. 01:46:46.730 --> 01:46:49.930 Aber da kommen wir gleich noch dazu, vielleicht etwas genauer. 01:46:50.250 --> 01:46:57.050 Okay, also um jetzt tatsächlich Test getrieben zu entwickeln oder überhaupt 01:46:57.050 --> 01:47:01.850 Tests zu schreiben, unterstützen mich die vielen Programmiersprachen ja mit bestimmten Frameworks, 01:47:01.930 --> 01:47:02.730 die es einfach schon gibt. 01:47:02.810 --> 01:47:06.330 Also ich muss mir nicht alles neu, ich muss das Rad nicht immer wieder neu erfinden, 01:47:06.410 --> 01:47:10.330 sondern da gibt es einfach schon bestimmte Programme, die helfen dabei. 01:47:10.730 --> 01:47:15.690 Ich würde sagen, wir gehen mal so ein paar Programmiersprachen durch und sagen vielleicht, 01:47:15.850 --> 01:47:21.210 welche Frameworks es da gibt, vielleicht ein bisschen was die tun oder welche ihr da benutzt. 01:47:21.370 --> 01:47:24.570 Fangen wir vielleicht mit unserer Lieblingsprogrammiersprache Java an. 01:47:24.810 --> 01:47:28.170 Oder vielleicht mit der Die neu mitgebrachte Lieblingsprogrammiersprache. 01:47:28.410 --> 01:47:30.090 Ja, du magst sie besonders, oder wie? 01:47:30.650 --> 01:47:34.490 Nein, du magst sie zwangsweise lange verwenden. 01:47:34.650 --> 01:47:36.330 Ja, okay, ich bin hier der Java entwickelt. 01:47:36.410 --> 01:47:36.970 Ja, ja, klar. 01:47:37.050 --> 01:47:37.770 Das ist nichts. 01:47:37.850 --> 01:47:38.650 Eine muss es sein. 01:47:39.130 --> 01:47:45.930 Die traurige Geschichte ist ja, glaube ich, dass wir so als kleinster gemeinsamer Nenner wahrscheinlich alle 01:47:46.650 --> 01:47:47.130 Shell. 01:47:47.290 --> 01:47:47.770 Alle mögen. 01:47:49.610 --> 01:47:52.010 Kein Windows verwenden, der Shell mögen. 01:47:53.210 --> 01:48:00.090 Ich glaube, so die Programmiersprache, mit der viele von uns so im gemeinsamen relativ 01:48:00.090 --> 01:48:02.970 viel Zeit verbracht haben, ist halt zwangsweise Java. 01:48:03.370 --> 01:48:08.650 Auch beruflich, weil es ist halt echt so, dass viele Team einfach Java einsetzen. 01:48:08.890 --> 01:48:09.610 Ich nicht, ich nicht. 01:48:09.690 --> 01:48:14.650 Jeder, der irgendwas mit Informatik einfach studiert hat oder gelernt hat oder so, 01:48:14.890 --> 01:48:17.690 der hat, glaube ich, zwangsweise mit Jar Himmeis-Changer. 01:48:18.250 --> 01:48:20.010 Da gibt es ja auch ganz coole Software drin. 01:48:20.090 --> 01:48:20.970 Also immer meine ich. 01:48:21.290 --> 01:48:23.290 Also zum Beispiel Elasticsearch. 01:48:23.450 --> 01:48:24.730 Elasticsearch ist ziemlich cool. 01:48:25.050 --> 01:48:25.850 Alles, was Java ist. 01:48:26.090 --> 01:48:26.490 Das war's. 01:48:28.010 --> 01:48:30.090 Aber hey, das ist besser als nichts. 01:48:31.290 --> 01:48:34.330 Lucine, was in Elasticsearch drinsteckt, soll recht gut sein. 01:48:34.570 --> 01:48:35.930 Cassandra ist ein JavaGuin. 01:48:36.090 --> 01:48:37.130 Cassandra ist ganz okay. 01:48:37.610 --> 01:48:37.930 Zwei. 01:48:38.090 --> 01:48:38.410 Zwei. 01:48:41.050 --> 01:48:42.410 Es gab noch dieses File-Sharing-Dings. 01:48:42.810 --> 01:48:43.130 Ja, genau. 01:48:46.970 --> 01:48:49.530 Genau, ich habe eigentlich eher dieses One-Swarm gemeint. 01:48:50.010 --> 01:48:51.530 Achso, das ist ja auf Azurios aufgesetzt. 01:48:51.930 --> 01:48:53.050 Aber das war auch ein Riesencancer. 01:48:53.770 --> 01:48:57.050 Holy shit, das war der größte fucking Java-Canner, den ich mir vorstellen kann. 01:48:58.090 --> 01:49:00.170 Die meisten Bitcoin-Wallets mit Java. 01:49:00.570 --> 01:49:02.570 Ja, Minecraft kommt jetzt gerade aus dem Chat. 01:49:02.890 --> 01:49:05.850 Es gibt Bitcoin-Wallets, aber die offiziellen sind C ⁇ . 01:49:06.490 --> 01:49:06.970 Oder einige. 01:49:08.410 --> 01:49:11.050 Ja, also es gibt Leute, die benutzen Java und da ist es halt auch. 01:49:11.210 --> 01:49:12.570 Es gibt viele Leute, die benutzen Java. 01:49:12.970 --> 01:49:13.930 Sehr viele Leute tatsächlich. 01:49:14.490 --> 01:49:19.050 Und da ist es halt, wäre es halt auch gut, wenn die Leute dann Tests hätten. 01:49:19.290 --> 01:49:22.170 Noch besser wäre es, wenn sich Testgetrieben entwickeln würden. 01:49:22.330 --> 01:49:24.250 Und da gibt es halt auch Frameworks, um sowas zu tun. 01:49:24.490 --> 01:49:27.450 Den kleinsten gemeinsamen Nenner zum Beispiel J-Unit. 01:49:28.170 --> 01:49:30.730 In allen Sprachen gibt es irgendwie den ersten Teil der Sprache. 01:49:32.570 --> 01:49:35.930 Also hat angefangen, soweit ich das weiß, mit S-Unit in Smalltalk. 01:49:36.410 --> 01:49:39.610 Und dann haben alle anderen einfach dasselbe gemacht und das ist so. 01:49:39.850 --> 01:49:46.410 Wenn ihr irgendwo Assert-Leerzeichen, eine Variable, andere Variable, das ist J-Unit im Normalfall. 01:49:46.650 --> 01:49:48.570 Assertions haben wir noch gar nicht angesprochen. 01:49:49.370 --> 01:49:54.730 Ist halt im Endeffekt, man geht davon aus, dass bestimmte Werte oder bestimmte 01:49:56.490 --> 01:50:01.610 Return-Values oder bestimmte Variablen oder bestimmte Dinge einen bestimmten Wert haben oder bestimmte 01:50:01.610 --> 01:50:02.090 Eigenschaften. 01:50:02.490 --> 01:50:05.290 Es ist halt, es ist syntaktischer Zucker über quasi eine Exception. 01:50:05.370 --> 01:50:06.410 So P mal Daumen. 01:50:06.650 --> 01:50:09.770 Du nimmst zwei Variablen und dann vergleichst du die irgendwie und nicht passt, dann knallt es halt. 01:50:09.930 --> 01:50:10.650 Also eine Explizit. 01:50:11.290 --> 01:50:14.810 Also im einfachsten Fall gibt es in einer Programmiersprache ein Assert-Stat, 01:50:15.050 --> 01:50:19.530 demübergibst du zwei Parameter und es wirft eine Exception, 01:50:19.610 --> 01:50:21.370 wenn diese Parameter nicht gleich sind. 01:50:21.450 --> 01:50:26.410 Und auf diese Assert-Methode kann man dann, oder auf dieses Assert-Stat, 01:50:26.490 --> 01:50:30.570 je nachdem wie es halt implementiert ist, da kann man dann im letzten Endes halt so ein Test-Framework drauf 01:50:30.570 --> 01:50:33.370 bauen, dass man sagt, okay, Assert not null. 01:50:33.530 --> 01:50:36.730 Dass man sagt, okay, ich möchte, dass diese Variable auf keinen Fall null ist, 01:50:36.810 --> 01:50:38.650 ansonsten wirft halt eine Exception. 01:50:38.890 --> 01:50:43.770 Oder Assert equals oder Assert oder ThrowsException oder sonst irgendwas, 01:50:43.850 --> 01:50:50.170 dass man sagen kann, okay, ich möchte, dass dies ein bestimmter Code jetzt unter bestimmten Umständen eine 01:50:50.170 --> 01:50:51.450 Exception wirft. 01:50:51.690 --> 01:50:53.210 Sowas macht man mit Assertions. 01:50:53.450 --> 01:50:57.050 Genau, also man kann im Prinzip, wie so ein Prozessor das macht, dass er versucht, 01:50:57.130 --> 01:51:03.050 alles auf Addition zurückzuführen, kann man alles in der Regel auf ein Assert Equals in irgendeiner Weise 01:51:03.050 --> 01:51:03.530 zurückführen. 01:51:04.250 --> 01:51:07.370 Dass man eben zwei Werte miteinander vergleicht und wenn die nicht passen, 01:51:07.930 --> 01:51:11.610 dann schmeißt man eine Exception, bricht den Test ab, markiert ihn als gefailt, 01:51:11.930 --> 01:51:14.490 wie das dann in den einzelnen Sprachen und Frameworks aussieht. 01:51:14.570 --> 01:51:14.730 Genau. 01:51:14.970 --> 01:51:18.410 J-Unit ist so das bekannteste Framework im Java-Umfeld. 01:51:18.490 --> 01:51:19.690 Das bietet genau das an. 01:51:19.770 --> 01:51:25.690 Also es ist ein Framework, das ich mir über einen Jar entsprechend oder einen Maven-Dependency reinlade, 01:51:26.010 --> 01:51:27.530 zur Verfügung stelle. 01:51:29.610 --> 01:51:33.850 Klassischerweise benennt man Klassen anders, 01:51:34.010 --> 01:51:36.810 nämlich immer entsprechend mit Test hinten dran. 01:51:37.610 --> 01:51:41.050 Und ansonsten so wie die Klasse, die sie testen. 01:51:41.290 --> 01:51:47.210 Also habe ich eine Klasse, die heißt main, dann ist die Test-Klasse eben Main-Test. 01:51:47.770 --> 01:51:54.650 Und zum Beispiel, wenn man Maven benutzt, liegen die Source-Code-Files für das Hauptprogramm in Source Main 01:51:55.130 --> 01:51:59.290 und die Source-Code-Files für die Tests in Source-Test, dass das schön getrennt ist, 01:51:59.370 --> 01:52:01.290 aber man kann es gleichzeitig betrachten. 01:52:01.770 --> 01:52:08.650 JUnit bietet alles rund um diese Assertions und kann zum Beispiel auch so Dinge abfangen wie ich 01:52:08.810 --> 01:52:12.010 will testen, dass eine Exception geworfen wird. 01:52:12.650 --> 01:52:17.930 Ein anderes Framework dazu ist TestNG, das baut im Prinzip auf diesen Konzepten auf, 01:52:18.170 --> 01:52:23.850 kann noch ein paar Sachen mehr, bis jetzt nicht groß weiter erwähnenswert. 01:52:24.010 --> 01:52:29.850 Es gab mal noch Cactus von Apache, das habe ich vor der Show gesehen, 01:52:30.090 --> 01:52:32.810 ist mittlerweile auf dem OpenApache Graveyart gelandet. 01:52:33.050 --> 01:52:37.930 No, also endgültig gewissermaßen wurde zu Grabe getragen. 01:52:38.650 --> 01:52:44.010 Das sind so die Teile, die ich im klassischen Falle einsetze, um Unit-Tests zu schreiben. 01:52:44.410 --> 01:52:50.170 Generell nochmal als Überbegriff, also diese Frameworks kann man normalerweise in so zwei, 01:52:50.330 --> 01:52:51.850 vielleicht auch drei Sachen aufteilen. 01:52:52.010 --> 01:52:56.650 Es ist einmal der Test-Runner, bedeutet irgendwie musst du ja, also du schreibst ja irgendwie Tests, 01:52:56.730 --> 01:52:58.970 aber in welcher Reihenfolge führt er die aus? 01:52:59.450 --> 01:52:59.770 Wie? 01:52:59.930 --> 01:53:02.650 Also gibt es da normalerweise gibt es halt eine Konvention, dass alle, 01:53:02.730 --> 01:53:08.410 die irgendwie mit Test Underscore anfangen, in der Klasse dann ausgeführt werden oder der parst die auf 01:53:08.410 --> 01:53:11.370 irgendeine besondere Art und vielleicht irgendwelche Annotations, Annotations. 01:53:11.850 --> 01:53:15.770 Genau, und so Spielereien, dann gibt es natürlich noch die Assertions, 01:53:15.930 --> 01:53:20.410 die Expectations, wie man auch immer so nennt, dass der also quasi Methoden bereitstellt, 01:53:20.490 --> 01:53:23.690 um wie gesagt einfach zwei Variablen zu vergleichen und er knallt es oder dass er sagt, 01:53:23.850 --> 01:53:30.490 ja, in dem Array muss irgendwie dieser Member drin vorkommen, der dir quasi dann auch 01:53:30.490 --> 01:53:32.970 schöne Fehlermeldungen generiert, wenn es nicht der Fall ist. 01:53:33.050 --> 01:53:39.050 Also was ich oft natürlich finde, ist, dass man, keine Ahnung, assert true und dann irgendwie myResult, 01:53:39.370 --> 01:53:43.850 Punkt Include und dann irgendein String und dann steht dann halt bei der Assertion nachher dran, 01:53:44.090 --> 01:53:46.330 false is not equal true befraust. 01:53:46.810 --> 01:53:50.810 Ohne, dass er dir einfach mal das Array sagt und dann sagt, und das sollte drin sein, 01:53:51.130 --> 01:53:56.250 bedeutet diese Assertions übernehmen die noch und was als drittes Feature auch noch oft mit drin ist, 01:53:56.490 --> 01:54:01.130 ist einfach das Reporting, also dass er quasi einen Exporter hat, dass er dann deine, 01:54:02.010 --> 01:54:05.610 ich meine, Felix mag Exit-Codes, dann sagt er halt hier Exit-Code 1, 01:54:05.690 --> 01:54:08.890 da ist irgendwas irgendwo kaputt, was schon mal ein guter Anfang ist. 01:54:08.970 --> 01:54:13.210 Und dann gibt es natürlich aber auch noch die Möglichkeit, er tut JUnit, 01:54:13.370 --> 01:54:16.890 hat das, glaube ich, da war typisch angefangen, XML-Dateien zu generieren zum Beispiel. 01:54:17.690 --> 01:54:22.410 JUnit XML, dass du das dann irgendwie in anderen Programmen noch weiterverarbeiten kannst, 01:54:22.490 --> 01:54:26.490 was denn genau schiefgegangen ist, dass du sagen kannst, ja hier, Jenkins zeigt mir dann an, 01:54:26.570 --> 01:54:29.290 ja, okay, folgende Tests sind fehlgeschlagen mit folgenden Namen. 01:54:29.370 --> 01:54:33.770 Und ach, übrigens, der Test ist auch schon vorher mal fehlgeschlagen, vor zwei Monaten. 01:54:34.010 --> 01:54:40.890 Vielleicht ist es eine Regression und also das bieten normalerweise die alle Frameworks in irgendeiner Art 01:54:40.890 --> 01:54:41.530 und Weise an. 01:54:41.690 --> 01:54:45.610 Den Export vielleicht nicht immer, aber zumindest, dass die Tests ausgeführt werden, 01:54:45.770 --> 01:54:48.090 in einer bestimmten Reihenfolge oder was auch immer. 01:54:48.410 --> 01:54:52.570 Und da ist auch meist ein Test-Setup mit drin, dass du quasi sagst, 01:54:52.730 --> 01:54:57.530 bevor ich den Test starte, mach folgendes, mach den Test und nachdem der Test fertig ist, 01:54:57.690 --> 01:55:02.250 mach einen Teardown, also Datenbank vorbereiten, Datenbank löschen, 01:55:02.330 --> 01:55:02.970 sowas in der Art. 01:55:03.210 --> 01:55:08.650 Genau, das gibt es dann in der Regel immer pro Test-Klasse einmal und pro Test-Case. 01:55:09.450 --> 01:55:14.730 Wenn du ein gutes Framework hast, teilweise gibt es, keine Ahnung warum, kommen wir später dazu. 01:55:14.890 --> 01:55:18.410 Es gibt Frameworks, wo du einfach ein Setup hast, also pro Klasse. 01:55:19.530 --> 01:55:21.850 Aber dann kein Teardown pro Klasse irgendwie. 01:55:21.930 --> 01:55:23.050 Manche Frameworks haben das nicht. 01:55:23.290 --> 01:55:24.170 Das ist seltsam, ja. 01:55:24.330 --> 01:55:29.130 Minitest zum Beispiel, so ein Assi, der, da gibt es, also du hast es ja entweder vor deiner kompletten Klasse 01:55:29.130 --> 01:55:33.370 und nach deiner kompletten Klasse oder vor deinem Test und nach deinem Test. 01:55:33.690 --> 01:55:39.290 Und diese After All-Hooks hat Minitest zum Beispiel hätte die, glaube ich, nicht. 01:55:39.770 --> 01:55:40.730 Was Assi ist. 01:55:42.090 --> 01:55:45.450 Noch ein Feature in J-Unit und vielen von den Test-Frameworks ist zum Beispiel, 01:55:45.530 --> 01:55:46.890 dass ich Tests auch skippen kann. 01:55:47.050 --> 01:55:52.170 Also dass ich in JUnit zum Beispiel hänge ich eine Add-Ignore-Annotation an den Test-Case dran und dann wird 01:55:52.170 --> 01:55:53.050 der geskippt. 01:55:53.530 --> 01:55:59.050 Das ist an sich eine gute Idee so gewesen, aber aus meiner Erfahrung heraus sorgt es hauptsächlich dafür, 01:55:59.130 --> 01:56:00.810 dass man so, oh, der Testcase schlägt fehlt. 01:56:00.890 --> 01:56:02.730 Na okay, dann ignore ich den einfach mal. 01:56:03.130 --> 01:56:07.770 Und sage ich mal, der Pain, den man dafür kassiert, ist leider nicht groß genug, 01:56:07.850 --> 01:56:12.970 weil da steht dann halt einfach nur bei jeder Testklasse, so und so viele Testcases wurden ausgeführt, 01:56:13.050 --> 01:56:17.770 so viele wurden geskippt und so viele waren fehlerhaft und dann steht da halt einer mehr bei skippt. 01:56:18.010 --> 01:56:21.290 Das diszipliniert die Entwickler in der Regel nicht groß genug. 01:56:22.010 --> 01:56:27.450 Aber ist ein Feature, haben, glaube ich, auch die meisten Test-Frameworks in irgendeiner Art und Weise. 01:56:29.050 --> 01:56:31.690 Dann, äh, das sind Testing-Frameworks. 01:56:31.930 --> 01:56:37.610 Dann gibt es für Java zum Beispiel auch Mocking- und Stubbing-Frameworks. 01:56:37.770 --> 01:56:42.650 Eines der bekannteren und relativ auch einfach zu verwenden, ist das Mokito. 01:56:43.610 --> 01:56:44.490 Mokito. 01:56:46.730 --> 01:56:47.930 Liegt noch auf Google Code. 01:56:49.530 --> 01:56:51.770 Steht hier auch auf der Seite eine Why drink it? 01:56:51.930 --> 01:56:53.050 How do I drink it? 01:56:55.210 --> 01:56:56.970 Ich habe jetzt an Moskito gedacht, aber. 01:56:57.370 --> 01:56:58.330 Ja, auch tatsächlich. 01:56:58.890 --> 01:57:00.490 Das ist einfach nicht Alkoholiker genug. 01:57:00.650 --> 01:57:01.930 Nee, sie sind nicht alkoholisch. 01:57:02.090 --> 01:57:04.090 Zeigt eure Einstellung Java gegenüber. 01:57:10.570 --> 01:57:15.530 Das hält im Wesentlichen, sage ich mal, eine Art API-Ähnlichkeit zu JUnit. 01:57:15.690 --> 01:57:21.370 Also ähnlich wie ich in JUnit meine Testcases schreibe, habe ich dann verschiedene Mock-Methoden 01:57:22.570 --> 01:57:24.010 und Verify-Methoden. 01:57:24.090 --> 01:57:29.450 Das ist das, was Flighty vorher erwähnt hat, ich kann verifizieren, dass ein Message-Send erfolgt ist. 01:57:30.890 --> 01:57:34.170 Und das kann ich mit Mokito machen. 01:57:34.410 --> 01:57:37.290 Das ist ein Framework, das das relativ einfach ermöglicht. 01:57:37.370 --> 01:57:39.130 Ich habe das früher viel verwendet. 01:57:39.770 --> 01:57:44.090 Spock ist noch insofern interessant, das hatten wir jetzt gerade kurz gehört von Marc, 01:57:44.570 --> 01:57:48.810 dass ich sehr häufig das Problem hat, dass die Error-Messages, wenn ein Test fehlschlägt, 01:57:48.970 --> 01:57:52.170 irgendwie nicht wirklich sinnvoll, nicht wirklich erklärend sind. 01:57:52.330 --> 01:57:55.930 Und dann hat gerade Spock, also das ist für mich so eines der Highlights davon, 01:57:56.890 --> 01:57:59.690 sehr explizit funktionierende Error-Messages. 01:57:59.770 --> 01:58:02.890 Also die machen da so ein bisschen ASCII-Art dann in der Regel so im Terminal, 01:58:04.250 --> 01:58:07.610 dass sie dir die Werte nebeneinander zeigen und dass sie dann zum Beispiel, 01:58:07.690 --> 01:58:11.930 wenn sie Listen haben, dann zeigen sie dir nebeneinander oder untereinander die verschiedenen Listen. 01:58:12.650 --> 01:58:13.610 Grafisches Gift dann quasi. 01:58:13.850 --> 01:58:20.570 Genau, du kannst recht einfach dann über grafische Sichtweise erkennen, was sein sollte und was der Fall war. 01:58:21.530 --> 01:58:27.690 Und Spock ist insofern, deshalb ist es, nennt es sich auch Enterprise Ready Specification 01:58:27.690 --> 01:58:28.650 Framework. 01:58:29.290 --> 01:58:34.330 Man schreibt Tests weniger als einzelne Methoden, 01:58:34.410 --> 01:58:39.130 die ausgeführt werden und mehr als so ein, ich erwarte folgendes, 01:58:39.370 --> 01:58:41.210 wenn ich dies und das da mache. 01:58:41.290 --> 01:58:45.610 Also ich habe in der Regel so einen typischen Block, da schreibe ich so Expect und dann das, 01:58:45.690 --> 01:58:52.490 was ich asserten will, also das die folgenden Aufrufe sind dann gewissermaßen meine 01:58:52.490 --> 01:58:53.370 Assertion. 01:58:53.850 --> 01:59:00.650 Und danach kommt ein Where-Block, der definiert, was denn so meine Input-Werte sind. 01:59:02.810 --> 01:59:07.370 Das ist auch vor allem im Groovy-Umfeld sehr beliebt, wenn man da noch viel, 01:59:07.450 --> 01:59:12.810 viel stärker die nette Syntax von Spock nutzen kann. 01:59:13.450 --> 01:59:18.330 Weil Groovy das einfach ermöglicht mit der etwas geschlifferen Java-Form. 01:59:18.650 --> 01:59:23.210 Dann, was wir in meinem früheren Job sehr gerne verwendet haben, das lag daran, 01:59:23.290 --> 01:59:26.090 wir hatten viele Manager, ist Fit. 01:59:26.330 --> 01:59:30.330 Fit ist ein Testing-Framework, gerade so für Integration-Tests. 01:59:31.370 --> 01:59:37.690 Das haben wir deswegen verwendet, weil es ein manager-kompatibles Format beherrscht, nämlich Excel. 01:59:37.930 --> 01:59:38.570 Oder Excel. 01:59:41.290 --> 01:59:41.850 Alle Dinge. 01:59:42.250 --> 01:59:47.850 Genau, das ist nicht besonders schön so an sich, das Framework, aber man kann es eben sehr gut benutzen, 01:59:47.930 --> 01:59:51.450 wenn man mehr oder weniger einen Manager sagen will, so. 01:59:51.750 --> 01:59:56.470 Du machst mir jetzt ein Excel-Dokument, in der Tabelle stehen die verschiedenen Werte, die du erwartest. 01:59:56.550 --> 02:00:00.710 Also beispielsweise für, was haben wir verwendet, Artikellisten. 02:00:00.790 --> 02:00:04.150 Also wenn wir Mappings hatten von Artikeln, die im Warenkorb lagen, 02:00:04.390 --> 02:00:10.230 zu verschiedenen Artikeltypen und Artikelnummern, die dann nachher im Billing-System bestellt werden sollten, 02:00:10.550 --> 02:00:15.990 dann haben wir das darüber sichergestellt, dass wir die Manager selber dann Excel-Dokumente haben schreiben 02:00:15.990 --> 02:00:16.310 lassen. 02:00:16.710 --> 02:00:23.510 Da haben wir ein bisschen Pain abgegeben, dass sie darin das formuliert haben und das liest dann 02:00:23.510 --> 02:00:29.270 nachher im Prinzip das Excel-Dokument ein und führt dafür entsprechende Test-Fixtures aus. 02:00:30.630 --> 02:00:31.430 Krasse Sache. 02:00:31.830 --> 02:00:32.470 Hardcore. 02:00:33.110 --> 02:00:35.990 Das ist halt alles Programming for the Enterprise. 02:00:36.310 --> 02:00:37.270 Richtig Enterprise Java. 02:00:37.590 --> 02:00:38.630 Enterprise, fricket Java. 02:00:38.790 --> 02:00:40.310 Das ist das Maximum Enterprise. 02:00:40.790 --> 02:00:42.070 Expertise Java fake. 02:00:42.310 --> 02:00:44.470 Felix, du bist doch unser Python-Mensch. 02:00:44.550 --> 02:00:46.630 Was benutzen die für Frameworks? 02:00:47.190 --> 02:00:51.910 Ich habe mich tatsächlich nicht damit auseinandergesetzt, sondern bis einmal das Internet gefragt. 02:00:52.150 --> 02:00:52.710 Ach Menno. 02:00:53.830 --> 02:00:55.990 Du benutzt also gar keine Tests, gibt zu. 02:00:56.310 --> 02:00:58.150 Nicht so oft, wie ich es vielleicht machen sollte. 02:00:58.310 --> 02:01:02.310 Vielleicht ist meine Software auch zu fricklich und zu eh kaputt die ganze Zeit quasi. 02:01:02.630 --> 02:01:03.590 Trotzdem mache ich noch nichts mehr. 02:01:04.550 --> 02:01:08.230 Ich habe zwei Sachen, die ich mir tatsächlich schon mal angeschaut habe, 02:01:08.550 --> 02:01:15.030 nicht groß eingesetzt, aber aus der Standard-Library gibt es genau zwei Arten, 02:01:15.270 --> 02:01:16.870 Unit-Tests zu schreiben. 02:01:17.030 --> 02:01:21.670 Das ist eine relativ interessante Sache, weil die zwei Sachen sind sich ziemlich weit, 02:01:21.830 --> 02:01:23.430 also sind sich überhaupt nicht in nahe. 02:01:24.230 --> 02:01:27.750 Die beschreiben quasi komplett verschiedene Arten, wie man Test schreibt. 02:01:27.830 --> 02:01:31.990 Einmal Unit-Tests, das ist genau das, was wir quasi die ganze Zeit beschrieben haben. 02:01:32.070 --> 02:01:35.350 Du hast irgendwie eine Funktion und dann beschreibst du mit einem Test, 02:01:35.430 --> 02:01:41.110 wie du die verwenden sollst und Tear Down und Setup und diesen ganzen Krams. 02:01:42.230 --> 02:01:49.030 Das ist in Python mit Unit-Tests halt abgebildet und funktioniert halt so, 02:01:49.110 --> 02:01:52.390 wie man sich das vorstellt und du führst es aus und dann macht er halt die ganzen Tests und sagt dir, 02:01:52.550 --> 02:01:54.310 was alles funktioniert hat und was nicht. 02:01:55.270 --> 02:01:56.950 Das zweite ist Doc-Tests. 02:01:58.310 --> 02:02:02.950 Das ist eine coole Sache und das liegt ein bisschen daran, 02:02:03.270 --> 02:02:06.870 wie in Python Dokumentation funktioniert. 02:02:07.110 --> 02:02:12.390 Nämlich wenn man in Python eine Funktion oder eine Klasse hat, 02:02:12.710 --> 02:02:19.430 dann kann man dort oben quasi wie so ein Kommentarblock aufmachen, 02:02:19.510 --> 02:02:25.990 nur dass dieser Kommentarblock nicht später dann verworfen wird, sondern Teil des Programms selber wird. 02:02:26.150 --> 02:02:31.350 Das heißt, der Kommentarblock wird zu dem Code, den der quasi beschreibt. 02:02:32.710 --> 02:02:33.270 Wie heißt denn das? 02:02:33.350 --> 02:02:34.710 Da gibt es doch auch einen Namen für irgendwie. 02:02:34.790 --> 02:02:39.670 Also normalerweise machst du das ja auch so über Methoden, dass du dann irgendwie mit add so Add und dann die 02:02:39.670 --> 02:02:40.310 Parameternamen. 02:02:40.630 --> 02:02:41.990 Achso, Doc, irgendwas auch. 02:02:42.710 --> 02:02:43.270 Doc Comments. 02:02:44.390 --> 02:02:47.830 In Java gibt es so Java Doc Comments, aber das ist Doc. 02:02:48.070 --> 02:02:51.430 Es gibt Java Doc, RubyDoc oder in Ruby gibt es auch zum Beispiel Jar. 02:02:51.830 --> 02:02:55.830 Genau, und da gibt es also dieses Ruby-Doc und Java Doc oder so, da gibt es irgendwie so einen generischen 02:02:55.990 --> 02:02:59.350 Namen für aber sorry, wollte ich unterbrechen. 02:03:00.230 --> 02:03:05.030 Und diese Besonderheit macht sich Doc-Test zu nutzen. 02:03:05.270 --> 02:03:11.750 Nämlich man beschreibt in dem Kopf von der Funktion, wie die Funktion sich verhalten soll, 02:03:11.990 --> 02:03:14.710 wenn man dem bestimmte Parameter übergibt. 02:03:15.270 --> 02:03:22.150 Und das sieht so ein bisschen aus wie der Prompt, wenn man quasi Python und da hat man diesen Interactive 02:03:22.230 --> 02:03:22.710 Prompt. 02:03:23.430 --> 02:03:27.350 Und was man da in diesen Prompt eingeben würde, um diese Funktion zu verwenden, 02:03:27.670 --> 02:03:33.110 schreibt man dann da rein und als Rückgabe bekommt man dann quasi, 02:03:33.270 --> 02:03:35.350 was es dann auch wirklich zurückgeben soll. 02:03:36.870 --> 02:03:38.390 Das ist relativ cool. 02:03:38.630 --> 02:03:40.070 Das ist eine coole Idee. 02:03:40.470 --> 02:03:43.110 Man kann dann auch zum Beispiel beschreiben, wann irgendwie Fehler, 02:03:43.270 --> 02:03:49.350 wie Fehler aussehen sollen und wann irgendwie eine Exception kommen soll und solche Sachen. 02:03:50.230 --> 02:03:56.470 Das ist ein bisschen schwierig für Sachen, die irgendwie mehr Setup-Teardown brauchen. 02:03:56.710 --> 02:04:00.230 Also wo man dann wirklich Boilerplate-Code hat, damit man die Sachen überhaupt erst verwenden kann. 02:04:00.310 --> 02:04:04.630 Für so triviales Zeug ist es ziemlich cool und auch super easy zu verwenden. 02:04:04.950 --> 02:04:08.950 Aber sobald es ein bisschen komplexer wird, wird es dann schon ein bisschen schwieriger. 02:04:10.390 --> 02:04:16.950 Genau, und das funktioniert halt, weil das Kommentar von der Funktion geparst wird und 02:04:16.950 --> 02:04:20.150 genau die Sachen, die da drin stehen, quasi ausgeführt werden. 02:04:21.750 --> 02:04:28.470 Also ist eine ziemlich coole Sache und auch relativ, also habe ich bis jetzt noch nicht in 02:04:28.470 --> 02:04:32.630 vielen Programmiersprachen gesehen, dass sowas quasi standardmäßig dabei ist. 02:04:34.390 --> 02:04:35.270 Sieht ziemlich cool aus. 02:04:35.750 --> 02:04:40.950 Es sieht cool aus, ist wahrscheinlich aber nur relativ eingeschränkt benutzbar. 02:04:41.510 --> 02:04:48.230 Das, was ich halt gesagt habe, solange die Sachen trivial sind, also solange man das so hart klein 02:04:48.230 --> 02:04:53.990 zerfrickelt hat, dass man genau eine Sache vorher machen muss und dann kannst du es quasi schon benutzen. 02:04:54.150 --> 02:04:55.190 Es ist super gut. 02:04:55.910 --> 02:04:59.270 Aber wenn das halt ein größeres Zeug ist, wo dann irgendwie was, nicht, 02:04:59.430 --> 02:05:02.870 wo halt nicht nur irgendwie ein Return-Value kommt, wo irgendwo was drinsteht, 02:05:02.950 --> 02:05:09.510 sondern halt was mehr, wo dann irgendwie Dinge noch passieren müssen oder keine Ahnung was, 02:05:10.230 --> 02:05:11.830 ist ein bisschen schwierig. 02:05:12.310 --> 02:05:14.630 Aber prinzipiell die Idee finde ich schon sehr, sehr cool eigentlich. 02:05:14.870 --> 02:05:18.390 Die Idee ist prinzipiell ganz cool und ich denke halt auch für viele Sachen, 02:05:18.470 --> 02:05:24.710 vielleicht auch in der Standardbibliothek oder in so kleinen, abgeschlossenen Bibliotheken, 02:05:25.030 --> 02:05:26.630 da macht sowas auf jeden Fall auch Sinn. 02:05:26.790 --> 02:05:29.510 Also ich meine, wenn man jetzt einfach nur sagen will, okay, ich möchte jetzt irgendwie, 02:05:29.670 --> 02:05:34.470 keine Ahnung, Algorithmen dokumentieren oder irgendwelche Sachen, 02:05:34.630 --> 02:05:39.430 die relativ funktional in Form von ich werfe was rein, ich bekomme was raus, 02:05:39.510 --> 02:05:42.150 ohne dass irgendwie zwischendrin ein State gehalten wird oder so. 02:05:42.470 --> 02:05:44.390 Für sowas ist es bestimmt ziemlich cool. 02:05:44.630 --> 02:05:49.430 Oder wenn du deine Etsy PasswD per E-Mail an jemanden schicken willst. 02:05:49.510 --> 02:05:53.190 Das ist ein Python-Grob-Zweizeilen-Code, das machst du dann einfach in diesen Doku-Block rein und dann ab 02:05:53.190 --> 02:05:53.430 dafür. 02:05:53.670 --> 02:05:56.710 Und dann kompilier das ein Zeug. 02:05:56.950 --> 02:05:57.110 Genau. 02:05:57.750 --> 02:06:02.230 Genau, und dann gibt es noch für Leute, die da mehr erfahren wollen, 02:06:02.470 --> 02:06:08.390 gibt es das Python-Testing Tools Taxonomy und da sind gefühlte 3 Milliarden 02:06:08.390 --> 02:06:11.110 Python-Test-Dinge drin. 02:06:12.790 --> 02:06:16.550 Wie gesagt, die zwei Sachen aus der Standard-Library habe ich angesprochen. 02:06:16.630 --> 02:06:21.510 Dann gibt es noch einen Nose-Test, was irgendwie wohl voll viele Leute benutzen und was irgendwie einfach ist 02:06:21.590 --> 02:06:22.230 zu verwenden. 02:06:22.470 --> 02:06:26.470 Aber prinzipiell geht es natürlich immer darum, du hast irgendwie Unit-Tests und du führst die aus. 02:06:26.550 --> 02:06:32.230 Und du hast, oder du hast irgendwie so Browser-Automation, zeugst und du führst es halt aus und machst damit 02:06:32.230 --> 02:06:34.630 irgendwelche Dinge und guckst dir die Return-Werte aus. 02:06:34.790 --> 02:06:40.950 Und der Unterschied ist eigentlich immer nur, wie einfach bestimmte Sachen damit sich lösen lassen. 02:06:42.390 --> 02:06:42.790 Genau. 02:06:43.590 --> 02:06:44.070 Gute Sache. 02:06:44.230 --> 02:06:48.470 Und Nachtrag DocBlock heißt es wohl, was ich gemeint habe. 02:06:48.550 --> 02:06:54.310 Dass es diese entweder immer Sternchen oder diese Hashes und dann einfach Add Parameternamen, 02:06:54.470 --> 02:06:55.670 Doppelpunkt, sonst was. 02:06:55.990 --> 02:06:56.390 Genau. 02:06:56.550 --> 02:07:01.270 Also wo das noch mit, also wo dieser Dokumentationsblock zum Beispiel noch mitverwendet wird, 02:07:01.350 --> 02:07:05.270 was ich schon mal gepickt habe von irgendwie ein paar Sendungen, ist, 02:07:06.070 --> 02:07:11.190 du beschreibst quasi deine Parameter, 02:07:11.350 --> 02:07:14.470 dein Parameter-Parsing in dem ersten Doc-Block. 02:07:14.710 --> 02:07:20.470 Und dann macht er daraus den ganzen Parser-Magic und dann hast du zum Schluss einfach nur noch quasi einen 02:07:21.670 --> 02:07:24.950 Key-Value-Store, wo alles drin ist, was du einfach haben willst. 02:07:25.270 --> 02:07:27.510 Ich suche das mal aus und das ist sehr, sehr cool. 02:07:27.830 --> 02:07:28.710 Coole Sache. 02:07:29.830 --> 02:07:35.510 Okay, dann andere Programmiersprache, Marc, eine deiner Lieblingsprogrammiersprachen, Ruby. 02:07:36.070 --> 02:07:37.350 Was nutzen die denn? 02:07:37.670 --> 02:07:42.710 Früher gab es da einfach mal Test Unit drin, was ungefähr genauso wie JUnit oder wahrscheinlich auch ähnlich 02:07:42.790 --> 02:07:44.470 wie Unit-Test in Python ist. 02:07:45.110 --> 02:07:49.110 Test Unit war Teil der Standard Library, also es war mal ein separates Projekt, 02:07:49.190 --> 02:07:55.750 wurde dann in die Standard Library getan, wurde dann außerhalb der Standard Library zu Test Unit Version 2 02:07:55.750 --> 02:08:02.150 weiterentwickelt und dann aber innerhalb der Standard Library abgelöst durch Minitest. 02:08:03.190 --> 02:08:08.790 Also Minitest ist quasi, war auch ein externes Gem, wo sie dann gesagt haben, das gefällt uns so cool. 02:08:08.950 --> 02:08:13.190 Von Ruby 1.8 auf 1.9 nehmen wir das einfach auch mit in die Standard Library. 02:08:13.750 --> 02:08:17.990 Bedeutet, es wird jetzt offiziell mitentwickelt und wir machen aber das Ganze, 02:08:18.230 --> 02:08:22.630 weil Minitest auch so unter anderem ein Unitest-Framework beinhaltet, 02:08:22.870 --> 02:08:29.110 machen wir quasi eine Kompatibilität zu dem alten Test-Unit, indem wir das einfach in Minitest wrappen. 02:08:29.670 --> 02:08:34.070 Bedeutet, unter den Covern quasi läuft da jetzt Minitest, 02:08:34.230 --> 02:08:37.110 aber die API ist noch komplett kompatibel zum alten Test-Unit. 02:08:38.710 --> 02:08:40.390 Falls da jemand alte Tests hat. 02:08:40.710 --> 02:08:41.430 Genau, richtig. 02:08:41.590 --> 02:08:45.510 Also das kann man einfach, so eine Drop-in-Solution und auf einmal kannst du theoretisch dann auch den neuen 02:08:45.510 --> 02:08:47.910 Scheiß benutzen, aber das alte geht immer noch. 02:08:48.150 --> 02:08:53.510 Ja, oder falls Leute halt tatsächlich sehr festgefahren sind auf Test-Unit. 02:08:53.750 --> 02:08:59.430 Ich meine, es gibt halt auch Leute, auch wenn sie sich relativ ähnlich verhalten, 02:08:59.590 --> 02:09:02.710 die beiden Frameworks, es gibt doch ein paar kleine Unterschiede. 02:09:02.950 --> 02:09:06.470 Und es gibt halt dann wahrscheinlich auch Leute, die sich dann irgendwie auch nicht umstellen wollen und 02:09:06.470 --> 02:09:09.830 sagen, oh, ich habe mich jetzt daran gewöhnt und so für solche Leute dann vielleicht auch. 02:09:10.310 --> 02:09:11.430 Wenn es läuft, geht es ja auch. 02:09:11.670 --> 02:09:15.110 Das Schöne an Minitest ist, dass es sehr, sehr klein und simpel ist. 02:09:15.190 --> 02:09:20.230 Also ein Testune ist es riesig und hat irgendwie so ganz Unmengen an Patterns drin, 02:09:20.310 --> 02:09:23.750 irgendwelche komischen Transformator-Baum-Dinger und was weiß ich. 02:09:23.910 --> 02:09:27.670 Und Minitest ist sehr, sehr klein und leichtgewichtig und kann aber auch sehr viel. 02:09:27.990 --> 02:09:30.470 Und auch sehr, eigentlich sehr schön überblickbar. 02:09:30.550 --> 02:09:36.070 Also da passiert sehr relativ wenig Magic, obwohl es eigentlich danach aussieht. 02:09:36.150 --> 02:09:41.750 Also es ist halt echt so, es gibt Minitest hat selber auch nochmal zwei Geschmacksrichtungen. 02:09:41.910 --> 02:09:46.870 Es gibt das einmal in der normalen X-Unit-Richtung, dass man sagt, man definiert eine Klasse, 02:09:46.950 --> 02:09:49.990 die erbt irgendwie von Minitest-Unit. 02:09:50.950 --> 02:09:57.910 Darin hat man Setup, Teardown, Before-After-Tests und sonstige 02:09:58.070 --> 02:09:58.710 Geschichten. 02:10:00.870 --> 02:10:01.590 Kein Before-Tests. 02:10:01.750 --> 02:10:03.990 Also Before-Test-Suite hat er nicht. 02:10:04.230 --> 02:10:05.430 Aus irgendeinem komischen Grund. 02:10:05.750 --> 02:10:08.710 Also du kannst nach allen Tests was ausführen, aber nicht vor allen Tests. 02:10:08.870 --> 02:10:11.270 Du kannst vor jedem einzelnen Test was ausführen. 02:10:11.590 --> 02:10:16.550 Ist wahrscheinlich aber halt auch der Scope von diesem Framework ist halt eher, 02:10:16.870 --> 02:10:20.870 biete mir eine Basis für Unit-Tests und da ist es halt relativ sinnlos, 02:10:21.830 --> 02:10:24.470 vor und nach der gesamten Test-Suite irgendwas auszuführen. 02:10:24.630 --> 02:10:28.470 Ja, gut, du kannst, also ich hätte es halt gern gehabt, teilweise, wenn ich irgendwie Redis zum Beispiel 02:10:28.550 --> 02:10:33.110 mittesten will und nicht wegmocken muss, dann hätte ich einfach gerne am Anfang einmal Redis gestartet und am 02:10:33.110 --> 02:10:35.990 Ende das beendet und inzwischenzeit immer drauf rumgerödelt, aber ich, 02:10:36.070 --> 02:10:41.030 ja, jetzt musst du halt irgendwie so Behelf Sachen machen, dass du irgendwie eine globale Variable setzt, 02:10:41.110 --> 02:10:41.910 wenn das Ding läuft. 02:10:43.750 --> 02:10:46.870 Genau, also es war der eine, eine, die eine Geschmacksrichtung. 02:10:46.950 --> 02:10:51.510 Es gibt Minitest-Unit, was so diese X-Unit-Richtung geht. 02:10:51.670 --> 02:10:56.550 Man implementiert ganz normal, ganz klassisch Klassen, 02:10:56.870 --> 02:11:00.310 erbt von einer bestimmten Unit-Testing-Klasse, implementiert Methoden, 02:11:00.390 --> 02:11:06.310 die mit Test beginnen und dann läuft der Rest, man hat irgendwie Assertions und dann gibt es noch mehr diese 02:11:06.310 --> 02:11:10.710 Behavioral-Driven oder Behavior-Driven Development-Schiene, 02:11:10.950 --> 02:11:13.910 die sich so ein bisschen an einem Framework, was später noch kommen wird, 02:11:13.990 --> 02:11:19.430 R-Spec anlehnt, dass man sagt, okay, man hat da jetzt so eine Domain-Specific Language für Tests, 02:11:19.510 --> 02:11:23.350 man muss da nicht mehr Methoden implementieren und man muss nicht mehr bestimmt erben, 02:11:23.430 --> 02:11:30.390 sondern man sagt einfach hier, ich lade ein bestimmtes Minitest-Modul und habe dann so 02:11:30.390 --> 02:11:36.470 Sachen wie Describe oder it und dann sieht es halt syntaktisch ein bisschen so aus wie Describe, 02:11:36.550 --> 02:11:41.670 ich habe eine Klasse, in diesem Describe-Block sage ich it, was weiß ich, 02:11:41.910 --> 02:11:48.550 must respond to read und dann implementiert man diese Assertion und diesen Test dann quasi in 02:11:50.550 --> 02:11:51.430 diesem It-Block. 02:11:51.590 --> 02:11:55.430 Ja, ich habe es selber nie genau kapiert, also weil technisch gesehen sind sie dasselbe. 02:11:55.510 --> 02:11:59.430 Also im Endeffekt vergleichst du halt zwei Sachen und dann knallt es halt, wenn es irgendwie so ist. 02:11:59.590 --> 02:12:05.110 Das ist hundertprozentig dasselbe, weil Minitest aus dieser Domain-Specific Language genau die gleichen 02:12:05.110 --> 02:12:12.070 Klassen zur Laufzeit generiert, die quasi die man im anderen 02:12:12.070 --> 02:12:13.350 Style selber schreiben sollte. 02:12:13.430 --> 02:12:16.550 Also das ist eigentlich komplett eine Geschmackssache. 02:12:16.950 --> 02:12:20.710 Beim Unitest musst du halt, müssen deine Tests zum Beispiel valide Methodennamen sein. 02:12:20.870 --> 02:12:26.150 Bei Specs normalerweise ist dein Test ein String, wo dann halt, also du kannst ja halt raussuchen, 02:12:26.230 --> 02:12:31.190 ob du irgendwie Test 02 Entering underscore, n underscore, 02:12:31.350 --> 02:12:34.470 Integer underscore, Leads, underscore, 2, underscore, n underscore, 02:12:34.630 --> 02:12:35.110 Exception. 02:12:35.510 --> 02:12:39.750 Ob du so eine riesige, fette Methode hast, die ein bisschen komisch aussieht oder ob du das halt als String 02:12:39.750 --> 02:12:40.550 schreiben willst. 02:12:41.510 --> 02:12:42.950 Minitest bietet beides. 02:12:43.830 --> 02:12:47.430 Genau, und das ist beides halt Ruby 1.9 in der Standardbibliothek. 02:12:47.590 --> 02:12:49.750 Für 1.8 kann man das als Gem nachladen. 02:12:50.870 --> 02:12:53.910 Ist cool, gibt es auch sehr viele coole Erweiterungen. 02:12:53.990 --> 02:12:57.270 Also es gibt dann halt irgendwie Minitest Pride, das macht dann den Testoutput-Bund, 02:12:57.350 --> 02:12:59.110 was es schon mal um Faktoren cooler macht. 02:12:59.670 --> 02:13:03.270 Es gibt Benchmarks, sie haben eigentlich ein Mocking- und Stubbing-Framework mit drin. 02:13:03.830 --> 02:13:07.670 Genau, das ist relativ, also das kann man benutzen für die normalen Fälle, 02:13:07.750 --> 02:13:12.470 wenn man ganz komplizierte Mocking-Fälle mit irgendwie, ich möchte in einer bestimmten Reihenfolge Sachen 02:13:12.470 --> 02:13:14.070 aufgerufen haben und so weiter. 02:13:14.310 --> 02:13:15.590 Das kann das glaube ich nicht. 02:13:15.670 --> 02:13:21.270 Jedenfalls bin ich da vor ein paar Monaten mal gegengelaufen und musste dann zu einer anderen 02:13:21.430 --> 02:13:25.910 Mocking-Bibliothek, nämlich Mocker, greifen, um da mal kurz vorzugreifen. 02:13:25.990 --> 02:13:32.230 Also Mocker ist einfach so ein ganz nettes getestetes Mocking- und 02:13:32.390 --> 02:13:37.750 Stubbing-Framework, was so sehr viele Features hat, die man eigentlich so erwarten würde. 02:13:40.070 --> 02:13:45.590 Anderes großes Framework, das, ich weiß nicht, ob es diese Specks, das war eines der ersten Spec-Frameworks, 02:13:45.670 --> 02:13:46.790 das ich in Ruby gesehen habe. 02:13:47.030 --> 02:13:51.830 R-Spec, gibt es auch zwei Versionen davon, die aber eigentlich recht ähnlich sind. 02:13:51.910 --> 02:13:58.790 Also RSpec 2, das ist das, was man wahrscheinlich haben will, bietet einem auch recht viele Hooks und 02:13:58.950 --> 02:14:00.310 ich mag es als Framework. 02:14:00.390 --> 02:14:04.870 Also es hat einigermaßen ein gutes Tooling drumherum, man kann es irgendwie nach XML exportieren und was man 02:14:04.870 --> 02:14:06.310 halt auch sonst so machen will. 02:14:06.870 --> 02:14:11.990 Sie bieten auch irgendwie Mox Expectations als Extra-Module an, die man da noch zuladen kann. 02:14:12.630 --> 02:14:17.190 Bietet einem auch so die Möglichkeit, halt die üblichen Tests abzufahren. 02:14:17.350 --> 02:14:19.510 Da scheint auch die Ruby-Gemeinde so ein bisschen geteilt zu sein. 02:14:19.590 --> 02:14:23.030 Die Hälfte will R-Spec, die andere Hälfte will so ihr Test-Unit-Style-Zeug. 02:14:23.270 --> 02:14:23.750 Minitest. 02:14:25.110 --> 02:14:25.350 Genau. 02:14:25.590 --> 02:14:29.510 Ja, ich meine, man hat halt beides hat Vor- und Nachteile. 02:14:29.670 --> 02:14:33.990 Ein Minitest ist relativ einfach zu verstehen, relativ einfach durchzublicken. 02:14:34.630 --> 02:14:37.990 Es gibt diese beiden Geschmacksrichtungen, von denen wir schon geredet haben. 02:14:38.070 --> 02:14:43.510 Davon sieht eine ein bisschen aus wie R-Spec, die andere sieht ein bisschen aus wie irgendwas X-Unit. 02:14:45.510 --> 02:14:51.350 Und ja, das ist auf der einen Seite relativ einfach, 02:14:51.430 --> 02:14:54.790 auf der anderen Seite fehlen halt teilweise Features, die man vielleicht gerne hätte, 02:14:54.870 --> 02:15:00.150 wohingegen so R Spec so die eierlegende Wollmilchsau ist, die kann unglaublich viel, 02:15:00.310 --> 02:15:06.230 die kann, da ist auch schon ein Mocking sehr komplex mit drin, 02:15:06.550 --> 02:15:08.790 da sind die ganzen Expectations mit drin. 02:15:09.030 --> 02:15:10.550 Es liest sich wie Englisch im Normalsten. 02:15:10.950 --> 02:15:13.030 Es liest sich letzten Endes wie Englisch. 02:15:13.270 --> 02:15:18.070 Also der Patcht macht auch jede Menge so Metaprogramming-Magik, dass quasi jedes Objekt dann auf einmal eine 02:15:18.070 --> 02:15:23.030 Shoot-Methode hat, dass du dann irgendwie sagst, keine Ahnung, 02:15:23.190 --> 02:15:24.950 wenn du irgend so eine Collection hast oder irgendein Array. 02:15:25.190 --> 02:15:25.990 Should equal zum Beispiel. 02:15:26.310 --> 02:15:29.510 Should equal or should und dann ein Leerzeichen Include und der merkt dann, 02:15:29.590 --> 02:15:33.670 okay, es gibt Include jetzt auf diesem Objekt nicht, aber es gibt es mit Fragezeichen und dann mache ich das 02:15:33.830 --> 02:15:36.230 und es liest sich wie ein englischer Satz im Endeffekt. 02:15:37.030 --> 02:15:39.910 Sowas in der Art macht aber Minitests back auch. 02:15:40.150 --> 02:15:42.790 Also ist, glaube ich, eine Geschmacksfrage. 02:15:43.190 --> 02:15:44.630 Verwirrt Leute am Anfang recht oft. 02:15:44.710 --> 02:15:48.470 Also wenn sie sich nicht wirklich mit Ruby auskennen und dann so, aber die Methode gibt es doch gar nicht. 02:15:48.550 --> 02:15:49.990 So, ja, der macht es irgendwie so. 02:15:50.310 --> 02:15:51.030 Magic Geheim. 02:15:51.350 --> 02:15:52.230 Magic geht einfach. 02:15:52.550 --> 02:15:53.350 Zu viel Magic. 02:15:53.510 --> 02:15:53.830 Ja. 02:15:54.630 --> 02:15:55.110 Mocker. 02:15:55.830 --> 02:16:00.790 Genau, habe ich gerade angesprochen, das ist eigentlich eine ganz nette Mocking-Library für Ruby, 02:16:01.030 --> 02:16:01.990 die ich gerne benutze. 02:16:02.070 --> 02:16:07.830 Also mein normaler Test, meine normale Test-Suite besteht eigentlich aus 02:16:09.030 --> 02:16:15.430 Minitest-Spec, also diese BDD-Variante und Mocker. 02:16:16.070 --> 02:16:18.950 Das sind so die beiden Tools, zu denen ich im Normalfall greife. 02:16:19.270 --> 02:16:24.550 Ich habe schon mal überlegt, mir irgendwie auch R-Spec anzugucken, aber ich weiß es nicht. 02:16:24.710 --> 02:16:27.590 Ich komme mit Minitests eigentlich relativ gut klar. 02:16:27.750 --> 02:16:31.750 Ich muss dazu nichts großartig nachinstallieren, weil es ist in der Standardbibliothek. 02:16:31.910 --> 02:16:36.310 Gut, das ist bei Ruby-Programmen jetzt eh kein besonders gutes Argument, 02:16:36.630 --> 02:16:41.590 weil für jede Kleinst-App muss man einen Haufen Gems nachladen. 02:16:42.870 --> 02:16:47.190 Und ja, also ich finde Minitest ganz nett. 02:16:47.590 --> 02:16:54.470 Das ist dementsprechend, weil es in Ruby Core ist, wird das gut weiterentwickelt und wird auch 02:16:54.470 --> 02:16:55.750 ständig maintained. 02:16:56.310 --> 02:17:02.070 Arspec, genauso, letzten Endes geben sie sich wahrscheinlich nicht viel und es ist eine Geschmacksfrage, 02:17:02.230 --> 02:17:03.030 welches man verwendet. 02:17:04.230 --> 02:17:05.510 Ganz anders ist es Cucumber. 02:17:05.910 --> 02:17:09.510 BDD hat mir vorher schon, also ich irgendwas anderes wanderwertig beschäftigt war, 02:17:09.590 --> 02:17:10.870 habt ihr glaube ich schon ein bisschen drüber geredet. 02:17:11.670 --> 02:17:17.270 Und Cucumber ist so der, ich glaube, der Urvater von diesem, äh, von dieser Art zu testen. 02:17:17.430 --> 02:17:24.230 Und zwar werden da Tests als englischer Text geschrieben oder als deutscher 02:17:24.230 --> 02:17:26.070 Text, keine Ahnung, könnt ihr auch in verschiedenen Sprachen machen. 02:17:26.310 --> 02:17:27.590 Das sind unglaublich vielen Sprachen. 02:17:27.910 --> 02:17:29.670 Macht es wahrscheinlich auf Englisch, das Einfache. 02:17:30.710 --> 02:17:36.550 Auf jeden Fall schreibst du da ein Feature als String und ein Feature sieht dann irgendwie so aus, 02:17:36.870 --> 02:17:39.830 keine Ahnung, steht dann Feature-Doppelpunkt und dann wieder ein Feature heißt, 02:17:39.910 --> 02:17:41.830 hier als Beispiel haben sie irgendwie Edition. 02:17:42.070 --> 02:17:46.230 Und dann hast du immer so diese Signalworte am Anfang, die eigentlich recht wenig aussagen, 02:17:46.390 --> 02:17:50.710 in order to bla bla bla oder as a user, I want, 02:17:50.870 --> 02:17:51.910 bla bla bla. 02:17:52.150 --> 02:17:58.710 Und was dann quasi dein Testschreiben ist, ist einerseits dieses Behavior als Text 02:17:58.870 --> 02:18:03.190 schreiben, also when I press add, then there should be a Pop-Up-Box called blah. 02:18:03.430 --> 02:18:07.430 Und wie du das Ganze dann in Code umsetzt, ist über Regular Expressions. 02:18:07.590 --> 02:18:12.230 Bedeutet das Framework bietet dir quasi ein Mapping von diesem Text auf ein Stück Code an. 02:18:12.390 --> 02:18:17.190 Also wenn du sagst, and I click the button called blah, in Anführungszeichen, 02:18:17.430 --> 02:18:22.790 dann schreibst du da einfach eine Regular Expression, die diesen Schritt matcht und die von mir aus dieses Bla 02:18:22.870 --> 02:18:25.190 als Variable rauszieht, als Matching Group. 02:18:26.070 --> 02:18:28.870 Und dann kannst du natürlich so ein generisches, ich klicke auf einen Button, 02:18:28.950 --> 02:18:31.990 wenn du irgendwie so ein Browser-Dingens hast wie Selenium, sagst du halt, 02:18:32.070 --> 02:18:36.150 ja gut, wenn der auf den Button klickt, der bla heißt, dann suchst du dir jetzt eben den Button, 02:18:36.230 --> 02:18:38.790 dessen Label-Text, keine Ahnung. 02:18:39.270 --> 02:18:39.990 Ja, zum Beispiel Text. 02:18:41.350 --> 02:18:47.110 Oder ja, ID eher selten, weil der User die ID ja nicht sieht, aber könnte man auch machen. 02:18:47.350 --> 02:18:49.750 Irgendwie, wenn er clickt on the button with the ID, bla. 02:18:50.710 --> 02:18:52.950 Der sich das raussucht und dann draufklickt. 02:18:53.110 --> 02:18:59.350 Und am Anfang wirkt es, also es ist ein bisschen nervig, weil du halt am Anfang echt alles erstmal Zeug 02:18:59.350 --> 02:19:02.710 implementieren musst und es ewig dauert, bis mal ein Test durchläuft, 02:19:02.950 --> 02:19:09.270 aber wenn der mal durchgelaufen ist, dann kannst du anfangen, englische Sätze zu kombinieren und teilweise 02:19:09.270 --> 02:19:13.830 auch Steps, also so nennt sich so einen Satz quasi, 02:19:14.150 --> 02:19:15.910 aus anderen Steps auszubauen. 02:19:16.070 --> 02:19:22.070 Also dann kannst du zum Beispiel sagen, given I'm logged in as an administrator. 02:19:22.230 --> 02:19:26.470 Und dann kannst du einfach fünf Steps zusammenbauen, nämlich given I'm on the login page, 02:19:26.550 --> 02:19:31.030 given I enter administrator credentials, and I click the login button, 02:19:31.430 --> 02:19:35.830 then I should see the homepage as a user or irgendwas, keine Ahnung. 02:19:36.950 --> 02:19:40.310 Und dann kannst du quasi einen Step aus anderen Steps aufbauen und am Ende, 02:19:40.470 --> 02:19:46.070 wenn du mal so eine Library hast, die dein Webinterface, deine Standard-Toolkits beschreibt, 02:19:47.370 --> 02:19:51.290 Dann musst du teilweise, um neue Tests zu bauen, gar nicht mehr programmieren. 02:19:51.370 --> 02:19:56.330 Du klickst dir einfach die englischen Beschreibungen zusammen und auf einmal funktioniert alles. 02:19:56.570 --> 02:20:02.250 Also da bist du dann aber halt einfach wegen der Verbosität von dem Ganzen auch auf irgendwelches Tooling 02:20:02.250 --> 02:20:05.450 angewiesen, dass du das zusammenklicken kannst, weil das willst du ja nicht alles schreiben müssen. 02:20:05.850 --> 02:20:11.050 Also es geht natürlich auch, das zu schreiben, aber ich stelle es mir schwierig vor mit Schreibfehlern und so 02:20:11.050 --> 02:20:11.450 weiter dann. 02:20:11.530 --> 02:20:12.250 Also wenn ich hier so ein bisschen. 02:20:12.410 --> 02:20:13.850 Achso, da ist given, I have never. 02:20:14.170 --> 02:20:15.610 Naja, da ist Cucumber ganz gut. 02:20:15.690 --> 02:20:20.330 Also Cucumber selber bietet Tooling an, dass er dir dann sagt, also du sagst dann Cucumber für meine Tests aus 02:20:20.490 --> 02:20:23.610 oder check mal Cucumber, dass da alles okay ist, dann sagt Cucumber, 02:20:23.690 --> 02:20:27.130 hey, du hast hier einen Text geschrieben, da finde ich keine Regular Expression, 02:20:27.210 --> 02:20:27.690 die matcht. 02:20:28.010 --> 02:20:30.490 Wenn du eine schreiben willst, dann würde die so aussehen. 02:20:30.570 --> 02:20:34.330 Also das sagt er dir echt in der Fehlermeldung und gib dir Copy und Paste fertig, 02:20:34.410 --> 02:20:39.130 quasi diesen kompletten Block, den du dann einfügen kannst, sondern eigentlich direkt implementieren kannst, 02:20:39.210 --> 02:20:39.930 wenn du willst. 02:20:40.410 --> 02:20:42.650 Wenn du ihn nicht hast, dann stürzt er halt ab. 02:20:44.090 --> 02:20:49.130 Tja, da bietet dir, also da ist QCumber recht gut, was das Tooling angeht, auch wunderbar mit Hooks. 02:20:50.250 --> 02:20:54.970 Genau, also man kann halt auch viel, also Reporting kann QCumber halt auch super, 02:20:55.050 --> 02:20:58.250 man kann sich irgendwie HTML-Pages generieren lassen, man kann sich XML generieren lassen, 02:20:58.330 --> 02:21:02.090 man kann sich JSON generieren lassen, man kann sich eigenen Reporter schreiben, 02:21:02.410 --> 02:21:06.970 man kann sogar sagen, okay, ich habe jetzt einen Reporter, zeigt mir doch mal alle Steps an, 02:21:07.130 --> 02:21:08.490 die nicht benutzt werden bisher. 02:21:08.650 --> 02:21:14.730 Oder zeigt mir doch mal, ich glaube, man kann auch noch Statistiken über die Verwendung von Steps und so 02:21:14.730 --> 02:21:16.090 weiter, kann man sich rauslassen. 02:21:16.250 --> 02:21:19.130 Bin ich mir nicht hundertprozentig sicher, könnte ich mir aber gut vorstellen. 02:21:19.610 --> 02:21:25.610 Also Cucumber kann relativ viel und das Schöne ist halt, wenn man sich mal so eine Library von Steps 02:21:26.570 --> 02:21:32.490 zusammenentwickelt hat, dann kann man damit halt auch eine ausführbare Spezifikation schreiben, 02:21:32.570 --> 02:21:39.370 mit der man eine User-Story für einen Kunden oder für seine User generell zusammenschreiben kann. 02:21:39.530 --> 02:21:43.610 Die können da drüber gucken, lesen das, okay, das ist jetzt irgendwie Prosa, 02:21:44.490 --> 02:21:49.370 sind in der Lage zu verstehen, was da passiert und das auch, können das nachvollziehen und sagen, 02:21:49.450 --> 02:21:54.650 nee, also ich will jetzt nicht, dass der auf den Button klickt, sondern der soll auf den Button klicken. 02:21:54.730 --> 02:21:59.850 Oder ich möchte, dass da erst, wenn ich, keine Ahnung, 02:21:59.930 --> 02:22:04.650 wenn ich meinen Usernamen eingegeben habe, möchte ich, dass dann erst mein Passwortfeld benutzbar ist oder 02:22:04.650 --> 02:22:05.850 irgendwie so Geschichten. 02:22:06.090 --> 02:22:10.970 Und sowas kann man dann in diese User-Stories mit rein encoden. 02:22:11.290 --> 02:22:16.330 Der Kunde oder jemand, der das später mal benutzen sollte, ist dann in der Lage, 02:22:16.650 --> 02:22:21.690 das zu verstehen, aber es ist eine ausführbare Spezifikation und das ist halt schon relativ wichtig. 02:22:22.090 --> 02:22:24.170 Also ja, das ist super. 02:22:24.330 --> 02:22:30.650 Also es ist ja genau das Gleiche, dass es, sage ich mal, Entscheider oder Manager oder nicht so fachlich 02:22:30.650 --> 02:22:33.610 betucht tauglich ist. 02:22:34.490 --> 02:22:40.890 Ich habe auch gerade gefunden, es gibt in Ruby Mine diese JetBrains Ruby-IDI zum Beispiel Cucumber Support 02:22:41.050 --> 02:22:41.530 dann drin. 02:22:42.250 --> 02:22:46.810 Ich glaube, was wir auch noch erwähnen sollten, Cucumber ist keine reine Ruby-Bibliothek. 02:22:46.890 --> 02:22:51.770 Es gibt auch, ich glaube, Cucumber gibt es auch in anderen Programm. 02:22:52.170 --> 02:22:56.490 Ja, es gibt es für Java, das heißt dann irgendwie, ähm, wie heißt dieses Java-Maskottchen? 02:22:56.570 --> 02:22:57.130 Dieser kleine? 02:22:57.930 --> 02:23:02.010 Ja, Qke for Duke heißt es dann, glaube ich, irgendwie als Library. 02:23:02.090 --> 02:23:07.770 Es gibt es für iOS, also das heißt ja, es gibt es für iOS und es ist Teil von 02:23:08.970 --> 02:23:09.770 Ruby Motion. 02:23:10.010 --> 02:23:13.610 Ruby Motion bietet dir dann so ein Stückchen Cucumber Support mit rein. 02:23:14.010 --> 02:23:17.690 Es gibt PHP, gibt es BH, B-Hat. 02:23:19.690 --> 02:23:20.970 Sieht natürlich nicht immer so hübsch aus. 02:23:21.050 --> 02:23:24.490 Also in Ruby sieht es mit diesem Regular Expression Matchen auf den Codeblock recht schön aus, 02:23:24.570 --> 02:23:28.970 weil die halt Lambdas können und weil Regular Expression auf Sprachebene mit drin ist und du dann nicht sagen 02:23:28.970 --> 02:23:32.650 musst, Regex.new, lödlödel, was weiß ich was. 02:23:34.570 --> 02:23:39.770 Also es sieht schon am coolsten in Ruby aus und es bietet auch in Ruby 02:23:41.450 --> 02:23:44.570 das angenehmste Tooling, so was von dem, was ich bisher gesehen habe. 02:23:44.650 --> 02:23:46.090 Aber es gibt es auch für andere Sprachen. 02:23:46.410 --> 02:23:48.730 Es ist ja echt nur ein Textparser, der das danach guckt. 02:23:48.890 --> 02:23:50.090 Das ist ja nur eine Technik, genau. 02:23:50.170 --> 02:23:56.090 Letzten Endes ist es die Sprache, in der man diese Testspezifikationen dann schreibt, 02:23:56.170 --> 02:23:58.250 die nennt sich Girkin. 02:23:59.050 --> 02:24:01.130 Also so die kleinen Gürkchen. 02:24:01.770 --> 02:24:06.730 Und diese Sprache, die wurde halt auch in andere Programmiersprachen übersetzt. 02:24:06.810 --> 02:24:08.570 Also sehr schön finde ich auch Erlangt. 02:24:08.650 --> 02:24:12.890 Da gibt es zweimal Qcam Bell, was sich irgendwie bayerisch anhört, 02:24:12.970 --> 02:24:17.370 aber einmal mit C vorne, einmal mit K vorne, weil es das mit C vorne schon gab wahrscheinlich. 02:24:19.210 --> 02:24:19.530 Ja. 02:24:20.170 --> 02:24:26.090 Aber ansonsten ganz nettes Framework, ist nicht unumstritten, 02:24:26.410 --> 02:24:29.370 weil hat sehr viel Overhead außenrum. 02:24:29.610 --> 02:24:34.570 Gerade diese ganzen Tests implementieren und sich erstmal mit der ganzen Infrastruktur außenrum auskennen. 02:24:35.850 --> 02:24:37.130 Ist nicht ganz einfach. 02:24:37.930 --> 02:24:44.250 Allerdings ganz cool, wenn man halt mit Leuten zu tun hat, die nicht selber programmieren können und trotzdem 02:24:44.410 --> 02:24:47.450 die Tests verstehen können sollen. 02:24:47.690 --> 02:24:54.090 Also wir haben das tatsächlich auch in unserer Firma, dass wir Cucumber Definitions auch 02:24:54.330 --> 02:25:00.810 manuellen Testern geben, damit die sich dann quasi nochmal manuell von einem Release durch die 02:25:00.810 --> 02:25:02.250 Applikation klicken können. 02:25:03.530 --> 02:25:06.250 Und da gibt es ja Dienstleister im Internet, wo man sagen kann, hey, 02:25:06.330 --> 02:25:11.850 ich möchte jetzt mal irgendwie fünf oder zehn Leute mieten, die sich dann mal einen Tag lang durch meine 02:25:11.930 --> 02:25:16.650 Applikation durchklicken und Workflows nachvollziehen in unterschiedlichen Browsern. 02:25:16.890 --> 02:25:23.850 Und genau solchen Leuten kann man dann halt auch solche standardisierten Formate geben und die verstehen 02:25:23.850 --> 02:25:26.410 das und die müssen nicht unbedingt programmieren können, um das auszuführen. 02:25:26.570 --> 02:25:29.050 Ja, und also man kann es auch schön erweitern. 02:25:29.290 --> 02:25:31.530 Cook haben wir selber halt unendlich viele von diesen Hooks. 02:25:31.690 --> 02:25:36.650 Und also was wir zum Beispiel am Anfang gemacht haben, ist einfach, er bietet einen HTML-Export. 02:25:36.730 --> 02:25:40.330 Also du kannst sagen, hier mach, exportiere nach XML für JUnit, für Jenkins, 02:25:40.410 --> 02:25:45.370 aber exportiere auch mal nach HTML, dass mir irgendwie jeder Test einfach so eine Übersicht hat, 02:25:45.450 --> 02:25:48.810 wo man dann die einzelnen Steps immer so collapsen kann und sieht, was ist denn fehlgeschlagen, 02:25:48.890 --> 02:25:52.090 was ist rot, was ist grün, schön farblich hervorgehoben schon. 02:25:52.650 --> 02:25:55.930 Was wir am Anfang gemacht haben, einfach, wir haben einen Hook geschrieben, 02:25:56.170 --> 02:26:00.330 der einfach einen After-Scenario-Hook, der nach jedem Test quasi schaut, 02:26:00.570 --> 02:26:02.410 okay, ist der Test fehlgeschlagen? 02:26:02.570 --> 02:26:06.490 Wenn der Test fehlgeschlagen ist und du rein zufällig den Browser offen hast, 02:26:06.570 --> 02:26:09.930 was ja bei diesen, also wir machen damit so Webbrowser-Fernsteuerungen, 02:26:10.090 --> 02:26:12.890 dann mach doch mal einen Screenshot und speichere den Screenshot inline, 02:26:13.130 --> 02:26:16.010 Base 64 kodiert als PNG-Datei. 02:26:16.090 --> 02:26:17.450 Du kannst einen HTML machen. 02:26:17.930 --> 02:26:22.410 Wir haben damit angefangen, bedeutet die HTML-Reports haben dann immer die Fehlerscreenshots gehabt. 02:26:22.490 --> 02:26:25.210 Dann haben wir gesagt, okay, und speichere auch gleich das HTML mit raus. 02:26:25.370 --> 02:26:27.850 Bedeutet, ein Entwickler kann dann das Ding anschauen und kann sagen, 02:26:28.250 --> 02:26:31.050 komisch ist fehlgeschlagen, kann dann aber den Screenshot sehen und sagen, 02:26:31.130 --> 02:26:34.490 ah ja, hier, da ist noch der modale Dialog offen, der eigentlich weg sollte. 02:26:34.650 --> 02:26:41.210 Und jetzt hat ein Kollege neulich noch was dazu geedet, dass er jetzt auch sogar per JavaScript 02:26:42.490 --> 02:26:46.810 über QCamber ein kleines Overlay injectet, wo dann immer draufsteht, 02:26:47.050 --> 02:26:50.570 auf dem Screenshot auch noch, ich war übrigens gerade in dem Step, bedeutet, 02:26:50.650 --> 02:26:55.370 ich habe hier aktuell da drauf geklickt und gewartet, bis irgendwas rauf poppt, 02:26:55.530 --> 02:26:59.930 aber den Selector, der kam einfach nicht. 02:27:00.490 --> 02:27:04.330 Also du kannst da ist echt ziemlich gut konfigurierbar. 02:27:04.810 --> 02:27:05.210 Genau. 02:27:06.250 --> 02:27:10.970 Was man vielleicht dazu sagen muss, QKAM an sich ist kein komplettes Testing-Framework. 02:27:11.050 --> 02:27:15.850 Da gibt es zum Beispiel auch von Haus aus keine Assertions, sondern die muss man sich irgendwie nachladen. 02:27:17.370 --> 02:27:18.250 Ja, genau. 02:27:18.650 --> 02:27:23.930 Und ja, ansonsten ist es, glaube ich, schon komplett. 02:27:24.010 --> 02:27:29.690 Es ist ein Testrunner dabei, keine Assertions, aber eine Auswertung. 02:27:31.610 --> 02:27:34.170 Wie war das Wort dafür, was dann hinten rauskommt? 02:27:34.410 --> 02:27:35.610 Mein Hirn setzt gerade aus. 02:27:35.930 --> 02:27:37.210 DJUnit XML-Datei. 02:27:37.530 --> 02:27:38.090 Ja, zum Beispiel. 02:27:38.170 --> 02:27:38.490 Sowas. 02:27:38.570 --> 02:27:39.050 Ein Reporter. 02:27:39.210 --> 02:27:41.210 Reporter war das Wort, was mir gerade gefehlt hat. 02:27:42.170 --> 02:27:46.890 Genau, also sowas ist dabei, Assertions zwischendrin, da kann man sich zum Beispiel die von R-Spec nachladen. 02:27:48.570 --> 02:27:50.250 Die funktionieren eigentlich auch ganz gut. 02:27:50.730 --> 02:27:54.090 Genau, das ist auf jeden Fall ein echt interessantes Framework. 02:27:55.290 --> 02:27:59.690 Dann haben wir noch so ein paar kleine Sachen, so Libraries, die man benutzen kann, 02:27:59.930 --> 02:28:01.450 wenn man bestimmte Sachen testet. 02:28:01.530 --> 02:28:03.370 Da würde ich relativ kurz drüber reden. 02:28:03.530 --> 02:28:04.810 Ja, wir sollten einfach nochmal. 02:28:05.050 --> 02:28:10.010 Also es gibt Bibliotheken, wenn man HTTP-Clients schreibt, die quasi 02:28:10.970 --> 02:28:17.530 bestimmte Request-Response-Pattern auf einen HTTP-Server 02:28:18.490 --> 02:28:19.610 simulieren können. 02:28:19.770 --> 02:28:24.250 Entweder der Request geht einmal durch und das Framework zeichnet auf, 02:28:24.330 --> 02:28:28.170 was denn da passiert ist und spielt das dann beim Test jedes Mal wieder neu ab. 02:28:28.490 --> 02:28:30.410 Oder man definiert das programmatisch. 02:28:30.490 --> 02:28:37.130 Da haben wir jetzt mal vier sogar Frameworks oder Bibliotheken verlinkt, 02:28:37.210 --> 02:28:38.170 die sowas können. 02:28:38.730 --> 02:28:45.530 Hat einfach auch das Ziel, dass wenn man einen Integration-Test zum Beispiel für eine 02:28:45.530 --> 02:28:49.850 Web-API von GitHub schreibt, zum Beispiel, 02:28:50.410 --> 02:28:55.610 dann kann es ja mal passieren, dass GitHub gerade down ist oder man gerade kein Internet hat oder sonst 02:28:55.610 --> 02:28:56.570 irgendwie Geschichten. 02:28:56.650 --> 02:29:02.250 Zudem ist es tatsächlich immer halt ein Call, der langsam ist, weil der übers Netz muss und sowas möchte man 02:29:02.250 --> 02:29:02.890 halt umgehen. 02:29:02.970 --> 02:29:04.250 Dafür gibt es Bibliotheken. 02:29:05.290 --> 02:29:09.770 Und für so Filesystem-Kram gibt es das auch noch. 02:29:09.850 --> 02:29:15.690 Also es gibt dann Bibliotheken, die quasi in Memory ein bestimmtes Filesystem emulieren, 02:29:16.490 --> 02:29:20.330 sodass man halt sagen kann, okay, ich möchte jetzt mal testen, ich lege hier eine Datei an, 02:29:20.490 --> 02:29:24.570 ich schreibe so und sowas in eine Datei rein und ich gucke dann, ob in der Datei was drin ist. 02:29:25.370 --> 02:29:29.130 Will das aber so schnell wie möglich haben und nicht auf einem tatsächlichen Dateisystem, 02:29:29.210 --> 02:29:32.090 dann kann man das halt im Endeffekt mit so einer Bibliothek simulieren. 02:29:34.090 --> 02:29:39.770 Es gibt ja noch so Sachen, wo du teilweise echt sogar die Zeit, was heißt, Timecop-Cronic? 02:29:40.730 --> 02:29:47.210 Timecop ist auch so eine Ruby-Library, wo du dann sogar beim Testen quasi Zeit simulieren kannst und nicht auf 02:29:47.210 --> 02:29:48.730 dein echtes System Zeit zugreifen. 02:29:48.970 --> 02:29:52.170 Das ist auch für Zeitzonen, mir fällt der Name des Gems gerade nicht ein, 02:29:52.250 --> 02:29:56.490 aber es gibt auch tatsächlich einen Gem, da kann man sagen, 02:29:56.570 --> 02:30:02.330 okay, führ mal alle meine Tests in allen unterschiedlichen Zeitzonen aus und stell mal die Rechneruhr oder 02:30:02.330 --> 02:30:06.330 simuliere mal, dass die Rechneruhr umgestellt wurde und guck mal, was mit deiner Anwendung dann passiert. 02:30:06.410 --> 02:30:07.530 Ja, ganz cool. 02:30:08.250 --> 02:30:14.170 Ja, genau, ansonsten gibt es noch JavaScript-Frameworks, die sind alle so ähnlich wie die Dinge, 02:30:14.250 --> 02:30:15.930 die wir bis jetzt besprochen haben. 02:30:16.250 --> 02:30:20.730 Jasmin ist tatsächlich ein direkter 1 zu 1-Port von Archback. 02:30:20.890 --> 02:30:27.850 Auch von den, ich glaube nicht von den gleichen Leuten, aber zumindest auf API-Basis relativ 02:30:27.850 --> 02:30:28.730 ähnlich. 02:30:29.930 --> 02:30:34.810 Interessant finde ich bei PHP entweder, weil ich in der Community nicht so zugange bin, 02:30:35.130 --> 02:30:41.850 oder aus anderen Gründen, mir sind da spontan nur zwei wirklich bekannte Test-Frameworks 02:30:42.410 --> 02:30:48.810 eingefallen, wohingegen ich, wohingegen es bei anderen Programmiersprachen irgendwie Hunderte gibt. 02:30:48.970 --> 02:30:55.450 Also ich weiß nicht, ob das was über die Community aussagt oder ob diese beiden Test-Frameworks PHP-Unit und 02:30:55.450 --> 02:31:01.370 SimpleTest, die hauptsächlich verwendet werden, ob die einfach ausreichend sind und gut genug sind oder ob die 02:31:01.370 --> 02:31:03.050 Community nicht so viel testet, weiß ich nicht. 02:31:03.290 --> 02:31:06.090 PHP war halt eine Template-Sprache von Anfang an, da hast du Testen, 02:31:06.330 --> 02:31:11.370 da brauchst du einen Webserver und eine Datenbank für, weil du hast irgendwie HTML generiert mit Inline-SQL. 02:31:11.850 --> 02:31:14.250 Bedeutet, da gab es von Anfang an nicht so viel. 02:31:14.490 --> 02:31:19.370 Es gibt jetzt Sachen wie BHET zum Beispiel, die das dann auch, also PHP hat die Dinger auch, 02:31:19.690 --> 02:31:25.370 aber ich würde sagen, so verhältnismäßig, man findet wesentlich weniger getesteten PHP-Code wie zum Beispiel 02:31:25.370 --> 02:31:25.930 Ruby. 02:31:26.250 --> 02:31:28.410 Ja, also das sind auch meine Vorurteile, ja. 02:31:28.650 --> 02:31:32.570 Genau, also da kommen wir nachher vielleicht noch auch drauf beim Thema Infrastruktur. 02:31:32.970 --> 02:31:37.050 Bei den ganzen anderen Programmiersprachen jetzt mal auch Ruby und JavaScript vorgelassen, 02:31:37.130 --> 02:31:41.530 aber da hat sich das eben entsprechend ergeben, habe ich ja auch immer einen Bildprozess in irgendeiner Weise. 02:31:41.690 --> 02:31:45.690 Und typischerweise klinke ich meine Tests in den Bildprozess mit ein. 02:31:45.930 --> 02:31:52.890 Und das hat sich bei PHP auch erst später, als dann so Library Dependency Management über alle möglichen Pair 02:31:52.890 --> 02:31:58.490 und ich weiß nicht, was Sachen dazu kamen, dazu ergeben und deshalb ist es einfach da nicht so üblich. 02:31:58.810 --> 02:32:03.610 Also man sagt halt, die meisten auch von mir PHP-Entwickler, die ich kenne, 02:32:03.770 --> 02:32:07.530 sagen halt, also die sind so der klassische Fall von ja, ich baue halt meinen Code, 02:32:07.610 --> 02:32:11.050 der funktioniert, ich schreibe keine Tests, weil da muss ich mich erstmal drum wieder kümmern, 02:32:11.130 --> 02:32:15.610 dass ich einen Testrunner habe und ein PHP Unit und dann muss ich mir irgendwie einen Testprozess und einen 02:32:15.610 --> 02:32:18.170 Bildprozess anlachen und da habe ich doch gar keine Lust drauf. 02:32:18.410 --> 02:32:20.010 Mein Code funktioniert doch, ne? 02:32:22.490 --> 02:32:26.650 Ich würde mal gern, also ihr schreibt ja alle Code, wir haben schon gehört, 02:32:26.810 --> 02:32:31.690 Fladi macht gerne tatsächlich Test-Driven Development und wir haben jetzt gehört, 02:32:31.770 --> 02:32:35.770 was es für verschiedene Frameworks in den ganzen Programmiersprachen gibt. 02:32:36.410 --> 02:32:37.850 Was benutzt ihr denn? 02:32:37.930 --> 02:32:42.410 Vielleicht können wir das mal an realen Projekten, die wir gerade haben, so durchgehen. 02:32:42.490 --> 02:32:44.970 Also was verwendet ihr tagtäglich, Marc? 02:32:45.050 --> 02:32:47.930 Du benutzt ja, wir haben ja gehört, du hast ja gerade irgendwas gefixt, 02:32:48.250 --> 02:32:52.170 was hast du denn, was waren das für Tests, wofür braucht man die? 02:32:53.370 --> 02:32:57.130 Das war jetzt ein bisschen was komplizierteres, aber was ein einfaches, 02:32:57.210 --> 02:33:01.050 schönes Beispiel ist gerade diesen Video-Downloader, habe ich da Wittel AB, 02:33:01.130 --> 02:33:05.290 weil mir irgendwann dieses YouTube-DL auf die Nerven ging, weil das immer so komisch geforgt hat und wenn ich 02:33:05.290 --> 02:33:08.490 es so mit STGC abgebrochen habe, dann ging der Download im Hintergrund weiter. 02:33:08.650 --> 02:33:12.810 Und das ging mir tierisch auf die Nerven, deswegen habe ich das einfach selber gemacht mit Blackjack und 02:33:12.810 --> 02:33:13.290 Noten. 02:33:13.690 --> 02:33:15.130 Und also quasi. 02:33:15.450 --> 02:33:17.770 Ich baue meinen eigenen Vergnügungspark. 02:33:18.170 --> 02:33:24.090 Und da ist natürlich die Sache, dieser Video-Downloader, der hat irgendwie verschiedene Plugins, 02:33:24.250 --> 02:33:28.010 also irgendwie einen für Vimeo, einen für Soundcloud, einen für YouTube, 02:33:28.330 --> 02:33:29.210 was weiß ich. 02:33:29.850 --> 02:33:34.010 Und da ist halt das Problem, da könnte ich Unitests machen und das wäre wahrscheinlich auch bitter nötig, 02:33:34.090 --> 02:33:36.890 weil irgendwie der Code unendlich alt und sehr schlecht ist. 02:33:37.850 --> 02:33:42.010 Aber im Endeffekt bringt mir das alles nichts, weil wenn was kaputt geht, 02:33:42.170 --> 02:33:46.330 ist das selten mein Code, weil so viel macht der nicht, sondern das ist, 02:33:46.490 --> 02:33:47.770 wenn die API sich ändert. 02:33:48.010 --> 02:33:52.810 Bedeutet, für das Ding habe ich nur Specs. 02:33:53.850 --> 02:33:57.210 Das Ganze, oder es ist eigentlich keine Spec, es ist eigentlich ein Minitest, 02:33:57.290 --> 02:34:00.410 ein Unitest, ich habe es aber bei einem Ordnernamen Spec, komischerweise. 02:34:01.290 --> 02:34:03.610 Und das sind einfach komplette Acceptance-Tests. 02:34:03.690 --> 02:34:10.010 Bedeutet, was ich da im Normalfall mache, ist, ich rufe das Programm selber auf mit einer YouTube-URL und 02:34:10.010 --> 02:34:15.130 sage, extrahiere mir da mal den Link vom Video und mache dann einen Head-Request auf die Datei, 02:34:15.210 --> 02:34:16.730 ob die auch wirklich da ist. 02:34:17.130 --> 02:34:23.130 Bedeutet so das Einfachste, was ich am Ende noch nachher drauf geklatscht habe, mache ich mit Minitest. 02:34:24.090 --> 02:34:29.450 Und das Problem ist, das Ganze läuft auf Travis CI, was eine coole Sache ist, 02:34:29.530 --> 02:34:34.330 nur leider läuft das immer nur, wenn du committest und YouTube ändert eben ihre Sachen nicht immer nur, 02:34:34.410 --> 02:34:36.170 wenn ich committe, sondern die ändern die zwischendurch. 02:34:36.730 --> 02:34:37.610 Häufiger committen. 02:34:37.770 --> 02:34:39.210 Ja, richtig, das ist das Problem. 02:34:39.290 --> 02:34:44.890 Und es gibt dann so Tools, die das irgendwie nightly quasi einen Webhook triggern, 02:34:45.050 --> 02:34:49.690 wo das dann auch läuft, aber das teste ich einfach komplett als Acceptance-Test. 02:34:50.970 --> 02:34:54.650 Ist gut genug, immer wenn irgendwas kaputt geht, bekomme ich es eigentlich mitten, 02:34:54.730 --> 02:34:56.730 hoffe dann, dass ich irgendwie Zeit habe, das zu fixen. 02:34:57.610 --> 02:35:02.570 Was mir da fehlt, ist ganz klar echte Unit-Tests für so Sachen wie Dateinamen, 02:35:02.810 --> 02:35:08.410 Cleaning, weil ich nehme natürlich den Dateinamen den Titel vom Video und baue dann Dateinamen draus und dann 02:35:08.410 --> 02:35:12.010 kommen auf einmal Chinesen und du hast keine Ahnung, was mit diesen fucking Dateinamen passiert, 02:35:12.090 --> 02:35:13.530 wenn da so Schriftzeichen drin sind. 02:35:13.610 --> 02:35:17.210 Und für sowas bräuchte ich echt Unit-Tests, die das machen. 02:35:17.370 --> 02:35:18.330 Hab ich noch nicht. 02:35:19.130 --> 02:35:21.050 Müsst man auch refactoren, damit es klappt. 02:35:21.370 --> 02:35:25.690 War jetzt auch nicht dein Ziel, weil du lädst nicht so viele chinesische Videos runter, oder? 02:35:26.010 --> 02:35:30.010 Nee, prinzipiell war das so eine ganz dreckige, kleine Anwendung, die nur mit YouTube ging und da habe ich 02:35:30.010 --> 02:35:32.570 gedacht, Vimeo würde ich auch gerne, das ist so einfach. 02:35:32.890 --> 02:35:36.090 Und dann habe ich das gemacht und dann wurde es irgendwie ganz groß und jetzt, 02:35:36.250 --> 02:35:40.170 keine Ahnung, 118 Stars, 15 Forks, keine Ahnung, was da los ist. 02:35:40.490 --> 02:35:42.970 Auf jeden Fall soll ich es reparieren, TM. 02:35:43.290 --> 02:35:44.410 TM, dann mach's doch einfach. 02:35:44.730 --> 02:35:46.250 Oder Leute, just do it. 02:35:46.570 --> 02:35:49.290 Leute, die Rechte geben, es zu ändern. 02:35:49.610 --> 02:35:52.010 Du hast Travis CI gesagt, was ist Travis CI? 02:35:52.490 --> 02:35:58.090 Travis CI ist so eine Open Source, also nicht Open Source, aber für Open Source Projekte kostenlose Continuous 02:35:58.090 --> 02:36:00.250 Integration-Umgebung. 02:36:00.410 --> 02:36:04.650 Es ist auch Open Source, stimmt, aber weiß nicht, vielleicht haben die so Premium-Zeug noch irgendwo drin. 02:36:05.050 --> 02:36:06.330 Ja, die hosten das halt für dich, ja. 02:36:07.210 --> 02:36:10.970 Auf jeden Fall ist das so eine einfache Möglichkeit, wenn du sowieso mit GitHub entwickelst, 02:36:11.050 --> 02:36:15.610 dass du quasi sagen kannst, ja, jedes Mal, wenn ich einen Commit mache, 02:36:15.690 --> 02:36:19.210 dann bietet GitHub dir so Hooks und der sagt halt dann, okay, jedes Mal, 02:36:19.290 --> 02:36:24.090 wenn ich einen Commit mache, dann sagt das Travis, Travis, check dein Repository aus und dann hast du eine 02:36:24.090 --> 02:36:28.650 Punkt Travis.yaml-File drin, wo dann die Kommandos stehen, die er als Root auf so einer, 02:36:28.730 --> 02:36:33.130 ähm, wahrscheinlich in so einem LXC-Container oder sowas ausführen soll. 02:36:33.530 --> 02:36:40.090 Und was er dann einfach bei mir macht, ist, er installiert halt Ruby in der entsprechenden Version, 02:36:40.330 --> 02:36:46.730 installiert mein, oder hat dir mein Zeug ausgecheckt und der rennt dann lässt einfach meine Tests abfeuern und 02:36:46.730 --> 02:36:50.010 der tut tatsächlich nur irgendwie den Exit-Code auswerten. 02:36:50.490 --> 02:36:52.970 Wenn der Exit-Code am Ende 1 ist, dann ist ein Test fehlgeschlagen, 02:36:53.050 --> 02:36:55.050 der schickt mir halt die Logdatei als Ausgabe. 02:36:55.210 --> 02:36:59.130 Ich muss dafür keine Infrastruktur machen, das integriert sich komplett in den Workflow. 02:36:59.290 --> 02:37:03.450 Wenn jemand einen Pull-Request auf GitHub stellt, wird Travis auch hellhörig, 02:37:03.530 --> 02:37:07.850 fängt an, die Tests darüber laufen zu lassen und kommentiert dann quasi an den Pull-Request. 02:37:08.890 --> 02:37:11.610 Ja, der würde laufen oder nee, der würde nicht laufen. 02:37:11.930 --> 02:37:13.770 Genau, und wenn es nicht läuft, dann muss ich ja gar nichts machen. 02:37:14.010 --> 02:37:15.610 Dann sagen wir mal so, siehst ja, ne? 02:37:15.850 --> 02:37:16.410 War nichts. 02:37:17.450 --> 02:37:17.690 Richtig. 02:37:18.410 --> 02:37:21.770 Und wenn es läuft, dann muss ich auch nichts machen, sondern ich klicke einfach auf Merch. 02:37:21.850 --> 02:37:22.330 Ungesehen. 02:37:22.490 --> 02:37:22.810 Bäm. 02:37:24.330 --> 02:37:25.770 Anscheinend geht noch alles. 02:37:26.490 --> 02:37:27.130 Quasi. 02:37:27.290 --> 02:37:28.730 Die Tests lügen nicht. 02:37:28.970 --> 02:37:35.770 Okay, Fleidi, du machst ja unter anderem noch unser neues CMS-Podding 02:37:35.770 --> 02:37:38.330 für Podcasting und sowas. 02:37:38.570 --> 02:37:41.850 Das benutzt ihr da oder testet ihr noch gar nicht? 02:37:42.170 --> 02:37:42.410 Was? 02:37:42.570 --> 02:37:42.890 Natürlich? 02:37:43.130 --> 02:37:43.930 Nee, nee, natürlich. 02:37:44.890 --> 02:37:48.970 Podding ist gerade ein relativ interessantes Beispiel, weil man so, 02:37:49.290 --> 02:37:54.170 also zumindest ich habe anhand von Podding, was Testen angeht, 02:37:54.250 --> 02:37:57.450 so ein bisschen viel, also schon relativ viel vom Spektrum gesehen. 02:37:57.530 --> 02:38:04.490 Ich habe angefangen, aus irgendwelchen Gründen kann ich das nicht oder kann ich es im Moment noch 02:38:04.490 --> 02:38:09.130 nicht, eine Anwendung vom Scratch testgetrieben zu entwickeln. 02:38:09.210 --> 02:38:16.010 Das heißt, ich brauche immer ein bestimmtes Minimum an Kontext, 02:38:16.490 --> 02:38:21.210 wie soll ungefähr die Anwendung funktionieren und wie soll es denn ungefähr aussehen. 02:38:23.130 --> 02:38:27.930 Und diesen Kontext brauche ich in Form von ausführbarer Software, dass ich mal sagen kann, 02:38:28.010 --> 02:38:31.610 okay, ich brauche irgendwas, das tut schon mal ein bisschen ungefähr das Richtige. 02:38:32.890 --> 02:38:34.890 Dann kann ich anfangen, irgendwie Tests zu schreiben. 02:38:34.970 --> 02:38:37.770 Und Podding war tatsächlich dann so eine iterative Geschichte. 02:38:37.930 --> 02:38:42.570 Zuerst gab es keine Tests, dann musste ich bei jedem Seitenaufruf, jedes Mal, 02:38:42.650 --> 02:38:45.290 wenn ich was geändert habe, ein paar Seiten durchklicken, um zu gucken, 02:38:45.370 --> 02:38:46.810 ob irgendwas explodiert. 02:38:47.290 --> 02:38:50.570 Das habe ich dann so langsam durch Integration-Tests ersetzt und gesagt, 02:38:50.650 --> 02:38:57.610 ja gut, Podding ist ja in der Hinsicht relativ flexibel, dass man die ganzen 02:38:57.610 --> 02:39:02.330 Themes und die ganzen Content, 02:39:02.490 --> 02:39:04.890 der drin ist und so weiter, den kann man ja ersetzen. 02:39:05.050 --> 02:39:11.530 Also Podding funktioniert so, dass alles in Flatfiles liegt und da im Endeffekt 02:39:11.770 --> 02:39:14.970 Templates und Themes und sonst was rausgeholt werden. 02:39:15.450 --> 02:39:19.850 Dann habe ich mir halt einen Integration-Test-Suite gebaut, 02:39:20.250 --> 02:39:24.570 die quasi ein fixes Theme, 02:39:25.210 --> 02:39:29.930 ein ganz minimales, und fixe Daten, die da drin sind, implementiert, 02:39:30.090 --> 02:39:35.210 sodass ich sagen kann, okay, wenn ich bestimmte Seiten aufrufe, dann möchte ich bestimmte Dinge auf diesen 02:39:35.210 --> 02:39:35.770 Seiten sehen. 02:39:35.850 --> 02:39:40.650 Das war dann mal meine Integration-Test-Suite und als ich dann die internen APIs einigermaßen gefestigt 02:39:40.730 --> 02:39:45.610 hatten, habe ich angefangen im Nachhinein Unitests zu schreiben, 02:39:45.770 --> 02:39:49.690 habe dann so lange refactored, bis ich dann quasi auch an einem Punkt war, 02:39:49.770 --> 02:39:52.090 dass ich einigermaßen testgetrieben entwickeln konnte. 02:39:52.170 --> 02:39:58.410 Und mittlerweile ist es so, dass die Basis von Podding, nämlich das 02:39:58.410 --> 02:40:03.450 Model-Framework, was wir da benutzen, was diese ganzen Dateien ausliest und dafür sorgt, 02:40:03.530 --> 02:40:07.370 dass es richtig funktioniert und dafür sorgt, dass man da Queries fahren kann und so weiter, 02:40:07.610 --> 02:40:13.850 das ist mittlerweile ein eigenes Ruby-Gem, was größtenteils durch Unitests abgedeckt ist. 02:40:14.290 --> 02:40:20.850 Also und dieses Gem heißt jetzt Milk, da sieht man auf GitHub eine fast leere 02:40:21.010 --> 02:40:26.530 README, die ich noch füllen muss, weil da momentan nur To-Do Write Gem Description und sowas drinsteht. 02:40:28.290 --> 02:40:35.090 Das ist in den letzten Wochen gerade aufgrund meiner Thesis und anderen Geschichten 02:40:35.330 --> 02:40:36.770 auch liegen geblieben. 02:40:37.730 --> 02:40:44.290 Aber tatsächlich bin ich da mittlerweile dazu übergegangen, testgetrieben zu 02:40:44.290 --> 02:40:48.290 entwickeln, Tests vorher zu schreiben, dann Features zu implementieren. 02:40:48.530 --> 02:40:55.170 Und mein Mitentwickler, der da auch noch mit dran arbeitet, versucht es auch größtenteils zu tun. 02:40:56.370 --> 02:41:00.770 Aber es ist halt schon ein Prozess und auch ein Lernprozess, 02:41:00.930 --> 02:41:04.690 zu wissen, wie schreibt man denn jetzt irgendwie Tests und wo fängt man an zu testen, 02:41:04.770 --> 02:41:08.850 was testet man, was testet man nicht und so weiter. 02:41:08.930 --> 02:41:15.250 Und ich müsste lügen, wenn ich behaupten würde, Potting hat momentan 02:41:15.890 --> 02:41:22.130 eine hundertprozentige Code-Coverage oder unglaublich super formulierte Tests, 02:41:22.210 --> 02:41:28.690 aber ich glaube, das Wichtige ist, dass man mal Tests hat und dass man dann anfängt zu refactern und den 02:41:28.690 --> 02:41:32.930 Code so zu bauen, dass er gut testbar ist. 02:41:33.090 --> 02:41:39.090 Also was auch noch eine ganz interessante Geschichte ist, als ich mit dem Unit testen bei Podding angefangen 02:41:39.090 --> 02:41:45.570 habe, da waren die Tests noch nicht wirklich Unit testbar, 02:41:45.650 --> 02:41:50.290 deswegen, da war der Code nicht besonders freundlich, Uni zu testen. 02:41:50.930 --> 02:41:54.050 Darum war der Testcode dafür furchtbar hässlich. 02:41:54.130 --> 02:41:57.330 Als ich dann angefangen habe zu refactorn, musste ich viele Dinge umbauen. 02:41:57.570 --> 02:42:03.970 Als netten Seiteneffekt habe ich jetzt eine Pluggable Storage Engine. 02:42:04.050 --> 02:42:07.250 Das heißt, für einfach für ein paar Integration Tests habe ich dann angefangen. 02:42:07.570 --> 02:42:10.450 Wäre doch ganz nett, wenn ich nicht aufs Dateisystem zugreifen müsste, 02:42:10.530 --> 02:42:17.490 sondern alle Sachen im Speicher laden oder in den Speicher 02:42:17.490 --> 02:42:20.130 reinschreiben oder aus dem Speicher laden könnte. 02:42:20.850 --> 02:42:24.850 Und so gibt es jetzt potenziell eine Schnittstelle, wo ich auch sagen kann, 02:42:24.930 --> 02:42:27.570 ja gut, wenn ich Bock drauf habe, kann ich mir auch einen Adapter schreiben, 02:42:27.730 --> 02:42:32.050 der Potting gegen Redis fährt oder Potting gegen MySQL fährt oder was auch immer. 02:42:32.130 --> 02:42:35.730 Wenn er eine bestimmte API implementiert und sowas, wäre dabei nie rausgekommen, 02:42:35.810 --> 02:42:39.650 wenn ich nicht irgendwann angefangen hätte, dafür einen Tests zu schreiben. 02:42:41.490 --> 02:42:47.970 Marc, zurzeit unser CMS für Binärgewitter ist ja so ein 02:42:47.970 --> 02:42:50.050 serious Dingsbombes-System. 02:42:50.210 --> 02:42:52.690 Ja, war zumindest mal auf Series aufgebaut. 02:42:53.170 --> 02:42:54.210 Zusammengeklöppelt hast. 02:42:54.370 --> 02:43:00.850 Auch da wird ja Travis CI benutzt, um Tests zu fahren und zu deployen. 02:43:02.850 --> 02:43:09.810 Travis CI hat auch eine coole Integration mit Heroku, indem du da einfach quasi 02:43:09.810 --> 02:43:11.970 noch, keine Ahnung, wie ging das eigentlich? 02:43:12.930 --> 02:43:17.250 Auf jeden Fall die Tests, die wir fahren, sind so ganz kleine Basistests. 02:43:17.330 --> 02:43:18.050 Im Grunde nur, dass er den. 02:43:18.210 --> 02:43:22.370 Ist der Feed noch da, dass er genau GD-Archive-Page, weil wenn die geht, 02:43:22.450 --> 02:43:25.330 hat er alle Markdown-Files komplett gepasst und den Titel rausgezogen. 02:43:25.410 --> 02:43:29.170 Also wenn du sonst eine kaputte Markdown-File irgendwie reinsteckst, dann explodiert er ganz fies. 02:43:29.410 --> 02:43:35.410 Und damit testen wir, dass zum Beispiel Pull Requests, wenn jemand ein Typo irgendwie einen Tippfehler 02:43:35.730 --> 02:43:39.570 verbessert, dass da nicht irgendwie unser Archiv hochfliegt, weil der aus irgendeinem Grund irgendwie 02:43:39.570 --> 02:43:42.130 UTF-7-Charaktere da eingefügt hat. 02:43:42.690 --> 02:43:45.010 Was es gibt, UTF-7, ganz leckhafte Sache. 02:43:46.130 --> 02:43:53.010 Genau, und der benutzt dann auch Travis CI, testet das Ganze auf Ruby 2.0 02:43:53.330 --> 02:43:55.250 und compiled das Ganze noch. 02:43:55.410 --> 02:44:01.250 Da kannst du einfach sagen, Deploy Provider Heroku, 02:44:01.410 --> 02:44:07.170 dann einen API-Key reinmachen und dann deployt er das da automatisch hin. 02:44:07.490 --> 02:44:08.690 Was ganz cool ist. 02:44:08.850 --> 02:44:14.370 Und der übernimmt quasi dann den kompletten Deployment-Prozess, wenn die Tests passen. 02:44:14.530 --> 02:44:18.370 Also wir vertrauen bei uns so extrem auf die Tests, dass wir alles ungesehen in Production schieben. 02:44:19.090 --> 02:44:20.530 Außerdem ist es uns auch egal. 02:44:21.090 --> 02:44:22.610 Ist ja jetzt Markegal. 02:44:23.010 --> 02:44:23.410 Richtig. 02:44:23.650 --> 02:44:30.530 Ja, gut, es ist ja nur eine Podcasting-Seite und nicht irgendwie ein riesengroßes Unternehmensweb auftritt 02:44:30.770 --> 02:44:34.850 oder irgendwas, was an zigtausend Kunden irgendwie rausgegeben wird. 02:44:34.930 --> 02:44:35.970 Deswegen können wir sowas machen. 02:44:36.050 --> 02:44:39.970 Aber es ist cool, dass es da so schön geht und deswegen funktioniert es ja auch, 02:44:40.050 --> 02:44:44.050 wenn jemand unsere Markdown-Files im GitHub einfach anpasst und wir sagen, 02:44:44.210 --> 02:44:47.810 jopp, merge, zack, ist irgendwie 15 Minuten später unsere Seite. 02:44:48.130 --> 02:44:51.090 Im Zweifelsfall können wir es auch einfach wieder rückgängig machen, 02:44:51.330 --> 02:44:56.130 aber da gilt halt so das alte Motto, wenige Tests ist besser als keine Tests. 02:44:56.210 --> 02:45:00.050 Und nur oberflächlich testen ist besser als gar nicht zu testen. 02:45:00.130 --> 02:45:04.690 Weil alles, was irgendwie automatisiert ist und dir zumindest eine gewisse Sicherheit gibt, 02:45:05.090 --> 02:45:10.850 ist schon mal gut, weil es dich nicht sonst nicht zuückhält, 02:45:11.410 --> 02:45:12.450 den Code zu ändern. 02:45:13.890 --> 02:45:18.130 Du hast halt einfach ein bisschen mehr Selbstbewusstsein, was deinen Code angeht, 02:45:18.210 --> 02:45:21.570 wenn du halt weißt, okay, da werden Tests automatisiert ausgeführt. 02:45:21.810 --> 02:45:25.810 Und man muss auch sagen, also ich schau gerade die Tests durch, ich bin ganz begeistert von mir selber. 02:45:25.970 --> 02:45:27.410 Erstens mal, es ist ein Smoke-Test. 02:45:27.570 --> 02:45:32.210 Smoke-Test generell ist so, im Grunde willst du nur sehen, ob es brennt. 02:45:32.290 --> 02:45:36.850 Also du startest den Test und wenn du dann rauch siehst, ist schlecht, wenn nicht, scheint alles gut zu sein. 02:45:36.930 --> 02:45:38.210 Solange es nicht brennt, ist okay. 02:45:38.370 --> 02:45:41.890 Und also wir testen erstmal, dass die Homepage ein 200er zurückgibt. 02:45:41.970 --> 02:45:47.090 Bedeutet, wenn du die App hochfährst und auf die Homepage schaust, sollte da, wenn es geht, kein Fehler sein. 02:45:47.410 --> 02:45:49.570 Wir testen, dass der Feed valide ist. 02:45:49.970 --> 02:45:53.330 Da habe ich sogar wohl eine eigene Assertion für irgendwie hochgebaut. 02:45:53.730 --> 02:45:59.010 Bedeutet, dass der diesem iTunes, XML, DTD-Dingens entspricht, 02:45:59.330 --> 02:46:01.650 dass da die ganzen Podcatcher mit klarkommen. 02:46:01.730 --> 02:46:04.050 Wir testen, dass der MP3-Feed workt. 02:46:04.370 --> 02:46:08.370 Wir testen, dass der MP3-Feed auch, dass du Feed-Size angeben kannst, 02:46:08.450 --> 02:46:10.770 dass du sagen kannst, ich will nur die letzten drei oder ich will die letzten, 02:46:11.010 --> 02:46:15.490 keine Ahnung was, dass du das Paging funktioniert auch noch. 02:46:15.810 --> 02:46:18.610 Das hat mir auch irgendwann neulich eingebaut, dieses Potlauf-Paging, 02:46:19.170 --> 02:46:21.330 das theoretisch wahrscheinlich auch funktioniert. 02:46:21.730 --> 02:46:23.490 Zumindest sagen die Tests, dass es funktioniert. 02:46:24.450 --> 02:46:25.570 Die Bürger-Tests anlüfen. 02:46:25.730 --> 02:46:26.290 Ich glaube nicht. 02:46:27.250 --> 02:46:28.130 Ich hab dir geschrieben. 02:46:28.290 --> 02:46:32.210 Genau, wir testen, dass Kategorien-Feeds funktionieren, dass wir also dieses Binärgewitter-Talk und 02:46:32.210 --> 02:46:34.290 Binärgewitter Speziale verschiedene Feeds machen können. 02:46:34.450 --> 02:46:39.010 Genau, also wenn ihr das, wenn ihr irgendwie diese Sendung total langweilig findet und immer nur die Talks 02:46:39.010 --> 02:46:39.330 hören wollt. 02:46:39.570 --> 02:46:40.370 Nur die lustigen Sendungen. 02:46:40.770 --> 02:46:45.010 Nur die lustigen Sendungen, dann könnt ihr die auch deabonnieren und könnt nicht sagen, 02:46:45.090 --> 02:46:48.130 ihr wollt alles, sondern ihr wollt nur Talk und nicht auch noch spezial. 02:46:48.370 --> 02:46:50.850 Und wir testen also wirklich sogar nicht nur, dass das Archiv lädt, 02:46:50.930 --> 02:46:54.290 sondern wir gehen durch jeden Haare-Link auf der Archive-Page durch und schauen, 02:46:54.370 --> 02:46:56.450 dass der lädt und dass da an 200 zurückkommt. 02:46:56.530 --> 02:46:58.770 Also dass jeder einzelne Eintrag auch funktioniert. 02:46:58.930 --> 02:46:59.650 Und das ist eigentlich schon. 02:47:00.130 --> 02:47:01.730 In dem Test habe ich letztens einen Fehler gefunden. 02:47:01.810 --> 02:47:02.210 So schön. 02:47:02.450 --> 02:47:02.850 Sehr gut. 02:47:03.490 --> 02:47:06.210 Im Test oder der Test schlugfehl. 02:47:06.530 --> 02:47:11.090 Und deswegen musstest du den doch letzte Woche anpassen. 02:47:11.170 --> 02:47:12.050 Nee, vorletzte Woche. 02:47:12.130 --> 02:47:15.250 Achso, ja, weil der ReckEx einfach super hart gefehlt hat. 02:47:16.370 --> 02:47:20.290 Es war natürlich auch so kreblich wie möglich, aber so die Haarefs mit irgendeiner Regular Expression 02:47:20.370 --> 02:47:25.890 extrahiert und da ist dann irgendwo ein Hochkommer war einfach dahinter nochmal. 02:47:26.130 --> 02:47:27.730 Und dann hat er einfach hartes Ding Greedy. 02:47:28.130 --> 02:47:30.370 Da habe ich Greedy Rackex-Zeug gedingst. 02:47:31.410 --> 02:47:33.890 Hast du gemerkt, dass Rekhex sowas machen normalerweise? 02:47:34.770 --> 02:47:35.570 Ah, paplabapp. 02:47:35.810 --> 02:47:36.530 Kranke Sache. 02:47:36.770 --> 02:47:37.810 Crazy shit. 02:47:38.370 --> 02:47:40.610 Felix, was testest du denn? 02:47:41.570 --> 02:47:43.810 Ich wenn ich teste, dann. 02:47:44.290 --> 02:47:44.930 Wenn überhaupt, ja. 02:47:45.170 --> 02:47:47.410 Wenn, dann ja, eigentlich war ja keine Fehler. 02:47:48.370 --> 02:47:53.090 Nee, tatsächlich habe ich besonders bei Testen, 02:47:53.330 --> 02:47:57.490 wie habe ich ja schon gesprochen, nicht so viel so Unit-Tests, so für die ganz kleinen Sachen, 02:47:57.650 --> 02:48:01.170 weil meine Projekte von meinem Gefühl her einfach nicht groß genug sind, 02:48:01.250 --> 02:48:03.650 dass ich da für jeden kleinen Shit irgendwie Dinge tun muss. 02:48:03.810 --> 02:48:06.370 Deswegen ist es meistens auch so Integrationstests. 02:48:06.450 --> 02:48:11.330 Das heißt, ich habe irgendwie ein Stück Software und ich will wissen, 02:48:11.410 --> 02:48:13.490 ob es am Ende das Richtige getan hat. 02:48:14.370 --> 02:48:19.410 Oder ich habe ein Stück Software geschrieben, was eine API von einem anderen Provider anspricht. 02:48:19.570 --> 02:48:23.410 Und ich will wissen, ob der Provider seine API quasi geändert hat, weil ich weiß, 02:48:23.490 --> 02:48:24.930 dass ja mein Code funktioniert. 02:48:25.730 --> 02:48:27.170 Sind immer die anderen schuld. 02:48:28.370 --> 02:48:31.170 Und das Problem ist ja meistens, was auch schon der Markt gesagt hat, 02:48:31.330 --> 02:48:34.290 dass zum Beispiel YouTube ändert seine API ab und zu. 02:48:35.730 --> 02:48:37.410 Ab und zu, dann, äh, was haben wir noch? 02:48:37.570 --> 02:48:42.290 Wir haben jetzt Code zum Beispiel für DCC. 02:48:43.090 --> 02:48:47.730 Dann haben wir Code für so Text-to-Speech. 02:48:50.290 --> 02:48:51.730 Text-to-Speech-AP quasi. 02:48:52.290 --> 02:48:54.210 Und für Speech-to-Text auch. 02:48:54.450 --> 02:48:58.130 Und solche Sachen, da kann es halt mal sein, dass sich der Shit ändert. 02:48:58.210 --> 02:49:01.090 Und es wäre dann voll unpraktisch, wenn es dann auf einmal nicht mehr tun würde. 02:49:01.650 --> 02:49:06.130 Und das ist jetzt alles auch im großen Repository, das heißt, wir haben da kein Problem, 02:49:06.210 --> 02:49:08.850 dass da zu wenig eingecheckt wird, dass das nicht auffallen würde. 02:49:10.210 --> 02:49:14.530 Genau, also das ist das, was ich meistens an Testcode schreibe. 02:49:14.610 --> 02:49:17.410 Das ist wirklich für das Ding aus. 02:49:17.650 --> 02:49:20.050 Und wenn's, ja, also quasi Smoke-Tests. 02:49:20.130 --> 02:49:22.130 Also wenn es kaputt gegangen ist, ist das doof. 02:49:22.290 --> 02:49:24.050 Und dann fällt es halt sofort auch auf. 02:49:24.130 --> 02:49:28.370 Und wenn es, wenn da irgendwie doch das Richtige passiert ist, dann ist es wohl gut genug. 02:49:29.330 --> 02:49:35.250 Ich glaube, das ist tatsächlich auch eine Frage, was für eine Verwendung man da im Hinterkopf hat, 02:49:35.970 --> 02:49:37.410 während man diesen Code schreibt. 02:49:37.490 --> 02:49:42.930 Wenn man jetzt sagt, okay, das ist irgendwie ein One-Shot-Projekt und das muss einmal tun oder muss einmal nur 02:49:42.930 --> 02:49:49.810 einen gewissen Use Case erfüllen und wird danach nie wieder weiterentwickelt oder nicht großartig erweitert, 02:49:49.890 --> 02:49:52.450 das soll keine neuen Features haben oder so, dann kann man sagen, okay, 02:49:52.690 --> 02:49:53.810 ist ja auch egal. 02:49:54.130 --> 02:50:00.610 Ich schreibe meinen Code jetzt so runter, dass er tut, dann tut es die Sachen für mich und ja, 02:50:00.850 --> 02:50:07.730 Tests brauche ich dann im Zweifelsfall nur um diesen eng eingegrenzten Use 02:50:07.730 --> 02:50:11.890 Case auszuprobieren oder irgendwie vielleicht auch gar nicht. 02:50:12.370 --> 02:50:16.370 Wenn man jetzt aber sagt, okay, ich möchte eine Library schreiben, die andere Leute benutzen wollen, 02:50:16.450 --> 02:50:21.250 oder ich möchte irgendwie wiederverwendbaren Code in meinem Projekt haben, 02:50:21.410 --> 02:50:27.330 oder ich habe vielleicht ein Projekt, wo ich gar nicht weiß, wo es in der Zukunft hingehen soll und das soll 02:50:27.330 --> 02:50:30.530 noch stark erweitert werden, was zum Beispiel bei meinem Thesis-Projekt der Fall war. 02:50:30.610 --> 02:50:35.810 Also da war es im Endeffekt auch so, ich habe das in Ruby geschrieben, 02:50:35.890 --> 02:50:41.410 ich habe da auch die Standard-Test-Tools, die wir jetzt vorhin schon besprochen haben, 02:50:41.730 --> 02:50:42.690 verwendet. 02:50:43.490 --> 02:50:49.330 Und da geht es halt wirklich um Firmendaten, die durchsuchbar gemacht werden sollen. 02:50:49.570 --> 02:50:52.850 Und da kann ich mich dann halt jetzt nicht mehr rausreden, von wegen, 02:50:52.930 --> 02:50:56.130 eh, das benutzt doch keiner, oder da ist es egal, ob es jetzt korrekt ist oder nicht, 02:50:56.370 --> 02:50:59.570 stört ja dann kein, sondern das muss halt funktionieren. 02:51:00.210 --> 02:51:02.050 Und da war es halt für mich wichtig. 02:51:02.290 --> 02:51:06.930 Ich wusste am Anfang meiner sechsmonatigen Thesis noch nicht, wo die Reise hingeht. 02:51:07.010 --> 02:51:11.490 Da war es halt wichtig, dass ich von Anfang an Tests habe, sodass ich die Flexibilität habe, 02:51:11.810 --> 02:51:18.690 nochmal vieles über den Haufen werfen zu können und trotzdem eine gewisse 02:51:18.690 --> 02:51:21.170 Sicherheit habe, dass mein Zeug noch funktioniert. 02:51:23.570 --> 02:51:23.890 Okay. 02:51:25.010 --> 02:51:26.610 Dann, wir haben ja Travis. 02:51:28.050 --> 02:51:30.530 So als Infrastruktur, die wir in vielen Projekten verwenden. 02:51:30.690 --> 02:51:31.410 Was gibt es noch so? 02:51:31.570 --> 02:51:32.130 Jenkins. 02:51:32.290 --> 02:51:32.770 CI? 02:51:33.490 --> 02:51:34.290 Was machen die. 02:51:34.850 --> 02:51:35.970 Jenkins war mal Hudson. 02:51:36.050 --> 02:51:37.810 Also es ist nicht Jenkins, ja, was heißt Jenkins CI? 02:51:37.970 --> 02:51:39.250 Das Projekt heißt Jenkins. 02:51:39.410 --> 02:51:44.850 Es ist im Grunde so ein ziemlich krasses Webinterface für Cron. 02:51:45.890 --> 02:51:46.770 Muss man tatsächlich sagen. 02:51:48.530 --> 02:51:49.730 Mit Java darunter. 02:51:50.130 --> 02:51:51.410 Jenkins kann irgendwie alles. 02:51:51.490 --> 02:51:55.250 Also was Jenkins als CI-Server oder was CI-Server ja generell machen, 02:51:55.330 --> 02:52:00.610 ist, er lauscht entweder auf ein Repository, schaut da alle paar Minuten nach, 02:52:00.690 --> 02:52:03.650 ob sich was geändert hat, wenn sich was geändert hat, dann führt er irgendwas aus, 02:52:03.890 --> 02:52:07.490 oder er führt einfach in einem gewissen Zeitplan irgendwas aus. 02:52:08.690 --> 02:52:13.570 Normalerweise checkt er das Repository dann aus, dann hast du da irgendeinen Workspace und dann sagt er so, 02:52:13.650 --> 02:52:14.610 und jetzt was willst du machen? 02:52:14.690 --> 02:52:18.450 Dann kannst du entweder, wenn du in der Java-Welt bist, kannst du vielleicht einen Ahnt-Task machen, 02:52:18.530 --> 02:52:21.890 sagst du einfach, okay, wenn sich was ändert, führ den Antask aus, mach ein Bild, 02:52:21.970 --> 02:52:24.050 schaut, dass der Bild noch funktioniert, dann ist okay. 02:52:24.290 --> 02:52:27.970 Oder du sagst halt, ja, dann führ mal ein bisschen Shell aus und dann kannst du im Grunde auch machen, 02:52:28.050 --> 02:52:28.690 was du willst. 02:52:28.770 --> 02:52:35.730 Also für Ruby-Projekte kannst du einfach sagen, okay, führ doch mal jetzt Shell aus und rake Spec 02:52:35.890 --> 02:52:37.890 und dann lass mal meine Specks laufen. 02:52:38.850 --> 02:52:42.690 Und wenn du dann alles richtig gemacht hast, kannst du dann im Nachhinein auch noch sagen, 02:52:42.770 --> 02:52:48.130 okay, wenn das jetzt gelaufen ist, dann haben wir jetzt noch einen Post-Build-Step. 02:52:48.370 --> 02:52:53.490 Und zwar nehmen wir das JUnit XML-Plugin-Dingens da und sagen, 02:52:53.570 --> 02:52:58.850 okay, dann jetzt nimm alle XML-Dateien in folgenden Pfad und das ist dein Resultat. 02:52:58.930 --> 02:53:02.690 Und Jenkins liefert dann im Webinterface auch noch so einen schönen kleinen Graph, 02:53:02.770 --> 02:53:05.170 wo du siehst, wann wie viele Tests fehlgeschlagen sind. 02:53:05.490 --> 02:53:10.370 Es gibt also Plugins für ungefähr alles, also für alle Versionskontrollsysteme. 02:53:10.610 --> 02:53:15.170 Du kannst dann irgendwelche Sachen noch sagen, ja, okay, wenn der Test erfolgreich war, 02:53:15.330 --> 02:53:21.490 dann lad doch einen neuen Tarball irgendwo hoch und Jenkins hat unendlich viele Plugins, 02:53:21.570 --> 02:53:24.690 alles ist immer kaputt, aber größtenteils geht es eigentlich. 02:53:25.490 --> 02:53:25.730 Okay. 02:53:25.970 --> 02:53:30.450 Das ist Jenkins, war eh mal Nick Hudson und ist ein Java-Server. 02:53:30.690 --> 02:53:36.450 Was gibt es noch für Infrastruktur, die man so verwenden kann, so wenn man testen will? 02:53:37.010 --> 02:53:37.730 Also steht noch. 02:53:38.130 --> 02:53:43.890 Travis CI hatten wir schon drüber gesprochen, das noch ganz kurz ist von einer Firma in Berlin gehostet. 02:53:44.050 --> 02:53:44.450 Das ist für mich. 02:53:45.250 --> 02:53:48.770 Ist für Open Source Angebote, wie Marc schon erwähnte, kostenlos. 02:53:48.930 --> 02:53:53.970 Da bin ich dann ein bisschen limitiert, glaube ich, ich kann nur einen Job ausführen oder so sequenziell. 02:53:54.370 --> 02:53:56.530 Und man ist nicht prioritär, gerade ganz oben. 02:53:56.770 --> 02:53:57.490 Genau, genau. 02:53:57.650 --> 02:54:04.050 Und für Unternehmen kostet es dann halt irgendwie im, glaube ich, dreistelligen Euro-Bereich monatlich locker 02:54:04.050 --> 02:54:04.210 mal. 02:54:04.930 --> 02:54:06.770 Oder man hat ein bisschen mehr Primo gibt es. 02:54:07.490 --> 02:54:13.010 Die Freien sind öffentlich, also jeder kann auf der Seite sehen, wer baut gerade welches Projekt und was 02:54:13.010 --> 02:54:13.490 machen die da. 02:54:13.730 --> 02:54:15.970 Genau, es ist analog zu GitHub im Prinzip. 02:54:16.370 --> 02:54:18.290 Ja, vom Modell her. 02:54:19.410 --> 02:54:26.210 Vom Geschäftsmodell her sind viele der Dienstleister, die wir ansprechen, die orientieren sich da an GitHub. 02:54:26.290 --> 02:54:28.290 Also Travis ist da auch so ein Fall. 02:54:28.530 --> 02:54:33.730 Da ist es halt auch so wie bei GitHub, deine kostenlosen Repositories, 02:54:33.810 --> 02:54:37.410 die sind halt öffentlich zugänglich und ein bisschen eingeschränkt, 02:54:37.570 --> 02:54:41.010 aber nicht so, dass es ein Open-Source-Projekt jetzt irgendwie stören würde. 02:54:42.370 --> 02:54:49.170 Und so gilt es halt auch für so zum Beispiel Coveralls, was so ein Dienstleister ist, 02:54:49.250 --> 02:54:56.050 der dir dann quasi noch bei einem Travis CI-Run noch Code Coverage Reports generiert und 02:54:56.450 --> 02:55:00.130 dir dann da drauf so Buttons baut, die du in deine README einbauen kannst, 02:55:00.210 --> 02:55:04.610 sodass Leute auch gleich sehen, okay, wie hoch ist denn deine Code-Coverage von deinem Projekt. 02:55:05.010 --> 02:55:08.690 Ist tatsächlich auch was, das muss ich in meine Sachen demnächst, wenn ich da mal ein bisschen 02:55:08.690 --> 02:55:10.370 weiterentwickel, auch einbauen. 02:55:10.530 --> 02:55:14.690 Dass ich dann halt auch sage, hey, okay, ich möchte jetzt mal ein bisschen Code Coverage haben und möchte halt 02:55:14.690 --> 02:55:19.970 dann halt auch mal wissen, wie viel, was für ein Prozentsatz meines Codes wird denn tatsächlich durch Tests 02:55:19.970 --> 02:55:21.170 ausgeführt. 02:55:21.970 --> 02:55:27.650 Genau, noch ein Continuous Integration Server ist Bamboo von Atlashian. 02:55:27.810 --> 02:55:30.610 Das ist die Firma, die dieses Jira oder Jira macht. 02:55:30.850 --> 02:55:32.930 Ja, da Confluence zum Beispiel machen die auch. 02:55:33.170 --> 02:55:34.850 Genau, dieses Wiki. 02:55:35.250 --> 02:55:38.530 Und Bamboo ist ein Continuous Integration Server. 02:55:38.930 --> 02:55:43.170 Das ist proprietär und entsprechend kostet es dann, 02:55:43.570 --> 02:55:48.930 ich glaube, man kann, man kann so eine Art Community Edition runterladen oder zumindest eine Test Edition für 02:55:48.930 --> 02:55:49.970 Open Source. 02:55:50.370 --> 02:55:56.610 Und hat natürlich dann Vorteile insofern, weil es sich super gerade mit Confluence und Gyra und so weiter 02:55:56.610 --> 02:55:57.810 integrieren lässt. 02:55:59.650 --> 02:56:05.490 Was bei mir im Umfeld noch teilweise in Einsatz kommt, also gerade im Bereich 02:56:05.490 --> 02:56:12.210 iOS-Applikationen und Mac-Applikationen gab es bisher immer nur sehr kreblilige 02:56:12.210 --> 02:56:15.570 Lösungen, Jenkins einzusetzen mit irgendwelchen hässlichen Plugins. 02:56:15.890 --> 02:56:19.490 Also das Problem dabei ist ja immer, dass man bei iOS einen Mac braucht, 02:56:19.570 --> 02:56:23.890 um das zu bauen und dann gibt es im Prinzip ein Command-Line-Tool, das X-Code-Build, 02:56:23.970 --> 02:56:25.810 mit dem kann man Projekte bauen. 02:56:27.490 --> 02:56:33.250 Und zum einen gibt es dann zum Beispiel bei Travis CI die Funktion, 02:56:33.570 --> 02:56:37.650 dass iOS und Mac-Applikationen gebaut und getestet werden können. 02:56:38.050 --> 02:56:44.210 Und seit Xcode 5, das mit dem iOS 7 jetzt vor kurzem rauskam, gibt es auch sogenannte Xcode-Bots, 02:56:44.850 --> 02:56:47.730 die man dann auf einem Mac OS 10 Server laufen lassen kann. 02:56:47.810 --> 02:56:52.690 Das ist so im Prinzip so ein Hudson und so ein Jenkins on Steroids. 02:56:52.770 --> 02:56:55.890 Also das funktioniert halt sehr sleek, sehr Apple-mäßig wieder. 02:56:56.290 --> 02:57:00.610 Hat dann aber große Probleme, zum Beispiel, wenn man CocoPots oder so einsetzt, 02:57:00.690 --> 02:57:06.450 dann funktioniert es wieder nicht so gut und deshalb vertrauen wir zum Beispiel auch dann intern eher auf 02:57:06.450 --> 02:57:07.410 Travis CI. 02:57:07.730 --> 02:57:10.690 Das kostet halt ein bisschen mehr, aber es funktioniert besser. 02:57:10.850 --> 02:57:15.570 Ist halt so richtig aus der Community irgendwie entstanden und was Apple sich da so vorstellt, 02:57:15.650 --> 02:57:17.570 ist eher in so einer heilen Welt. 02:57:18.050 --> 02:57:22.130 Man hatte auch bei Apple ja lange nicht das Gefühl, dass sie wirklich selber Tests einsetzen. 02:57:23.570 --> 02:57:30.050 Also wusste man auch von einigen Apps, dass sie auch von WWDC-Qotes von einzelnen 02:57:30.050 --> 02:57:33.890 Apple-Ingineers, dass sie so mehr oder weniger gesagt haben, naja, wir haben die App halt so runtergeschrieben 02:57:34.050 --> 02:57:34.370 und. 02:57:35.090 --> 02:57:36.290 Wir machen ja keine Fehler, ist ja klar. 02:57:36.530 --> 02:57:38.530 Genau, die sind ja von Apple, die machen keine Fehler. 02:57:38.850 --> 02:57:41.330 Das war ein weißes Jackett. 02:57:41.810 --> 02:57:43.890 Ja, genau, ein weißes T-Shirt. 02:57:44.130 --> 02:57:49.490 Und Felix, was setzt du noch so ein? 02:57:49.730 --> 02:57:50.930 Hast du hier noch Wimpern? 02:57:51.090 --> 02:57:56.930 Achso, genau, ich habe nicht genau gewusst, wo ich es denn dazu tun soll, aber ich bin nicht. 02:57:57.090 --> 02:57:59.490 Genau, das ist keine Infrastruktur, aber ein tolles Plugin wahrscheinlich. 02:57:59.730 --> 02:58:04.530 Genau, also ich wollte darauf nochmal hinweisen, Syntastic ist quasi alles, 02:58:05.410 --> 02:58:11.810 ist quasi ein Syntax-Check-Tool für Wim, also für so Fricke-Kommandozeilenzeugs. 02:58:12.450 --> 02:58:13.890 Das nützt sich tatsächlich auch für meine Spieler. 02:58:14.130 --> 02:58:20.610 Genau, und das kann unter anderem, also es kann quasi alle Programmiersprachen auf Syntax checken. 02:58:20.690 --> 02:58:26.450 Und das macht, wenn du für Python das Zeugs installiert hast, dann checkt er auch PEP 8, 02:58:26.530 --> 02:58:31.570 das heißt dieser quasi der Guide, wie man seinen Code quasi schön macht. 02:58:32.130 --> 02:58:36.610 Und wie man den strukturiert, also beziehungsweise wie man den so schreibt, 02:58:36.690 --> 02:58:39.330 dass er überall gleich aussieht, quasi. 02:58:39.490 --> 02:58:41.330 Und ich bin mir ziemlich sicher, das gibt es für alles. 02:58:41.490 --> 02:58:45.090 Andere auch und die können auch irgendwie Haske und JavaScript und so. 02:58:45.170 --> 02:58:48.530 Und das ist eigentlich ein ziemlich cooles Teil und ich wollte kurz nur darauf hinweisen. 02:58:49.250 --> 02:58:54.450 Genau, also so Lint gibt es ja auch immer mehr für alle möglichen Sprachen. 02:58:54.770 --> 02:58:58.050 JS-Lint und Ruby Lint und was es auch immer gibt. 02:58:58.450 --> 02:59:05.170 Lint sind im Endeffekt so Tools, die deinen Code auf bestimmte Eigenschaften oder bestimmte 02:59:05.170 --> 02:59:06.050 Patterns untersuchen. 02:59:06.130 --> 02:59:10.050 Im Endeffekt ist es statische Code-Analyse mit so ein bisschen Best Practices kombiniert, 02:59:10.130 --> 02:59:16.530 dass man sagt, okay, du machst jetzt JavaScript, also mach doch mal bitte irgendwie 02:59:16.530 --> 02:59:18.610 Strichpunkte hinter deine Statements. 02:59:19.730 --> 02:59:21.410 Weil die coolen Kids benutzen das so. 02:59:21.570 --> 02:59:21.970 Ja, genau. 02:59:22.050 --> 02:59:29.010 Oder oder keine Ahnung, oder rück deinen Code richtig ein oder keine Ahnung. 02:59:29.330 --> 02:59:31.250 Zwei New Lines nach irgendwie Functions oder so ein Shit. 02:59:31.490 --> 02:59:33.890 Ja, genau, also bestimmte, da kann man halt dann bestimmte Dinge. 02:59:35.250 --> 02:59:40.050 Bestimmte Dinge, die in der Programmiersprache als Idiom gelten und da irgendwie gewünscht sind und dass man 02:59:40.050 --> 02:59:41.810 dann irgendwie coolen Code schreiben kann. 02:59:42.210 --> 02:59:44.450 Sowas überprüfen halt diese Lint-Tools. 02:59:45.910 --> 02:59:48.550 Ich weiß nicht, ob es wirklich zu Tests dazugehört, aber irgendwie. 02:59:48.870 --> 02:59:55.830 Ja, es geht ja auch um Codequalität und sowas kann man dann halt relativ schön 02:59:56.070 --> 02:59:59.830 automatisiert machen mit sowas. 02:59:59.910 --> 03:00:06.310 Oder JS-Hint gibt es dann auch noch für diejenigen, denen die Regeln in JS-Lint nicht passen. 03:00:06.630 --> 03:00:11.190 Also ich kenne es jetzt größtenteils als JavaScript, weil ich das größtenteils in meiner Zeit als 03:00:11.190 --> 03:00:13.030 JavaScript-Entwickler benutzt habe. 03:00:13.910 --> 03:00:16.550 Gibt es aber auch in allen möglichen anderen Sprachen. 03:00:16.950 --> 03:00:18.070 Was ist Faker? 03:00:18.470 --> 03:00:19.030 Faker-Faker. 03:00:19.590 --> 03:00:20.150 Faker. 03:00:20.550 --> 03:00:26.550 Und ich habe es heute entdeckt, ich weiß nicht genau wo und wie, aber ich hätte das jetzt in so Richtung 03:00:26.550 --> 03:00:28.390 Factory Girl eingestuft. 03:00:28.950 --> 03:00:29.590 Aber es ist was komplett. 03:00:29.830 --> 03:00:31.350 Nee, nee, es kommt wie Faker in Ruby. 03:00:31.510 --> 03:00:33.110 Achso, das ist genau Faker in Ruby. 03:00:33.270 --> 03:00:34.070 Und es ist so wie Faker. 03:00:35.270 --> 03:00:37.510 Faker in Data Pearl, da wo es nämlich ursprünglich ist. 03:00:39.430 --> 03:00:40.390 Hallo, was macht es? 03:00:41.270 --> 03:00:46.630 Das ist quasi, es erzeugt dir Text, beziehungsweise das, was du jetzt halt fragst oder eine Adresse, 03:00:46.870 --> 03:00:51.270 zufällig und Namen, E-Mails, Postleitzahlen, 03:00:51.430 --> 03:00:52.790 komplette Leute. 03:00:53.830 --> 03:00:56.150 Wenn man jetzt einfach mal eine Datenbank voll machen will mit Adressen, 03:00:56.230 --> 03:00:59.670 dann bam nimmst du einfach so einen Faker und fakes dir den ganzen Schiff. 03:01:00.070 --> 03:01:04.950 Hier, also was die Tests allein schon City, Postcode, Company, 03:01:05.190 --> 03:01:09.590 Lorem Ipsum, Numbers, Streetnames, Internet, 03:01:09.670 --> 03:01:10.630 was zum Teufel ist Internet. 03:01:10.950 --> 03:01:11.830 Ja, du kannst Internet! 03:01:12.390 --> 03:01:15.510 Du kannst ja auch zum Beispiel E-Mail-Adressen sowas rauslassen, was echt cool ist. 03:01:15.750 --> 03:01:20.950 Du kannst auch sagen, hier E-Mail-Adressen mit Separatern, mit IPv6-Adressen generieren lassen. 03:01:21.190 --> 03:01:23.990 Genau, mit nur Free-Mailer zum Beispiel kannst du ja auch rauslassen. 03:01:24.310 --> 03:01:27.830 Und so UTF8-Daten und T-Daten. 03:01:28.070 --> 03:01:28.470 Richtig. 03:01:28.870 --> 03:01:30.070 Okay, sehr cool einfach. 03:01:30.310 --> 03:01:32.630 Wollte ich nur mal darauf hinweisen, finde ich cool. 03:01:32.790 --> 03:01:35.430 Nachdem wir jetzt irgendwie nach über drei Stunden über Testing geredet haben, 03:01:35.590 --> 03:01:39.510 jetzt die eigentlich entscheidende Frage, braucht man das überhaupt? 03:01:41.270 --> 03:01:44.630 Ja, also wenn, wenn du, es kommt drauf an, wenn du, ich finde halt, 03:01:44.710 --> 03:01:49.430 wenn du ein Kundenprojekt hast und du hast nicht vor, das Ding zu maintainen, 03:01:49.510 --> 03:01:54.470 sondern du willst es denen einfach abliefern und dann sagen, Tschö mit Ö und es ist vielleicht so 03:01:54.470 --> 03:01:57.430 durchsetzbar, dann kannst du es auch mal ohne Tests versuchen. 03:01:57.830 --> 03:02:00.630 Muss halt hoffen, dass es, also wenn es nicht zu komplex ist. 03:02:00.870 --> 03:02:04.950 Aber sobald du halt komplexe Software, entweder generell komplexe Software hast oder Software, 03:02:05.030 --> 03:02:10.550 die du über eine längere Zeit maintainen willst, sparst du dir durch Tests einfach Zeit und kannst auch 03:02:10.550 --> 03:02:11.670 Features einfach entwickeln. 03:02:12.070 --> 03:02:15.910 Also die harte Realität ist natürlich auch die, dass häufig gerade so im Budget, 03:02:15.990 --> 03:02:21.670 wenn man Dienstleister ist, manchmal oder häufig kein Budget für Tests bleibt. 03:02:22.630 --> 03:02:27.350 Und dass auch, als aus meiner Erfahrung, so das Erste ist, 03:02:27.430 --> 03:02:33.270 was zwangsweise hinten unterfällt, wenn der Kunde irgendwie das Budget kappt oder wenn entsprechende Deadlines 03:02:33.270 --> 03:02:37.430 gerissen werden, dann passiert es halt häufiger, gerade so wie Marc das beschrieben hat, 03:02:37.510 --> 03:02:39.350 dass es so eine Einmalablieferlösung ist. 03:02:39.910 --> 03:02:42.950 Wenn man das erkennt, dann fallen halt Tests als erstes hinten unter, 03:02:43.030 --> 03:02:46.310 weil natürlich tun die erstmal dem laufenden Programm nichts bei. 03:02:46.790 --> 03:02:53.350 Wenn man aber möchte, dass eine Sache weiter maintained wird, dann ist es auf jeden Fall 03:02:53.350 --> 03:02:55.350 ratsam, Tests zu haben. 03:02:55.510 --> 03:03:00.230 Ich kenne es von meinem Anwendung so, also ich konnte ja vorher bei Projekten nicht viel sagen, 03:03:00.470 --> 03:03:03.990 weil ich im Prinzip fast nur Hochgeheimes für Kunden mache. 03:03:04.070 --> 03:03:04.630 Haha. 03:03:06.150 --> 03:03:11.670 Da ist es so, dass ich mindestens, wenn ich einen Bug habe, dass ich danach ein Test Case schreibe, 03:03:11.830 --> 03:03:16.230 dass der Bug nicht mehr auftritt und dann habe ich dadurch durch, dass ich die ganzen Bugs, 03:03:16.310 --> 03:03:20.550 die ich jemals hatte, abgedeckt habe und mich vor Regressions geschützt habe, 03:03:20.630 --> 03:03:26.230 irgendwann auch eine relativ dichte Test-Story, Cover Story in der Hinsicht, 03:03:26.310 --> 03:03:28.150 dass ich ruhig schlafen kann nach Zwiebeln. 03:03:28.390 --> 03:03:31.270 Dann auch mehr Acceptance-Tests oder mehr Unit-Tests, wo du da. 03:03:31.590 --> 03:03:32.710 Das kommt ganz drauf an. 03:03:33.030 --> 03:03:37.910 Also beispielsweise in gewissen Bereichen, in gewissen Projekten fangen, 03:03:38.070 --> 03:03:42.550 also wenn ich Unit-Tests machen will, sagen wir so rum, dann fange ich in der Regel gleich damit an, 03:03:42.870 --> 03:03:47.750 weil es sonst am Ende tatsächlich schwierig ist, nachträglich das Ganze so Unit-Testbar zu machen. 03:03:47.910 --> 03:03:53.990 Also ich versuche immer Code entsprechend zu schreiben, aber das gerade so unter Zeitdruck oder so 03:03:54.310 --> 03:03:55.670 verschwindet es dann manchmal. 03:03:55.750 --> 03:03:59.830 Oder eben, wenn man merkt, okay, das ist halt One-Use-Class, so nach dem Motto, 03:04:00.310 --> 03:04:02.150 dann verschwindet das gerne mal. 03:04:02.630 --> 03:04:07.670 Und dann sind es halt recht häufig, gerade so Acceptance-Tests, also gerade so zum Beispiel Webfronts einfach 03:04:07.670 --> 03:04:10.870 kurz durchtesten mit Selenium, das besprechen wir ein andermal, glaube ich, 03:04:11.110 --> 03:04:16.310 was man damit alles machen kann, weil ich, äh, weil ich dann wenig Möglichkeit habe, 03:04:16.470 --> 03:04:19.590 jetzt bis auf den Unit-Level runterzugehen. 03:04:20.630 --> 03:04:26.550 Und was für mich an der Sache das eigentlich Entscheidende ist, wir hatten vorher schon das Thema weniger 03:04:26.550 --> 03:04:29.270 Tests, wenig Tests sind besser als keine Tests. 03:04:29.590 --> 03:04:34.230 Für mich machen Tests immer im Zusammenhang mit Continuous Integration erst Sinn. 03:04:34.790 --> 03:04:39.590 Ich habe in einem großen Unternehmen gearbeitet, ich arbeite jetzt als Entwickler hauptsächlich alleine oder 03:04:39.590 --> 03:04:40.470 in kleinen Teams. 03:04:40.630 --> 03:04:47.110 Und in beiden Fällen ist es so, dass ich möchte, dass meine Tests, meine Integration automatisch getestet 03:04:47.110 --> 03:04:47.430 wird. 03:04:47.990 --> 03:04:52.310 Aus dem einfachen Grund, erstens will ich nicht ständig irgendwie Tests anstoßen müssen, 03:04:52.390 --> 03:04:53.350 weil dann mache ich es selber nicht. 03:04:53.430 --> 03:04:57.590 Also da muss man sich an der eigenen Nase fassen und realisieren, dass man das nicht macht. 03:04:57.830 --> 03:05:04.710 Also niemand schreibt freiwillig Tests und genauso wird er sie dann irgendwie nicht freiwillig einfach so 03:05:04.710 --> 03:05:07.270 irgendwie die ganze Zeit laufen lassen, weil das kostet ja Zeit. 03:05:07.670 --> 03:05:12.230 Und gleichzeitig ist das Problem auch immer, wenn ich andere im Team habe, 03:05:14.870 --> 03:05:18.390 dann gibt es, so ist halt das soziale Gefüge, es gibt immer dann den einen, 03:05:18.470 --> 03:05:22.070 der immer die Tests laufen lässt, bei dem sie dann fehlschlägen und der ist dann auch noch gleich alles fixt 03:05:22.230 --> 03:05:23.510 und die anderen machen irgendwie nichts. 03:05:23.750 --> 03:05:28.230 Das ist so typische leider Menschen- und Entwicklerdynamik, die sich da irgendwie sozial breit macht. 03:05:28.630 --> 03:05:29.590 Bei mir funktioniert es. 03:05:29.830 --> 03:05:33.670 Genau, und dafür ist ein Continuous Integration Server super, weil das ist so eine, 03:05:33.830 --> 03:05:36.630 sag ich mal, so eine moralische Instanz, die lügt nie. 03:05:36.950 --> 03:05:43.750 Wenn der Continuous Integration Server sagt, das baut nicht und der letzte Commit war von dem Matt, 03:05:43.990 --> 03:05:47.430 ja, dann schämt sich der Matt aber ganz deutlich. 03:05:47.670 --> 03:05:52.950 Und dann weiß auch jeder, wer zuständig ist und dann habe ich so automatisch so ein Gefühl, 03:05:53.030 --> 03:05:55.430 okay, ich muss das jetzt auch selber wieder gerade biegen. 03:05:56.070 --> 03:06:00.710 Also das hilft auch im sozialen Gefüge bei der Entwicklung dann eben sehr gut. 03:06:00.950 --> 03:06:03.670 Dass da nicht immer man selber mit dem Finger auf jemanden zeigen muss, 03:06:03.750 --> 03:06:07.590 sondern das hat man ja gewissermaßen der Fehlerverursacher selber gemacht. 03:06:07.910 --> 03:06:10.390 Ich finde es immer nett, das gibt es dann auch so Plugins für Jenkins, 03:06:10.470 --> 03:06:12.790 wo du dann externe USB-Sachen steuern kannst. 03:06:13.190 --> 03:06:14.230 So ein Rocket Launcher, ja. 03:06:14.390 --> 03:06:14.870 Rocket Launcher. 03:06:14.950 --> 03:06:18.310 Aber das Schönste, was ich fand, war bisher so ätherische Öl-Duftlampen. 03:06:18.950 --> 03:06:22.550 Die heizen das einfach auf und wenn der Bild fehlschlägt, riecht es nach Banane. 03:06:23.030 --> 03:06:27.190 Wenn jemand ins Büro kommt und es riecht nach Banane, dann wissen alle, da ist irgendwas schlecht. 03:06:27.430 --> 03:06:28.710 Und ich denke, da kannst du über so. 03:06:29.350 --> 03:06:30.550 Gut, wenn es nur Banane ist. 03:06:30.710 --> 03:06:35.750 Ja, und wenn es irgendwie die ganze Zeit nach, keine Ahnung, Flieder oder so riecht oder so, yeah, baby. 03:06:37.910 --> 03:06:41.190 Grüne Bild und auf einmal so, oh fuck, ich rieche Banane. 03:06:41.590 --> 03:06:47.830 Ich habe auch tatsächlich schon von sehr fragwürdigen Arbeitsumgebungen gehört, wo. 03:06:48.230 --> 03:06:55.030 Stromschläger an, wo das Türschloss zum Entwicklerbüro an einen Continuous Integration Server gekoppelt wird. 03:06:56.150 --> 03:07:00.790 Und die Tür geht einfach nicht auf, die Tür geht dann einfach ab einer gewissen Uhrzeit nicht mehr auf, 03:07:01.110 --> 03:07:04.230 bevor die can't do that. 03:07:05.030 --> 03:07:05.910 You have to fix me. 03:07:12.070 --> 03:07:17.910 Aberfürsten die kleinen Tabletten runter ist als Anekdote vielleicht ganz, ganz lustig. 03:07:18.630 --> 03:07:23.510 Ja, also es gibt das Tolle darin ist, dass es ja da, sage ich mal, eine sehr kreative Szene drumherum gibt, 03:07:23.670 --> 03:07:29.430 allein schon eben dann so Lampen oder so dann dran zu koppeln und entsprechende Farben auch 03:07:30.070 --> 03:07:34.550 einzusetzen und das, sag ich mal, 03:07:34.710 --> 03:07:38.070 ein bisschen positiver anzugehen, als jetzt irgendwie den krassen Druck darauf auszuüben. 03:07:38.150 --> 03:07:40.950 Ja, sowas auch halt ein bisschen spielerisch zu sehen. 03:07:41.270 --> 03:07:47.190 Es ist dann irgendwie doch auch mal ein bisschen so, Gamification funktioniert doch eigentlich schon. 03:07:47.270 --> 03:07:51.590 Und wenn ich dann meine Code-Coverage ein bisschen hochpushen kann und ich kann irgendwie schlechte 03:07:51.590 --> 03:07:56.550 Codemetriken rausnehmen oder ich sorge dafür, dass meine Tests schneller durchlaufen, 03:07:57.270 --> 03:07:59.750 dann tut es dem Ego eigentlich schon ganz gut. 03:07:59.830 --> 03:08:05.270 Oder auch wenn man sagen kann, okay, ich bin jetzt so morgens, ich bin jetzt total unkreativ, 03:08:05.590 --> 03:08:09.430 ich bin irgendwie, hab einen schlechten Tag, mir geht es gerade überhaupt nicht gut. 03:08:10.390 --> 03:08:14.390 Da ist es wahrscheinlich keine gute Idee, neue Features zu implementieren, 03:08:14.470 --> 03:08:18.310 aber vielleicht kann man doch mal ein paar Sachen sich rannehmen, refactern, 03:08:19.030 --> 03:08:23.990 vielleicht ein paar Tests dazu schreiben, dann fühlt man sich erstens produktiv und zweitens tut man, 03:08:24.070 --> 03:08:29.190 trotz dass man irgendwie gerade schlecht drauf ist, irgendwas Positives für sein Projekt. 03:08:30.870 --> 03:08:36.790 Und ich denke, man muss das auch nicht immer so als super Kostenfaktor rechnen, 03:08:37.030 --> 03:08:41.430 weil wenn man das tatsächlich mal in seine normale Arbeitsweise integriert hat, 03:08:41.510 --> 03:08:43.750 dann kostet es nicht mehr so wirklich viel Zeit. 03:08:44.150 --> 03:08:51.110 Und wenn man mal gelernt hat, stabile Tests zu schreiben und dementsprechend auch gut testbaren 03:08:51.190 --> 03:08:52.950 Code, dann ist es auch nicht mehr so teuer. 03:08:53.430 --> 03:08:56.870 Ist natürlich die Sache, du musst in der Designphase, also um testen zu können, 03:08:56.950 --> 03:08:59.350 musst du ja wissen, wie dein Design aussieht. 03:08:59.430 --> 03:09:03.990 Bedeutet, gerade wenn du so explorativ entwickelst, finde ich, Testdriven wäre damit einfach nur störend, 03:09:04.070 --> 03:09:06.790 weil du baust dir einen Test und dann am Ende weißt du, dass der Test bei dir ist. 03:09:07.190 --> 03:09:08.310 Das ist das, was ich gemeint habe. 03:09:08.390 --> 03:09:12.950 Ich kann aktuell, wenn ich irgendwie Privatprojekte für mich entwickle, 03:09:13.350 --> 03:09:19.590 dann weiß ich oft noch gar nicht, was soll denn die Applikation oder was soll denn meine Library oder was auch 03:09:19.590 --> 03:09:20.790 immer irgendwann mal tun. 03:09:20.870 --> 03:09:26.390 Und dann fange ich halt mal an, so einen Prototypencode runterzukoden, 03:09:26.630 --> 03:09:30.390 der dann irgendwann mal mit Tests ausgestattet wird und dann so lange refactored wird, 03:09:30.470 --> 03:09:35.670 bis von dem ursprünglichen Code eigentlich nichts mehr übrig bleibt. 03:09:35.910 --> 03:09:36.230 Ja. 03:09:37.430 --> 03:09:38.390 Ja, also. 03:09:39.270 --> 03:09:44.470 Okay, also ihr seid alle der Meinung, testen bringt was, sollte man machen. 03:09:45.510 --> 03:09:45.830 Ja. 03:09:46.070 --> 03:09:52.390 Also ich habe schon Diskussionen mit Leuten gehabt, die irgendwie versucht haben, 03:09:52.630 --> 03:09:58.950 gegen automatisiertes Testen zu argumentieren und dann sagen, ja, aber das schafft ja falsche Sicherheit. 03:09:59.110 --> 03:10:04.790 Und dann denken die Leute, dass ihr Code super funktioniert, weil ihre Tests ja laufen, 03:10:04.870 --> 03:10:07.350 aber der tut das ja gar nicht in Wirklichkeit. 03:10:08.470 --> 03:10:10.070 Ja, aber dann sind ja die Tests halt falsch. 03:10:10.550 --> 03:10:12.710 Ja, das war dann auch mein Argument. 03:10:12.790 --> 03:10:17.110 Also es gibt immer wieder Leute, die dann versuchen, dagegen zu argumentieren und versuchen irgendwie mit 03:10:17.110 --> 03:10:22.390 logisch klingenden Argumenten ihre Faulheit keine Tests schreiben zu wollen, 03:10:22.470 --> 03:10:23.430 zu unterstützen. 03:10:23.670 --> 03:10:27.590 Aber ich denke, in vielerlei Hinsicht ist es das halt. 03:10:27.670 --> 03:10:33.670 Ich meine, wenn du halt, wenn du keine Tests schreibst und nicht irgendwie nicht mal auf irgendeinem Level 03:10:33.670 --> 03:10:40.550 versuchst, was zu automatisieren, dann kostet dich das auf längere Zeit oder 03:10:40.550 --> 03:10:45.990 halt im Laufe von einem Projekt vielleicht meistens schon, kostet dich das halt viel mehr Zeit, 03:10:46.150 --> 03:10:49.510 als die du brauchst, um dich manuell mal durch eine Applikation zu klicken, 03:10:49.590 --> 03:10:54.390 um zu gucken, ob noch alles tut, wie wenn du dann deine Tests schreibst. 03:10:54.630 --> 03:10:55.990 Automatisieren ist eh cool. 03:10:56.150 --> 03:10:57.350 Automatisieren ist immer cool. 03:10:57.910 --> 03:10:59.190 Am besten alles wegautomatisieren. 03:10:59.830 --> 03:11:05.670 Das Ding ist halt, Übung festigt, also Übung macht ja nicht unbedingt den Meister, 03:11:05.750 --> 03:11:08.630 wie man es so sagt, sondern Übung festigt nur Dinge, die du übst. 03:11:10.470 --> 03:11:17.110 Und wenn man halt sagt, okay, ich bin jetzt irgendwie, ich habe jetzt jahrelang nicht 03:11:17.350 --> 03:11:22.310 testgetrieben entwickelt und habe keine Tests geschrieben und musste alles manuell prüfen, 03:11:22.390 --> 03:11:27.750 dann ist das halt etwas, was eigentlich halt schon ein gefestigtes Verhalten ist und das muss man halt 03:11:27.750 --> 03:11:33.670 irgendwie erstmal wegkriegen, bevor man dann so mental sich drauf einlassen kann. 03:11:33.750 --> 03:11:35.190 Und das ist halt bei vielem so. 03:11:35.350 --> 03:11:38.630 Also das ist halt eine andere Art zu arbeiten, das ist eine andere Art, 03:11:38.870 --> 03:11:42.310 irgendwie über Dinge nachzudenken und Sachen anzugehen. 03:11:42.630 --> 03:11:46.950 Und da wird man, wenn man das bis jetzt nicht gemacht hat, 03:11:48.550 --> 03:11:55.030 Widerstand und inneren Widerstand spüren und Produktivitätseinbußen 03:11:56.950 --> 03:11:57.270 haben. 03:11:58.630 --> 03:12:00.470 Das muss man sich natürlich auch bewusst sein. 03:12:00.550 --> 03:12:05.910 Das ist nichts, womit man anfängt und dann ist man ab Tag 0 total super hyperproduktiv und schreibt die besten 03:12:05.910 --> 03:12:06.150 Tests. 03:12:06.230 --> 03:12:08.550 Das ist halt auch irgendwie eine Sache, dass ich dauert erstmal Zeit. 03:12:08.950 --> 03:12:10.630 Das dauert eine Weile, das muss man lernen. 03:12:11.190 --> 03:12:16.230 Auch wenn ich das schon zum Teil eine ganze Weile mache, 03:12:16.470 --> 03:12:22.950 gerade was Testing angeht, da lerne ich jedes Mal, wenn ich irgendwie ein neues Projekt anfange oder irgendwie 03:12:22.950 --> 03:12:26.710 neue Sachen ausprobiere oder Bücher dazu lese oder sonst irgendwas, 03:12:26.790 --> 03:12:31.190 da lerne ich jedes Mal so viel, dass ich mir denke, oh Gott, irgendwie vor ein paar Wochen war ich noch total 03:12:31.190 --> 03:12:33.750 der Kacknoop und jetzt weiß ich schon mehr. 03:12:34.070 --> 03:12:38.790 Und also das ist halt schon ein Zeichen dafür, 03:12:38.870 --> 03:12:44.470 dass es da noch sehr, sehr viel mehr zu lernen gibt, als ich jetzt gerade auch irgendwie sagen könnte. 03:12:44.950 --> 03:12:47.750 Aber im Großen und Ganzen macht es, glaube ich, schon Sinn. 03:12:47.830 --> 03:12:51.350 Es sei denn, es sind jetzt so totale Mini-Projekte. 03:12:52.150 --> 03:12:57.830 Also zum Beispiel, ein Kumpel von mir hat mal vor ein paar Jahren, 03:12:57.990 --> 03:13:03.510 vor anderthalb Jahren oder vor ein paar Monaten vielleicht, eine kleine Ruby, 03:13:03.670 --> 03:13:09.430 ein kleines Ruby-Skript geschrieben, was aus den Gelbe Sack-Terminen für Stuttgart 03:13:10.710 --> 03:13:14.310 eine iCal-Datei generiert. 03:13:16.390 --> 03:13:23.350 Für sowas braucht man letzten Endes sowas führt man einmal aus und dann hat man die Termine 03:13:23.350 --> 03:13:24.470 fürs komplette Jahr. 03:13:24.710 --> 03:13:28.790 Wenn das beim Einmal ausführen funktioniert hat und die Termine dann auch noch stimmen, 03:13:30.710 --> 03:13:33.590 dann ist das gut genug und dann braucht man dafür keine Tests. 03:13:33.670 --> 03:13:37.990 Ich habe das Ding dann geforgt und habe noch ein Kommandozeilen-Interface außenrum gebaut und das ein bisschen 03:13:37.990 --> 03:13:38.790 aufgehübscht. 03:13:38.950 --> 03:13:40.790 Dafür brauche ich aber auch noch keine Tests. 03:13:40.870 --> 03:13:42.070 Da ist die Komplexität noch nicht. 03:13:42.230 --> 03:13:43.830 Also das Ding, das kann ich einmal ausführen. 03:13:43.910 --> 03:13:48.390 Ich importiere das in meinen Kalender, ich gucke, ob der die Datei in die richtige Stelle schreibt. 03:13:48.710 --> 03:13:53.670 Das kann ich auch selbst machen und wenn ich die Software selber nur einmal im Jahr ausführen muss, 03:13:54.230 --> 03:13:55.910 dann ist es mir da nicht wichtig genug. 03:13:56.070 --> 03:14:01.670 Bei jetzt anderen Sachen, gerade Content Management-System oder mein Thesisprojekt oder 03:14:02.790 --> 03:14:07.190 Software X, die eben eine oder die das Potenzial hat, komplex zu werden oder so. 03:14:07.350 --> 03:14:08.310 Genau wie komplex ist. 03:14:08.390 --> 03:14:12.070 Oder auch bei Software, wo man noch gar nicht weiß, wo die Reise hingeht und wo man dann sagt, 03:14:12.150 --> 03:14:18.950 okay, ich werde im Laufe des Lebenszykluses von der Applikation sehr viel über den 03:14:18.950 --> 03:14:24.230 Haufen werfen müssen, dann sind Tests vielleicht auch ganz gut, dass man so mal ein bisschen die Teile, 03:14:24.390 --> 03:14:29.590 die funktionieren sollen, auch mal definiert und seien es nur irgendwelche Integration oder Acceptance-Tests, 03:14:29.670 --> 03:14:33.030 damit man überhaupt irgendwas hat, woran man sich festhalten kann. 03:14:33.910 --> 03:14:39.430 Okay, dann würde ich sagen, es muss jeder natürlich selber entscheiden, ob er das machen will. 03:14:39.510 --> 03:14:45.270 Ich hoffe, ihr habt hier ein paar Anregungen, ein paar nette Frameworks, 03:14:45.590 --> 03:14:51.430 ein paar Vorschläge mitgenommen und ob ihr das dann bei eurem Projekt anwendet oder nicht, 03:14:51.590 --> 03:14:57.430 oder was weiß ich, im nächsten Team-Meeting mal vorschlagt, weil bisher ohne Testen entwickelt wurde. 03:14:58.230 --> 03:15:02.470 Oder doch mal alles auf Travis CI zu schicken und zu gucken, was da so alles passiert. 03:15:02.790 --> 03:15:05.030 Dann hoffen wir, euch hat das Spaß gemacht. 03:15:05.110 --> 03:15:09.190 Fladi, du wolltest noch ein paar Vorträge und Bücher nennen, die man sich. 03:15:13.590 --> 03:15:14.790 Account gefunden habe. 03:15:15.190 --> 03:15:22.150 Also zu meinen Therapeutic Refactoring, da geht es im Großen um Legacy-Code, 03:15:22.390 --> 03:15:28.630 also alter Code, der komplex ist, der nicht getestet ist, wie man da so ein bisschen rangehen kann, 03:15:28.870 --> 03:15:35.670 um da halbwegs sinnvoll Refactoring zu betreiben. 03:15:35.830 --> 03:15:38.710 Also das ist so ein ganz netter Vortrag, der geht irgendwie, ich glaube, 03:15:38.870 --> 03:15:43.910 eine halbe, eine Dreiviertelstunde und der erklärt die nette Frau, 03:15:43.990 --> 03:15:50.870 deren Name ich gerade vergessen habe, wie das funktioniert an einem Beispiel und Boundaries ist 03:15:50.870 --> 03:15:54.630 im Endeffekt auch so eine von Gary Beinhardt. 03:15:54.870 --> 03:15:57.110 Bernhard, Bernhard heißt er, glaube ich. 03:15:59.270 --> 03:16:05.830 Da geht es im Endeffekt um ein Testing-Schema, was der Functional Core 03:16:05.910 --> 03:16:12.470 Imperative Shell nennt, wo es dann so darum geht, ich habe jetzt komplett funktionale Elemente 03:16:13.990 --> 03:16:16.870 in meiner Basisapplikation im Kern. 03:16:17.110 --> 03:16:22.230 Die sind komplett, also die kann ich komplett, die sind komplett Data in, 03:16:22.310 --> 03:16:27.830 Data Out, da passiert nichts, da wird kein State gehalten und nichts und außenrum baue ich dann den ganzen 03:16:27.830 --> 03:16:32.230 Rest, ist auch ein ganz netter Vortrag, wo man mal ein bisschen drüber nachdenken kann, 03:16:32.310 --> 03:16:35.270 ob das irgendwie, ob man da Bock drauf hat. 03:16:35.510 --> 03:16:36.390 Dann noch drei Bücher. 03:16:36.550 --> 03:16:40.230 Ja, genau, also der Klassiker Test-Driven Development von, ich glaube, 03:16:40.390 --> 03:16:42.550 Canned Back, wenn mich nicht alles täuscht. 03:16:45.190 --> 03:16:45.750 Wo steht denn? 03:16:45.910 --> 03:16:46.870 Genau, Canned Back. 03:16:47.510 --> 03:16:53.030 Ja, gut, Extreme Programming, das ist so ein Klassiker, den kann man sich auch mal angucken. 03:16:53.590 --> 03:16:59.270 Da ist Test-Driven Development auch eine der Sachen, die da gemacht werden. 03:16:59.590 --> 03:17:04.310 Und ein Buch, was ich gerade lese, was ich auch schon vor kurzem in der Talksendung gepickt habe, 03:17:04.390 --> 03:17:07.430 ist Practical Object-Orient Design in Ruby. 03:17:07.750 --> 03:17:10.230 Da gibt es auch ein sehr langes Kapitel zu Tests. 03:17:10.310 --> 03:17:17.030 Also das ist im Endeffekt komplett, so würde ich sagen, der definitive Guide 03:17:17.670 --> 03:17:24.550 für objektorientierte Programmierung generell jetzt in einer konkreten 03:17:24.550 --> 03:17:27.990 Form jetzt in Ruby, aber die Sachen, die man dort lernt, die kann man auch, 03:17:28.870 --> 03:17:33.190 finde ich, in jeder objektorientierten Programmiersprache ebenfalls anwenden. 03:17:34.310 --> 03:17:38.630 Okay, so, dann würde ich sagen, wir machen hier mal Klappe zu, Affe tot. 03:17:39.430 --> 03:17:43.430 Ganz tot ist er auch noch nicht, weil wir wollen auch noch eine zweite Sendung dazu machen. 03:17:43.510 --> 03:17:44.390 Wir haben ja immer. 03:17:44.710 --> 03:17:49.670 Das Ziel von Benäggewitter Spezial ist ja immer noch eine zweite Sendung zu machen, 03:17:49.750 --> 03:17:54.310 die man dann ewig lange nicht macht, aber wir nehmen uns strikt vor, 03:17:54.470 --> 03:17:56.390 noch eine zweite Sendung über Testing zu machen. 03:17:56.470 --> 03:18:00.710 Dann im Speziellen über Mobile-Testing, 03:18:00.790 --> 03:18:04.710 also iOS, Android und dann nochmal ein bisschen ein bisschen Webbrowser, 03:18:04.790 --> 03:18:06.390 was wir jetzt auch nicht mehr geschafft haben. 03:18:06.950 --> 03:18:09.430 Seid gespannt, wenn wir das dann irgendwann mal hinkriegen. 03:18:09.510 --> 03:18:14.550 Vielleicht schneller als gedacht, vielleicht dauert es aber auch noch bis Mitte nächsten Jahr, was wir gucken. 03:18:14.870 --> 03:18:18.070 Wir warten einfach und schauen, ob das Thema sich einfach von selber erledigt. 03:18:18.230 --> 03:18:18.630 Oder so. 03:18:18.870 --> 03:18:20.070 Ob man nie mehr testen muss. 03:18:20.390 --> 03:18:25.030 Und dann stellen wir leider irgendwann traurig fest, oh, damn, muss man doch noch. 03:18:25.990 --> 03:18:27.510 Die Leute wollen das Zug benutzen, was wir machen. 03:18:27.990 --> 03:18:29.270 Und dann müssen wir es vielleicht nochmal machen. 03:18:29.350 --> 03:18:32.790 Ihr könnt auf jeden Fall in die Kommentare schreiben, ob euch das gefallen hat, 03:18:32.950 --> 03:18:35.270 ob wir noch eine zweite Sendung auf jeden Fall machen sollen. 03:18:35.430 --> 03:18:40.870 Und wenn ihr anderer Meinung seid und ihr sagt, testen, die haben es doch nicht mehr alle, 03:18:41.030 --> 03:18:46.070 macht doch keiner mehr, ist doch alles Bullshit, könnt ihr uns das natürlich auch in netter Form in die 03:18:46.070 --> 03:18:46.950 Kommentare pasten. 03:18:47.190 --> 03:18:48.390 Ihr könnt es auch so schon pasten. 03:18:48.950 --> 03:18:50.230 Ja, natürlich, immer. 03:18:50.550 --> 03:18:50.710 Immer. 03:18:50.790 --> 03:18:52.790 Und ihr könnt das auch flattern und sowieso und überhaupt. 03:18:53.030 --> 03:18:55.510 Gut, dann war es das für diese Sendung. 03:18:55.590 --> 03:19:00.790 Ich wünsche euch wie immer eine frohe Zeit, passt auf euch auf, habt Spaß am Gerät und bis zum nächsten Mal. 03:19:01.190 --> 03:19:01.670 Tschüss.