WEBVTT

00:00:00.740 --> 00:00:04.200
Ja, hallo und herzlich willkommen zum Python-Podcast in der 24. Episode.

00:00:05.400 --> 00:00:08.480
Heute geht es bei uns zum Test und wir haben wieder einen Gast, der Ronny ist da.

00:00:08.980 --> 00:00:09.180
Hi.

00:00:09.300 --> 00:00:09.780
Hi Ronny, hallo.

00:00:10.460 --> 00:00:11.300
Und der Jochen natürlich auch.

00:00:11.460 --> 00:00:12.860
Ja, ja, ich bin dann auch da.

00:00:14.120 --> 00:00:15.240
Ja, schön, dass ihr alle wieder eingeschaltet habt.

00:00:16.020 --> 00:00:19.700
Und Ronny, erzähl doch mal was von dir. Möchte ich einmal kurz vorstellen.

00:00:20.380 --> 00:00:23.520
Ja, ich heiße Ronny Vidrilia, ich arbeite in Köln bei Amint Innovation.

00:00:24.700 --> 00:00:28.980
Bin da jetzt seit einem Jahr ganz offiziell Tech-Evangelist für Django.

00:00:29.820 --> 00:00:47.860
Habe jetzt meine acht Jahre, die ich da bin, auch Großteils mit Backend-Arbeiten und Django verbracht, habe in Köln Wirtschaftsinformatik studiert, also eigentlich eher so ein Beraterstudiengang, aber ich hatte immer mehr Spaß eigentlich am entwickelnden Beraten, beziehungsweise Beratung mit Entwicklung zusammen.

00:00:47.900 --> 00:00:48.580
Kann ich ja gar nicht verstehen.

00:00:51.120 --> 00:00:59.080
Und genau, wir haben uns eigentlich kennengelernt, du warst Pei Cologne oder Düsseldorfer?

00:00:59.080 --> 00:01:02.800
Ja, und du hast dann dieses Meetup ausgerichtet, das Django-Meetup in Köln.

00:01:03.300 --> 00:01:04.360
Hatten wir das nicht vorher schon?

00:01:04.960 --> 00:01:07.920
Ja, wir haben uns auf irgendeinem der Peikolons mal gefragt.

00:01:07.980 --> 00:01:10.160
Peikolons bestimmt, da haben wir uns bestimmt schon mal gesehen.

00:01:10.560 --> 00:01:22.140
Genau, und wie Dominik gerade schon gesagt hat, seit jetzt glaube ich einem knappen Jahr richten wir bei uns im Büro bei Ambient das Django-Meetup Köln aus.

00:01:24.380 --> 00:01:28.620
Und genau, da sind die beiden auch immer regelmäßige Gäste.

00:01:29.320 --> 00:01:30.840
Falls ihr uns live kennenlernen wollt.

00:01:31.100 --> 00:01:33.780
Bis Corona all das verunmöglicht hat, sozusagen.

00:01:34.240 --> 00:01:36.760
Also na gut, es gibt halt das virtuelle Meetup.

00:01:37.160 --> 00:01:38.160
Und ja, genau.

00:01:38.380 --> 00:01:39.200
Das ist nicht mehr ganz das Gleiche.

00:01:39.280 --> 00:01:40.380
Ich fand es auch immer schön, die Leute live zu sehen.

00:01:40.740 --> 00:01:41.860
Apropos live sehen.

00:01:42.000 --> 00:01:45.340
Wir haben heute tatsächlich eine Testfolge, die einen Test macht.

00:01:45.720 --> 00:01:47.640
Und zwar sind wir zum ersten Mal nicht im Wintergarten,

00:01:48.100 --> 00:01:51.720
sondern diesmal draußen und sitzen in einem Restaurantgarten.

00:01:51.720 --> 00:01:54.140
Wir waren auch schon mal woanders, aber wir waren noch nie draußen.

00:01:54.380 --> 00:01:56.420
Ja, genau. Und das ist jetzt quasi das erste Mal live

00:01:56.420 --> 00:01:58.440
vor Ort draußen. Also entschuldige mir so ein bisschen

00:01:58.440 --> 00:02:00.540
die Hintergrundgeräusche. Das ist ein bisschen urbanes Leben.

00:02:01.920 --> 00:02:02.240
Genau.

00:02:02.680 --> 00:02:03.780
Ja, schreibt da gerne mal Feedback zu.

00:02:04.340 --> 00:02:06.440
Klingt das ganz schrecklich furchtbar? Oder kann man

00:02:06.440 --> 00:02:08.240
damit halbwegs leben? Ich meine, das ist natürlich angenehm.

00:02:08.360 --> 00:02:10.480
Also gerade wenn es warm ist, irgendwie eher draußen zu sitzen

00:02:10.480 --> 00:02:12.480
und irgendwie ein bisschen was Kühleres

00:02:12.480 --> 00:02:14.460
zu trinken, ist natürlich schon sehr viel angenehmer als

00:02:14.460 --> 00:02:15.740
jetzt. Dankeschön.

00:02:16.200 --> 00:02:16.460
Prost.

00:02:18.220 --> 00:02:20.620
Naja, hört sich ein bisschen zu fern an. Die Werte sind zu voll.

00:02:22.400 --> 00:02:37.740
Ja, aber eben wenn man in so einem kleinen Raum sitzt, also das ist ja immer das Problem mit der Akustik, man braucht entweder einen kleinen Raum, in dem viel Zeug ist, damit es halt nicht so hallt, weil Hall ist immer so der Feind von guter Akustik, oder halt Weite. Hier haben wir jetzt Weite und wir haben leider sogar ein bisschen Wind, vielleicht hört man den auch.

00:02:38.480 --> 00:02:57.040
Ja, auf jeden Fall, genau. Also wenn großer Raum, also so draußen ist eigentlich auch nicht schlecht für die Akustik, aber Wind ist natürlich schon mal wieder nicht so toll. Aber ja, ich bin mal gespannt, wie das funktioniert und wir haben ja auch ein Realist-Equipment, das wir nehmen auf, ohne irgendwie Laptop oder Computer, einfach so mit so einem portablen Aufnahmegerät und den üblichen Headsets und da mal schauen, wie das so geht.

00:02:57.040 --> 00:03:01.260
Ja, aber du kannst gerne noch mal ein bisschen über die Gerätschaften erzählen, du machst das schon letztes Mal irgendwie.

00:03:02.200 --> 00:03:23.180
Naja, das ist jetzt einfach so ein Zoom H6, das ist halt so ein Field Recorder, das wird jetzt beworben. Das hat halt auch so XLR-Eingänge für Mikrofone, macht Phantomspeisung und dann ist da noch so ein Kopfhörerverstärker dran, wo dann halt die Ausgänge, die alle das gleiche Line-Out-Signal von dem H6 kriegen, nochmal dran hängen, damit man sich auch selber und die anderen hören kann.

00:03:23.780 --> 00:03:44.420
Und genau, also was wirklich eine tolle Kombination ist, ist halt sozusagen die Standard-Podcaster-Konfiguration zur Zeit, glaube ich, die die meisten Audioqualität bietet für Geld, ist halt so ein Zoom H6 plus irgendwie diese HMC 660X oder C, keine Ahnung, Headsets, weil man kann an dem Zoom H6 nämlich auch 12 Volt Phantomspeisung einstellen.

00:03:44.420 --> 00:03:47.080
und muss nicht

00:03:47.080 --> 00:03:48.840
löten und braucht keinen Adapter

00:03:48.840 --> 00:03:50.880
oder so und die Dinger funktionieren einfach

00:03:50.880 --> 00:03:52.840
an dem Ding direkt, was halt bei den meisten

00:03:52.840 --> 00:03:54.240
professionellen Audio-Interfaces nicht geht.

00:03:55.520 --> 00:03:57.000
Ja, mal schauen, wie das so wird.

00:03:57.260 --> 00:03:58.980
Ja, ich bin gespannt auf die Folge und wie sich das hinterher anhört.

00:03:59.120 --> 00:04:00.680
Also gerade mit dieser Hintergrund-Akustik. Also man hört ja

00:04:00.680 --> 00:04:02.400
manchmal den Wind rauschen, das Lachen der Gäste,

00:04:03.300 --> 00:04:04.000
die leise Musik.

00:04:05.460 --> 00:04:06.520
Ronny, Tests heute?

00:04:06.760 --> 00:04:06.880
Ja.

00:04:08.700 --> 00:04:10.640
Oder wollen wir zuerst irgendwie, gibt es irgendwelche News?

00:04:10.720 --> 00:04:11.320
News aus der Szene.

00:04:12.900 --> 00:04:14.520
Ja, also Dango 3.1 kam ja raus, ich weiß nicht,

00:04:15.040 --> 00:04:16.940
jetzt ist es tatsächlich final. Und Wagtail

00:04:16.940 --> 00:04:18.180
wurde auch schon auf Dango 3.1 gearbeitet,

00:04:18.600 --> 00:04:20.620
das habe ich auch noch mitbekommen. Ja, es gibt eine neue

00:04:20.620 --> 00:04:22.540
Wagtail-Version, wobei die, glaube ich,

00:04:22.560 --> 00:04:24.780
war nicht so weltbewegendes dabei. Ja doch, es geht jetzt

00:04:24.780 --> 00:04:26.680
mit Dango 3.1. Ach so, ja.

00:04:26.920 --> 00:04:28.820
Okay, gut. Denn ich habe direkt tatsächlich

00:04:28.820 --> 00:04:30.600
umgestellt. Du hast einen tollen Artikel

00:04:30.600 --> 00:04:31.580
geschrieben übrigens auch.

00:04:32.480 --> 00:04:34.640
Ja, das war, ich meine, das ist halt irgendwie so

00:04:34.640 --> 00:04:35.620
mehrere

00:04:35.620 --> 00:04:38.680
Probleme auf mit einer Klappe

00:04:38.680 --> 00:04:40.640
fliegen, erledigen

00:04:40.640 --> 00:04:42.520
halt sozusagen. Ja, wir schreiben auch noch gerade

00:04:42.520 --> 00:04:45.080
schreiben wir an so einen Artikel, deswegen habe ich

00:04:45.080 --> 00:04:46.120
den zuerst irgendwie

00:04:46.120 --> 00:04:47.740
zur Release von

00:04:47.740 --> 00:04:50.800
Django 3.1 halt sozusagen veröffentlicht

00:04:50.800 --> 00:04:52.460
und davor haben wir halt diese Asung-Folge

00:04:52.460 --> 00:04:54.380
gemacht, die halt... Kannst du Django News, Ronny?

00:04:55.260 --> 00:04:56.420
Ja. Ja, weil der erste

00:04:56.420 --> 00:04:58.260
Artikel war von ihm. Ich habe es auch gesehen, ich war

00:04:58.260 --> 00:05:00.680
ja, ich hatte ja schon

00:05:00.680 --> 00:05:02.440
intern vorher

00:05:02.440 --> 00:05:04.160
mitbekommen, dass du einen Artikel geschrieben hast.

00:05:04.740 --> 00:05:05.280
Nicht schlecht.

00:05:06.380 --> 00:05:08.120
Ja, was mich, also tatsächlich hat es

00:05:08.120 --> 00:05:10.360
Jochen

00:05:10.360 --> 00:05:12.280
wird gerade von einer Wespe bearbeitet und die kriegt

00:05:12.280 --> 00:05:13.220
gerade über sein Brillenglas.

00:05:14.300 --> 00:05:15.620
Jochen mag Insekten sehr gerne,

00:05:16.120 --> 00:05:17.320
wie ich schon mitbekommen durfte.

00:05:18.060 --> 00:05:19.580
Aber er bleibt relativ entspannt.

00:05:19.900 --> 00:05:21.980
Also ehrlich gesagt, die Insekten mögen mich mehr als sie.

00:05:22.720 --> 00:05:23.360
Finde ich.

00:05:24.160 --> 00:05:25.640
Das ist etwas beunruhigend. Na gut.

00:05:26.140 --> 00:05:26.800
Gab es doch diesen Song.

00:05:27.700 --> 00:05:29.940
I don't like the insects, but the insects like me.

00:05:30.200 --> 00:05:30.840
Ja, genau.

00:05:31.960 --> 00:05:34.040
Aber genau, was ich

00:05:34.040 --> 00:05:36.040
daran eigentlich ganz gut fand,

00:05:36.100 --> 00:05:37.840
ich weiß jetzt nicht, der Artikel, naja, ich habe irgendwann auch einfach

00:05:37.840 --> 00:05:39.880
mir gedacht, ich habe keinen Bock mehr weiterzumachen,

00:05:39.940 --> 00:05:41.940
jetzt reicht es. Aber er hat relativ

00:05:41.940 --> 00:05:43.940
viel Aufmerksamkeit, also mehr Aufmerksamkeit gekriegt,

00:05:44.000 --> 00:05:45.980
als ich gedacht hätte. Und ich

00:05:45.980 --> 00:05:47.900
glaube, das lag halt daran, dass einfach auch viel Arbeit

00:05:47.900 --> 00:05:49.260
drin steckt, fürchte ich. Ja, ich wollte gerade sagen,

00:05:49.340 --> 00:05:51.900
also ich habe ja irgendwie mal so angefangen damit

00:05:51.900 --> 00:05:53.940
erstmal, ne. Jochen hat mir so um die Ohren gehauen,

00:05:54.020 --> 00:05:55.620
das ist unglaublich. Dann meinte er so, nee, das geht gar nicht.

00:05:55.660 --> 00:05:57.420
Und hat dann irgendwie 15 oder 16 Seiten

00:05:57.420 --> 00:06:00.020
drangehängt, wie man es richtig macht. Ja, okay, danke, Jochen.

00:06:00.640 --> 00:06:01.940
Ja, aber ich wollte das

00:06:01.940 --> 00:06:03.920
eigentlich alles gar nicht. Aber na gut, also manchmal braucht man

00:06:03.920 --> 00:06:05.920
halt auch jemanden, da braucht man irgendwie so einen Anstoß, um das

00:06:05.920 --> 00:06:07.960
dann zu machen und den Handwänden damit. Und ja,

00:06:08.000 --> 00:06:09.360
gut, jetzt ist es draußen und gut.

00:06:10.600 --> 00:06:11.900
Also insofern, ja, also

00:06:11.900 --> 00:06:13.740
viel Arbeit in irgendwas stecken hilft.

00:06:14.120 --> 00:06:15.980
Ja, wenn das irgendjemand weiterhilft, keine Ahnung.

00:06:18.600 --> 00:06:20.040
Ja, genau.

00:06:20.420 --> 00:06:21.420
Ach, es gab noch eine neue

00:06:21.420 --> 00:06:23.860
Release-Kandidat

00:06:23.860 --> 00:06:25.380
für Python 3.9.

00:06:25.740 --> 00:06:27.060
Den ersten gibt es jetzt.

00:06:27.880 --> 00:06:29.020
Also, und Leute, die das

00:06:29.020 --> 00:06:30.620
verwenden, haben schon gesagt,

00:06:30.700 --> 00:06:32.300
es funktioniert eigentlich alles ganz fluffig.

00:06:32.920 --> 00:06:34.080
Was sind denn die Neuerungen von 3.9?

00:06:34.520 --> 00:06:38.920
Wir haben das bestimmt schon mal besprochen.

00:06:39.440 --> 00:06:39.520
Wir haben das bestimmt schon mal besprochen.

00:06:39.520 --> 00:06:40.460
Wir haben jetzt ja kein Recht an den hier.

00:06:40.740 --> 00:06:41.940
Wir können das nicht einfach nebenbei...

00:06:41.940 --> 00:06:43.540
Wir können das nicht einfach, weil so

00:06:43.540 --> 00:06:46.520
online recherchieren geht

00:06:46.520 --> 00:06:48.600
halt gerade eben nicht. Aber ansonsten

00:06:48.600 --> 00:06:51.100
hat, weiß nicht, sonst irgendwelche Neuigkeiten...

00:06:51.100 --> 00:06:51.340
Nee, ne?

00:06:52.160 --> 00:06:54.360
Ist dir was eingefallen? Nein, außer

00:06:54.360 --> 00:06:55.140
Django 3.1,

00:06:55.360 --> 00:06:58.080
was ich jetzt auch schon nutze, funktioniert gut.

00:06:58.520 --> 00:07:00.320
Jason Fields sind super. Doch, mir fällt noch was ein, und zwar

00:07:00.320 --> 00:07:02.080
ist von Daniel Roy Fieldroy das

00:07:02.080 --> 00:07:04.140
Buch Two Scopes of Django

00:07:04.140 --> 00:07:06.160
in der Version 3, hat der gestern Abend

00:07:06.160 --> 00:07:08.260
seinen Twitch-Kanal hochgefahren,

00:07:08.340 --> 00:07:09.680
weil es jetzt offiziell Redaktion ist.

00:07:10.180 --> 00:07:12.060
Ah, okay, ich hatte es schon gekauft, aber

00:07:12.060 --> 00:07:14.020
immer die Updates nur gesehen, nur die dann nie,

00:07:14.280 --> 00:07:15.620
weil ich dachte, ach, ich warte auf die fertige Release.

00:07:15.840 --> 00:07:18.160
Wenn ich jetzt weiß, das Release ist super, dann hole ich mir mal

00:07:18.160 --> 00:07:20.160
den. Ganz genau, das war gestern

00:07:20.160 --> 00:07:21.780
Abend. Ah, sehr schön.

00:07:23.280 --> 00:07:23.980
Ja, nö,

00:07:24.060 --> 00:07:25.980
ansonsten, genau, können wir dann

00:07:25.980 --> 00:07:27.560
vielleicht direkt mit dem echten Thema

00:07:27.560 --> 00:07:29.640
einsteigen. Ja, wollen wir vielleicht noch kurz

00:07:29.640 --> 00:07:31.700
einen Überblick geben? Also ich glaube, wir reden einfach los, wie immer,

00:07:31.840 --> 00:07:34.000
über Tests und so ein bisschen mehr Tests und Tests

00:07:34.000 --> 00:07:35.980
und Tests und Tests und wir testen jetzt, ob der Test funktioniert

00:07:35.980 --> 00:07:37.780
mit den Tests. Mögt ihr Tests?

00:07:39.440 --> 00:07:39.720
Jochen?

00:07:40.180 --> 00:07:47.400
Ja, also ich habe lange Zeit, ich habe früher die Leute, die so anfingen mit TDD oder so.

00:07:47.460 --> 00:07:48.860
Ich finde Tests total furchtbar.

00:07:51.580 --> 00:07:56.980
Das hat dann irgendwie, als ich noch keine Tests geschrieben habe oder noch nicht so viele, da habe ich so ein bisschen über diese Leute immer gelächelt.

00:07:57.080 --> 00:08:03.980
Ich so, ah ja, die mit ihrem komischen statischen Dings da, Java und so und Testschreiben, höhö, das mache ich alles einfach mal so eben aus der Hand.

00:08:04.000 --> 00:08:05.560
Mein Code ist so perfekt, den braucht man gar nicht.

00:08:06.240 --> 00:08:07.900
Einfach keine Fehler machen, so einfach ist das.

00:08:08.040 --> 00:08:10.020
Genau, das ist alles kein Problem.

00:08:10.180 --> 00:08:23.620
Und dann irgendwann dachte ich so, okay, ich bin vielleicht einfach nicht so der Typ für längere Programme. Ich schreibe gerne so kurze Sachen, die so auf eine Bildschirmseite gehen oder vielleicht ein bisschen länger sind, aber habe das nie so reflektiert, woran das eigentlich liegt.

00:08:23.620 --> 00:08:51.480
Und dann, als ich irgendwann angefangen habe, Tests zu schreiben, weil das halt in irgendeinem Projekt dann erforderlich wurde, merkte ich so, oh, ach, ich kann ja vielleicht doch leckere Programme schreiben. Mit Tests geht das plötzlich. Und das ist halt, man kann halt sich quasi ausruhen. Entweder man hält halt den kompletten State im Kopf und weiß dann halt, dass man wahrscheinlich keine Fehler gemacht haben wird, weil man das halt weiß, wie jeder einzelne Teil funktioniert und miteinander interagiert. Oder wenn man das halt nicht mehr wissen kann, weil es einfach zu viel wird, dann braucht man halt Tests. Ansonsten passieren schreckliche Dinge. Das ist halt einfach so.

00:08:51.480 --> 00:08:54.880
Oder halt auch für Refactoring. Das ist halt auch immer ein Riesenargument für Tests.

00:08:55.580 --> 00:08:56.660
Okay. Magst du Tests, Johnny?

00:08:57.800 --> 00:09:08.880
Ja. Ich muss gestehen, wenn ich unter Zeitdruck viel entwickeln muss, dann ärgere ich mich manchmal nachher, dass da noch so viele Tests übrig bleiben, die man schreiben muss.

00:09:10.260 --> 00:09:14.160
Aber generell finde ich es eine super Sache. Und wie gesagt, allein schon wegen Refactoring.

00:09:14.160 --> 00:09:15.980
ich arbeite an mehreren

00:09:15.980 --> 00:09:18.100
Django-Projekten, die jetzt schon Jahre laufen

00:09:18.100 --> 00:09:20.200
und ich weiß, wie mühsam

00:09:20.200 --> 00:09:22.120
das früher war, als wir noch keine

00:09:22.120 --> 00:09:24.120
Tests da drin hatten und wie

00:09:24.120 --> 00:09:26.420
unmöglich es war, irgendwelche Sachen anzufassen,

00:09:26.940 --> 00:09:28.280
ohne

00:09:28.280 --> 00:09:30.120
dass man nachher Stunden

00:09:30.120 --> 00:09:32.120
am besten tagelang irgendwie...

00:09:32.880 --> 00:09:33.820
Genau, vor allem dann so

00:09:33.820 --> 00:09:36.120
zerbrechliche Sachen, wie man hat dann

00:09:36.120 --> 00:09:38.120
zum Beispiel irgendwie eine Überstundenerfassung

00:09:38.120 --> 00:09:40.020
oder sowas gebaut und da dann irgendwie alle

00:09:40.020 --> 00:09:42.320
Sonderfälle irgendwie zu bedenken und durchzutesten

00:09:42.320 --> 00:09:43.400
manuell zu Fuß,

00:09:44.140 --> 00:09:45.860
vor allem, wenn du noch so Späße hast wie mit Daten

00:09:45.860 --> 00:09:47.400
und da musst du immer noch quasi in,

00:09:47.820 --> 00:09:50.020
also ohne, dass man irgendwie jetzt in einem Testumgebung

00:09:50.020 --> 00:09:51.780
ist, wo man das Datum einfach mocken kann,

00:09:52.440 --> 00:09:54.020
so in manuellen Testen

00:09:54.020 --> 00:09:55.980
das Datum dann irgendwie und dann so lustige

00:09:55.980 --> 00:09:57.520
Sachen wie Wochenenden und Feiertage.

00:09:58.940 --> 00:10:00.000
Dafür bin ich schon sehr, sehr

00:10:00.000 --> 00:10:02.140
froh, dass es Unit-Tests gibt und dass die so gut funktionieren.

00:10:03.940 --> 00:10:04.180
Ja.

00:10:05.080 --> 00:10:05.960
Ja, ich muss sagen, also ich mag

00:10:05.960 --> 00:10:07.740
Tests eigentlich gar nicht, aber sind in gewisser Weise,

00:10:07.740 --> 00:10:09.540
fand ich ja notwendig, aber ich habe erst mitbekommen,

00:10:09.620 --> 00:10:11.500
ich bin jetzt noch nicht so lange dabei, dass es eine große

00:10:11.500 --> 00:10:13.340
philosophische Debatte gibt zwischen Menschen, die gerade

00:10:13.340 --> 00:10:15.160
kronheimlich viele Testabdeckungen, also Coverage

00:10:15.160 --> 00:10:16.780
nennt man das ja, haben am liebsten

00:10:16.780 --> 00:10:19.500
150% des Codes sollen getestet

00:10:19.500 --> 00:10:21.260
werden und andere Leute sagen, ja, ist eigentlich

00:10:21.260 --> 00:10:23.140
völlig egal, einfach ein Integrationstest,

00:10:23.260 --> 00:10:25.180
ob überhaupt so die Permissions so sind, wie

00:10:25.180 --> 00:10:27.000
ich mir das vorstelle und dann, wenn halt was

00:10:27.000 --> 00:10:29.080
schmiedschlägt, dann schreibt man danach dafür einen Test,

00:10:29.140 --> 00:10:29.840
dass es nicht nochmal passiert.

00:10:31.180 --> 00:10:32.140
Irgendwie so dazwischen ist so

00:10:32.140 --> 00:10:35.000
die Wahrheit, ich weiß nicht, ob es sowas gibt,

00:10:35.180 --> 00:10:37.060
wie so manches Mal.

00:10:38.300 --> 00:10:39.320
Aber ich glaube auch,

00:10:39.420 --> 00:10:41.200
also ich meine, es gibt ja das

00:10:41.200 --> 00:10:43.280
berühmte Pareto-Prinzip, 80-20-Regel,

00:10:43.340 --> 00:10:57.260
Und ich glaube, wenn man versucht, 100% der Sachen abzudecken, ich glaube, es gibt einfach Dinge, da ist einfach der Overhead so viel größer, dafür irgendwie Tests zu bauen, dass man da, glaube ich, auch einfach riskieren kann, dass gewisse Dinge vielleicht einfach mal in die Hose gehen dürfen.

00:10:57.360 --> 00:10:59.520
es wird auch so starr. Also wenn du halt ganz, ganz,

00:10:59.580 --> 00:11:01.460
ganz viel testest, dann kannst du eigentlich

00:11:01.460 --> 00:11:03.260
ja nichts mehr ändern, ohne dass

00:11:03.260 --> 00:11:05.360
irgendein Test fehlschlägt. Ich meine, du merkst dann zwar, was dann

00:11:05.360 --> 00:11:06.760
fehlgeschlagen ist vielleicht, aber

00:11:06.760 --> 00:11:09.340
das macht einen doch sehr unbeweglich und

00:11:09.340 --> 00:11:11.460
du hast halt tatsächlich auch, wenn du refactoren willst,

00:11:11.540 --> 00:11:12.480
wie du eben sagtest, Ronny, das

00:11:12.480 --> 00:11:15.180
Problem, dass du ganz, ganz viele Sachen

00:11:15.180 --> 00:11:17.340
und die Teste anfassen musst, weil vielleicht auch die

00:11:17.340 --> 00:11:19.020
Tests refactored werden müssen dann.

00:11:19.840 --> 00:11:21.280
Ja, also ich würde auch denken, es kommt halt

00:11:21.280 --> 00:11:23.120
auf den Anwendungsfall an. Also wenn du halt irgendwie eine

00:11:23.120 --> 00:11:24.940
kleine Webseite hast, die irgendwas

00:11:24.940 --> 00:11:27.520
keine Ahnung, für dich und ein paar Freunde

00:11:27.520 --> 00:11:29.640
irgendwie macht, da braucht man vielleicht keine Tests,

00:11:29.720 --> 00:11:31.540
weil wenn irgendwas schief geht, dann fixt man das halt und

00:11:31.540 --> 00:11:33.760
es hat ja keinen gestört, dass es irgendwie schief gegangen ist.

00:11:34.920 --> 00:11:35.840
Steuerprogramm vom AKW

00:11:35.840 --> 00:11:37.160
bräuchte vielleicht ein paar mehr Tests.

00:11:37.160 --> 00:11:38.960
Genau, da würde man sich dann vielleicht freuen,

00:11:39.060 --> 00:11:41.180
wenn die bemerken, dass etwas schief läuft, bevor es

00:11:41.180 --> 00:11:43.080
irgendwie die ganze Region mit in den

00:11:43.080 --> 00:11:44.880
Abgrund reißt, aber genau.

00:11:45.060 --> 00:11:46.540
Und da braucht man halt vielleicht viele und gute Tests.

00:11:46.880 --> 00:11:48.160
Und ja, also

00:11:48.160 --> 00:11:50.520
ich meine, nur ein paar

00:11:50.520 --> 00:11:52.680
Integrationstests zu haben, ist ja auch schon mal

00:11:52.680 --> 00:11:54.820
auf jeden Fall besser, als keine Tests zu haben. Auch die fangen natürlich

00:11:54.820 --> 00:11:56.640
dann schon Sachen. Auf der anderen Seite

00:11:56.640 --> 00:11:58.760
ist es schwierig. Das mit den Metriken ist

00:11:58.760 --> 00:12:00.840
immer so eine Sache. Ich meine, es ist auf jeden Fall

00:12:00.840 --> 00:12:02.920
immer auch besser, irgendwas zu messen, als nichts zu messen

00:12:02.920 --> 00:12:04.980
und dass man irgendwas hat, worauf man optimieren kann.

00:12:05.500 --> 00:12:06.580
Aber gerade, wenn man jetzt so

00:12:06.580 --> 00:12:08.820
schlechte Tests schreibt, dann kriegt man

00:12:08.820 --> 00:12:10.780
mit denen oft eine gute Testabdeckung hin.

00:12:10.940 --> 00:12:12.680
Weil man hat dicke

00:12:12.680 --> 00:12:14.520
Integrationstests, die ganz viel

00:12:14.520 --> 00:12:16.240
Code aufrufen.

00:12:17.580 --> 00:12:18.740
Aber eigentlich sind die halt

00:12:18.740 --> 00:12:20.740
eher nicht so toll, weil die sind

00:12:20.740 --> 00:12:22.040
halt langsam und

00:12:22.040 --> 00:12:24.340
dann die

00:12:24.340 --> 00:12:26.960
sind auch schwer zu ändern, wenn man dann Code ändert

00:12:26.960 --> 00:12:27.880
und

00:12:27.880 --> 00:12:30.760
was heißt das eigentlich 100% Test-Coverage?

00:12:30.920 --> 00:12:32.800
Ich meine, die Brand-Coverage ist ja auch nochmal

00:12:32.800 --> 00:12:34.200
vielleicht so eine Geschichte, das geht jetzt übrigens mit der

00:12:34.200 --> 00:12:36.860
neuesten, mit der Version

00:12:36.860 --> 00:12:38.860
5 von Coverage, geht das auch, dass man halt

00:12:38.860 --> 00:12:40.100
dem sagen kann,

00:12:40.520 --> 00:12:42.200
sag mir doch mal, wie viele von den

00:12:42.200 --> 00:12:44.320
If-Verzweigungen, also es reicht

00:12:44.320 --> 00:12:45.740
nicht, dass das einmal drüber gelaufen ist, sondern

00:12:45.740 --> 00:12:48.320
auch, ob die tatsächlich

00:12:48.320 --> 00:12:50.260
beide Pfade genommen haben, ob irgendein

00:12:50.260 --> 00:12:51.840
Test getestet hat, ob beide Pfade genommen werden

00:12:51.840 --> 00:12:54.220
und dann sieht es halt

00:12:54.220 --> 00:12:56.220
schon anders aus. Und ich weiß, dass es Leute gibt,

00:12:56.320 --> 00:12:57.920
die dann sowas sagen wie, naja,

00:12:58.500 --> 00:13:00.100
das geht auch mit Coverage Leaders auch, dass man

00:13:00.100 --> 00:13:02.220
sagt, man kann auch zu jedem File

00:13:02.220 --> 00:13:04.440
angeben, welches andere File

00:13:04.440 --> 00:13:06.360
für die Abdeckung verantwortlich

00:13:06.360 --> 00:13:08.160
sein soll. Also wenn man jetzt zum Beispiel im Django-Projekt

00:13:08.160 --> 00:13:09.940
Models

00:13:09.940 --> 00:13:12.180
py-File hat, dann sagt man,

00:13:12.420 --> 00:13:13.780
okay, da

00:13:13.780 --> 00:13:16.260
soll die Abdeckung gewährleistet

00:13:16.260 --> 00:13:17.760
werden von Testmodels py

00:13:17.760 --> 00:13:20.220
und die Abdeckung, die

00:13:20.220 --> 00:13:21.700
daherkommt, dass das aus irgendwelchen anderen

00:13:21.700 --> 00:13:23.760
Integrationstests heraus auch

00:13:23.760 --> 00:13:25.860
aufgerufen wird, das zählt nicht.

00:13:26.420 --> 00:13:28.100
Weil ansonsten kannst du halt mit

00:13:28.100 --> 00:13:29.940
fetten Integrationstests deine Coverage hochbringen

00:13:29.940 --> 00:13:32.000
und, aber eigentlich ist das

00:13:32.000 --> 00:13:34.080
überhaupt nicht das, was du haben willst, sondern was du eigentlich haben willst,

00:13:34.160 --> 00:13:36.140
ist, dass du sicher sein kannst, wenn du jetzt was änderst,

00:13:36.680 --> 00:13:38.120
dass du tatsächlich

00:13:38.120 --> 00:13:39.800
nichts damit kaputt gemacht hast und

00:13:39.800 --> 00:13:42.120
das kriegst du gerade bei diesen dicken Tests

00:13:42.120 --> 00:13:43.940
ja gar nicht so richtig mit. Also außer

00:13:43.940 --> 00:13:45.180
du hast was wirklich Gravierendes kaputt gemacht.

00:13:47.580 --> 00:13:47.900
Ja.

00:13:50.020 --> 00:13:51.140
Ja, okay, wir sind durch mit Tests.

00:13:51.700 --> 00:14:05.480
Nee, nee. Ja, keine Ahnung, aber wie ist das denn praktisch? Wann habt ihr denn mit Testen angefangen? Ich glaube, ihr seid ja irgendwie, ihr macht ja bei euch ganz viel Django schon lange.

00:14:05.900 --> 00:14:06.180
Genau.

00:14:06.480 --> 00:14:08.080
Und habt ihr von Anfang an Tests verwendet?

00:14:08.840 --> 00:14:30.300
Tatsächlich nein. Ich meine, die Sinnhaftigkeit von Tests war uns natürlich schon klar, aber dadurch, dass wir halt im Agenturgeschäft sind, also sprich, da kommen Kunden und beauftragen dann irgendwas oder wir beraten Kunden, wie wir dann halt eine Software bauen, haben früher auch sehr viel Richtung, ja, so Businesslösungen, also wie man irgendeinen speziellen Business Case halt digitalisieren kann.

00:14:30.300 --> 00:14:54.720
Das ist auch wegen dem Wirtschaftsinformatik-Hintergrund, weil das halt ein ganz gutes Match war. Und haben halt dann früher am Ende gesagt, okay, Tests schreiben dauert Zeit. Also das ist schon einige Jahre her, aber es war halt so. Ich meine, quasi die Idee ist genau das Gegenteil von TDD. Also sprich, du schreibst das bei deinem Code und danach schreibst du die Tests. Und das ist ja quasi ein Mehrwert für den Kunden, weil die Software dann besser funktioniert. Und haben dann halt sehr realistisch versucht, dem Kunden das zu verkaufen.

00:14:56.680 --> 00:15:13.940
Und selbst bei technisch affineren Kunden war dann halt relativ schnell immer die Aussage, naja, es soll ja funktionieren und wenn es kaputt geht ohne Tests, dann müsst ihr es ja trotzdem ganz machen und sparen wir Geld, weil wir die Tests nicht bezahlen. Und das war dann bei uns so ein gewisses Learning, bis wir dann einfach…

00:15:13.940 --> 00:15:15.340
Ich würde das ja den Kunden lernen lassen.

00:15:16.920 --> 00:15:18.400
Wenn der Kunde auf die Nase fällt

00:15:18.400 --> 00:15:19.540
und du kannst ihm das vorher erzählen

00:15:19.540 --> 00:15:20.400
und er bezahlt es halt nicht,

00:15:20.740 --> 00:15:21.620
dann fällt es halt auf die Nase.

00:15:21.960 --> 00:15:23.620
Also man steht halt da ein bisschen blöd da.

00:15:23.920 --> 00:15:24.600
Das ist schon richtig.

00:15:24.860 --> 00:15:27.040
Aber viele, die ich so mitbekommen habe,

00:15:27.640 --> 00:15:29.380
an kleineren Kunden vor allen Dingen,

00:15:29.820 --> 00:15:30.140
die dann sagten,

00:15:30.180 --> 00:15:31.040
naja, jetzt können wir es nicht leisten,

00:15:31.140 --> 00:15:31.760
den Test machen wir jetzt nicht.

00:15:33.040 --> 00:15:34.800
Die kamen dann irgendwann reumütig zurück.

00:15:34.900 --> 00:15:35.940
Ja, wir haben jetzt eine Software gebaut,

00:15:36.020 --> 00:15:36.780
es wurde kein Test geschrieben,

00:15:36.860 --> 00:15:38.360
es funktioniert alles nicht mehr.

00:15:38.780 --> 00:15:39.180
Wir haben irgendwas,

00:15:39.300 --> 00:15:40.540
vielleicht haben die selber irgendwas angepasst.

00:15:40.540 --> 00:15:42.620
Da konnte irgendjemand von den Menschen aus der Firma

00:15:42.620 --> 00:15:44.680
so ein bisschen Dango und hat dann irgendwas umgebaut

00:15:44.680 --> 00:15:46.680
und irgendwas kaputt gemacht oder irgendwas anderes,

00:15:46.780 --> 00:15:47.920
was ihm erst später aufgefallen ist.

00:15:48.840 --> 00:15:50.680
Ich muss sagen, also dafür,

00:15:50.840 --> 00:15:52.600
dass wir erst, also dass wir die

00:15:52.600 --> 00:15:54.720
ersten Jahre, als wir noch ganz klein waren,

00:15:55.320 --> 00:15:56.580
tatsächlich keinen Test geschrieben haben,

00:15:56.580 --> 00:15:58.440
haben die Sachen trotzdem überraschend gut funktioniert.

00:15:58.660 --> 00:15:59.820
Also es wundert mich rückblickend auch.

00:16:00.200 --> 00:16:00.900
Ihr seid alle so gut.

00:16:03.660 --> 00:16:04.720
Aber es ist echt überraschend.

00:16:04.920 --> 00:16:06.560
Also wenn ich heutzutage, wo ich das mit den

00:16:06.560 --> 00:16:08.360
Tests weiß, dann werde ich so schnell nervös,

00:16:08.440 --> 00:16:10.420
wenn ich für irgendwas Kritisches keinen Test schreibe.

00:16:12.100 --> 00:16:27.720
Naja, auf jeden Fall, wir haben dann halt irgendwann einfach gesagt, komm, das ist einfach Teil der Programmierarbeit, das steht nicht zur Debatte. Und ja, seitdem machen wir das. Und ja, ich glaube, der…

00:16:27.720 --> 00:16:29.120
Habt ihr richtig so eine Struktur da drin?

00:16:31.400 --> 00:16:55.540
Also wir haben jetzt keinen Coding Guide in der Firma. Also ich meine, jeder kann es im Endeffekt machen, wie er möchte. Ich meine, natürlich haben wir halt diese typischen QA Schritte wie Code Review, Content Review und sowas. Das ist natürlich ganz klar, dass wenn dann jemand irgendwie der Meinung ist, dass irgendwie Tests so und so geschrieben gehören und dass irgendeine wichtige Funktion nicht hinreichend getestet ist, dann kriegt man natürlich den Ball nochmal zurück. Aber im Endeffekt gibt es da jetzt keine offizielle Guideline oder sowas, weil ich meine, wie es bei Python so schön heißt, we are all adults here.

00:16:55.540 --> 00:17:25.520
Ja, also jeder weiß ja, was er macht und die Akzeptanz ist auch da. Also das finde ich halt bei uns auch ganz cool, dass unsere, die Geschäftsführer sind halt auch Wirtschaftsinformatiker, also auch Techniker. Das heißt, wir hatten, wir haben bei uns nie das Problem, was man halt sonst, zum Beispiel mein Studentenjob, so was ich öfters mal hatte, dass dann halt da ein Technikfremder halt sagt, das muss irgendwie ganz schnell funktionieren und dann wird halt lange gefrickelt und gewurschtelt und es kommt nie der Punkt, wo man mal das nötige Refactoring macht.

00:17:25.540 --> 00:17:37.660
weil Nicht-Techniker dann manchmal halt nicht den, ja, den Mehrwert sehen. Ja, also dass man dann auch einfach unterm Strich halt sehr viel Geld sparen kann, wenn Code einfach maintained ist und vielleicht dann auch getestet.

00:17:37.800 --> 00:17:46.600
Wir verkaufen das im Internen mittlerweile als Security-relevant. Also wenn es keine Tests gibt, dann ist ganz viel Sicherheitslücken da, man muss da sicherstellen, dass das nicht…

00:17:46.600 --> 00:18:08.940
Also, ja, ich bin mir nicht sicher, ob es da nicht inzwischen, also, ich glaube, wir hatten das Thema auch schon mal in der Projektmanagement-Episode, aber ob da nicht tatsächlich ein echter Interessenskonflikt ist, weil es kann sein, dass ich aus einer Wirtschaftssicht vielleicht tatsächlich sage, okay, für die Qualität bin ich nicht bereit zu bezahlen, weil ich hätte gerne lieber mehr Geschwindigkeit.

00:18:09.540 --> 00:18:15.040
Die Musik hat sich übrigens gerade eben geändert, ich hoffe, ihr hört das nicht alle. Es war eben so schön entspannt und jetzt haben sie ein bisschen mehr Beats reingebracht.

00:18:15.520 --> 00:18:17.600
Ja, ich treffe das jetzt so ein bisschen

00:18:17.600 --> 00:18:19.080
durch die Nackt.

00:18:19.880 --> 00:18:20.540
Ja, also

00:18:20.540 --> 00:18:22.900
es kann ja sein, dass ich aus einer wirtschaftlichen

00:18:22.900 --> 00:18:24.500
Sicht sage,

00:18:24.820 --> 00:18:27.680
das, was die mir an Qualität liefern, das ist mir ehrlich gesagt

00:18:27.680 --> 00:18:29.240
zu hoch. Ich hätte gerne lieber

00:18:29.240 --> 00:18:30.600
weniger Qualität und dafür schneller.

00:18:31.780 --> 00:18:33.560
Und das hat den zusätzlichen

00:18:33.560 --> 00:18:35.480
Vorteil, dass wenn es dann schief geht, dann kann ich zu ihnen

00:18:35.480 --> 00:18:37.040
hingehen und mit ihnen schimpfen und sagen hier so

00:18:37.040 --> 00:18:39.320
das hat nicht richtig funktioniert,

00:18:39.520 --> 00:18:41.460
jetzt macht man noch schneller. Voll gut.

00:18:41.700 --> 00:18:43.620
Ja, ich muss ja nur ein bisschen besser sein als meine Konkurrenz

00:18:43.620 --> 00:18:45.940
und ein bisschen weniger zahlen für die Produktivität,

00:18:46.040 --> 00:18:46.980
die ich da irgendwie rausquetsche.

00:18:47.600 --> 00:18:49.580
Und dann schon läuft es bei mir

00:18:49.580 --> 00:18:51.720
besser als bei anderen. Ja, aber dann wäre das

00:18:51.720 --> 00:18:53.440
Problem bei der Entwicklerseite, weil dann kein

00:18:53.440 --> 00:18:55.340
Entwickler dürfte sich darauf einlassen, weil...

00:18:55.340 --> 00:18:57.500
Ja, aber ich glaube, Leute tun das dann

00:18:57.500 --> 00:19:00.000
trotzdem und geraten dadurch auch in blöde Situationen.

00:19:00.040 --> 00:19:01.180
Und das ist mir auch schon selber passiert.

00:19:01.500 --> 00:19:03.400
Und man muss eigentlich als Entwickler und dann halt

00:19:03.400 --> 00:19:05.420
vielleicht auch als Agentur, die das dann

00:19:05.420 --> 00:19:07.280
komplett anbietet, eigentlich sagen,

00:19:07.400 --> 00:19:08.780
okay, nee, das ist das, was ich an Qualität...

00:19:08.780 --> 00:19:10.980
Also sozusagen, das ist eigentlich meine einzige Verantwortung,

00:19:11.160 --> 00:19:13.360
ist zu sagen, ich übe meine Profession kompetent aus.

00:19:13.900 --> 00:19:15.760
Und wie ich das mache, ist eigentlich meine Sache.

00:19:16.140 --> 00:19:17.900
Und ja, du kannst halt das nehmen oder nicht.

00:19:18.080 --> 00:19:22.940
Aber ich werde keine Einschnitte bei der Qualität machen,

00:19:23.040 --> 00:19:24.900
weil hinterher bin ich eh der Blöde.

00:19:25.000 --> 00:19:26.100
Wenn es schief geht, bin ich der Blöde.

00:19:26.720 --> 00:19:31.400
Und ich bin sowieso der Blöde, weil ich irgendwie damit,

00:19:31.540 --> 00:19:36.740
ja sozusagen auch mich selbst sabotiere.

00:19:36.740 --> 00:19:38.100
Ich meine, man wird dann ja auch schlechter,

00:19:38.240 --> 00:19:39.900
aber man lernt das dann ja.

00:19:39.900 --> 00:19:41.780
dass man halt rumschlampt und so.

00:19:41.920 --> 00:19:43.680
Und das ist eigentlich alles, das will man einfach alles gar nicht,

00:19:43.800 --> 00:19:47.100
sondern man möchte eigentlich mit weniger Zeit mehr hinbekommen.

00:19:47.320 --> 00:19:49.460
In der Umschlammschule, man lernt rumzuschlammen.

00:19:49.700 --> 00:19:51.940
Und Tests lösen das.

00:19:53.800 --> 00:19:56.000
Ja, ich meine, die Frage ist halt auch, was man für einen Anspruch hat

00:19:56.000 --> 00:19:58.360
oder was der Lebenszyklus der Software ist.

00:19:58.520 --> 00:20:02.760
Also als wir noch ganz klein waren, da haben wir dann öfters mal so Marketing-One-Pager gemacht,

00:20:02.900 --> 00:20:04.980
keine Ahnung, Kaugummi-Werbung und sowas.

00:20:05.140 --> 00:20:08.640
Das ist so ein Ding, da ist ein Gewinnspiel drin, das läuft genau für einen Monat

00:20:08.640 --> 00:20:11.020
und danach wird das Ding eingestampft und es braucht kein Mensch mehr.

00:20:11.380 --> 00:20:12.000
Ja gut, klar.

00:20:12.600 --> 00:20:14.180
Das sollte natürlich trotzdem funktionieren.

00:20:15.500 --> 00:20:19.180
Das merkt man ja beim Angucken schon fast, wenn man einfach Localhost aufmacht.

00:20:20.220 --> 00:20:24.720
Aber wenn man halt sagt, hey, das ist irgendwie jetzt vielleicht was, was firmenstrategisch relevant ist,

00:20:26.620 --> 00:20:30.420
da committet sich die Firma auch ein bisschen drauf, dass jetzt vielleicht auch über Jahre,

00:20:30.420 --> 00:20:33.180
dass sie da halt irgendwie investiert hat und das muss gut laufen.

00:20:34.720 --> 00:20:37.720
Ja, also ich meine, bei den Projekten, die wir jetzt lange betreuen

00:20:37.720 --> 00:20:39.200
und die wir damals auch ohne Tests angefangen haben,

00:20:39.500 --> 00:20:40.780
ziehen wir die jetzt auch einfach nach.

00:20:41.080 --> 00:20:42.660
Weil ich meine, das ist halt einfach sinnvoll.

00:20:43.460 --> 00:20:46.300
Und man kann inzwischen …

00:20:46.300 --> 00:20:47.260
Macht ihr das dann auf eigene Kosten

00:20:47.260 --> 00:20:47.960
oder sagt dann der Kunde,

00:20:48.100 --> 00:20:50.880
ja okay, das ist jetzt hier in unserem Supportaufwand das …

00:20:50.880 --> 00:20:52.620
Wir machen das eigentlich so,

00:20:52.680 --> 00:20:53.380
dass wir jetzt halt sagen,

00:20:53.500 --> 00:20:55.740
die Tests sind ein elementarer Teil der Programmierung.

00:20:56.140 --> 00:20:56.460
Ja.

00:20:56.700 --> 00:20:57.380
Also das ist halt so,

00:20:57.420 --> 00:20:58.600
als ob man sagt …

00:20:58.600 --> 00:21:01.080
Zehn Minuten aus einer Stunde nur für Tests oder so.

00:21:01.500 --> 00:21:03.100
Ja, ich würde sagen, wie gesagt,

00:21:03.220 --> 00:21:03.980
also ich bin jetzt auch keiner,

00:21:04.100 --> 00:21:05.960
der sagt, coverage 100 Prozent,

00:21:05.960 --> 00:21:07.820
weil wie gesagt, ich glaube einfach 80-20-Regel,

00:21:07.880 --> 00:21:09.300
ich glaube in 80% der Zeit,

00:21:10.000 --> 00:21:11.760
also 80% des Notwendigen

00:21:11.760 --> 00:21:13.120
kriegt man in 20% der Zeit hin.

00:21:14.380 --> 00:21:15.540
Und keine Ahnung, wenn ich da irgendwelche

00:21:15.540 --> 00:21:18.000
Django-Views oder sowas habe, die mehr oder weniger einfach

00:21:18.000 --> 00:21:19.960
getestete Django-Funktionalität ausführen,

00:21:20.060 --> 00:21:21.080
schreibe ich keinen Test dafür.

00:21:21.260 --> 00:21:24.180
Wenn ich irgendwelche Permissions drin habe, an denen ich selber rumgebastelt

00:21:24.180 --> 00:21:25.680
habe, okay, das ist was anderes,

00:21:25.860 --> 00:21:27.300
weil das kann echt mal schnell in die Hose gehen.

00:21:27.940 --> 00:21:29.160
Aber so Standard-Funktionalität

00:21:29.160 --> 00:21:31.560
teste ich jetzt auch nicht unbedingt.

00:21:31.740 --> 00:21:34.080
Also umso mehr es Richtung Zahlen und Details

00:21:34.080 --> 00:21:36.080
und Services geht, also weiter weg

00:21:36.080 --> 00:21:37.440
von dem Django-Standard.

00:21:38.380 --> 00:21:40.060
Übrigens interessant, wir reden gerade

00:21:40.060 --> 00:21:42.100
die ganze Zeit nur von Django, also Testing kann man ja

00:21:42.100 --> 00:21:43.960
auch außer von Django tun. Das stimmt. Aber wir

00:21:43.960 --> 00:21:46.060
machen halt einfach viel Django, deswegen reden wir jetzt erstmal weiter über

00:21:46.060 --> 00:21:48.100
Django-Tests. Aber ich meine, die meisten

00:21:48.100 --> 00:21:49.480
Sachen sind ja universal.

00:21:51.240 --> 00:21:52.260
Also ist ja jetzt nichts

00:21:52.260 --> 00:21:53.940
Django-spezifisches, also selbst bei

00:21:53.940 --> 00:21:54.700
Flask gibt es Views.

00:21:57.220 --> 00:21:58.100
Ja, und eigentlich hat man

00:21:58.100 --> 00:22:00.020
bei jedem Projekt, also es sei denn, man macht halt

00:22:00.020 --> 00:22:02.100
irgendwas, was halt tatsächlich nicht so einen

00:22:02.640 --> 00:22:04.000
wichtigen Anwendungsfall hat, aber

00:22:04.000 --> 00:22:05.320
eigentlich hat man immer Tests mit dabei.

00:22:06.080 --> 00:22:08.100
Und auch bei Django ist genau das, was man halt sonst verwendet,

00:22:08.320 --> 00:22:09.860
irgendwie üblich, nämlich entweder das

00:22:09.860 --> 00:22:12.340
eingebaute Unit-Tests-Modul

00:22:12.340 --> 00:22:14.140
aus der Standardbibliothek oder halt eben

00:22:14.140 --> 00:22:15.480
PyTest, wobei

00:22:15.480 --> 00:22:17.940
ich sagen würde so,

00:22:18.440 --> 00:22:20.120
wenn ich mich so umgucke bei den Projekten,

00:22:20.800 --> 00:22:21.960
in denen ich irgendwie beteiligt bin,

00:22:22.320 --> 00:22:24.080
ist die Mehrheit inzwischen auf PyTest

00:22:24.080 --> 00:22:26.000
und Unit-Test fühlt sich so ein bisschen an,

00:22:26.000 --> 00:22:27.580
als das sind immer so die etwas älteren Sachen

00:22:27.580 --> 00:22:29.500
und die etwas nicht so ganz gut gepflegten.

00:22:30.260 --> 00:22:31.700
Und ich meine, natürlich hat das irgendwie

00:22:31.700 --> 00:22:32.940
gewissen Charme, dass das...

00:22:32.940 --> 00:22:34.840
Vielleicht, erklär mir doch mal kurz, was denn überhaupt der Unterschied ist

00:22:34.840 --> 00:22:36.580
zwischen Unit-Testers und was PyTester neu herumbringt.

00:22:36.860 --> 00:22:38.260
Und es gibt auch einen Nose-Tester oder sowas.

00:22:39.640 --> 00:22:40.480
Ja, Nose

00:22:40.480 --> 00:22:42.640
war früher ein Test-Runner.

00:22:42.740 --> 00:22:44.800
Ich glaube, das ist inzwischen gar nicht mehr wirklich

00:22:44.800 --> 00:22:45.300
Main-Tent.

00:22:46.280 --> 00:22:47.640
Ich habe gehört, Johannes benutzt noch viel Nose.

00:22:48.040 --> 00:22:48.880
Ernsthaft? Okay.

00:22:49.320 --> 00:22:50.400
Vielleicht bist du ja auch Unit-Tester, ich weiß nicht.

00:22:50.760 --> 00:22:52.320
Er möge mich schlagen, wenn er das hört.

00:22:54.360 --> 00:22:55.260
Ja, keine Ahnung.

00:22:55.540 --> 00:22:57.500
Also Nose kenne ich auch noch, aber das ist schon echt lange her.

00:22:57.500 --> 00:22:59.680
Also aus meiner Perspektive

00:22:59.680 --> 00:23:00.980
ist es, also

00:23:00.980 --> 00:23:03.500
Unit-Test ist irgendwie eine Portierung von

00:23:03.500 --> 00:23:05.680
JUnit und hat halt

00:23:05.680 --> 00:23:07.680
viele der Konzepte dort mitgebracht,

00:23:07.800 --> 00:23:09.200
die ja auch jetzt vielleicht gar nicht so schlecht sind, aber

00:23:09.200 --> 00:23:11.640
das passt halt in vielen Fällen nicht so

00:23:11.640 --> 00:23:13.500
richtig auf das, wie man in Python normalerweise

00:23:13.500 --> 00:23:15.600
programmiert. Was heißt das denn?

00:23:15.800 --> 00:23:17.600
Also was macht JUnit und warum

00:23:17.600 --> 00:23:19.540
ist das so anders als das? Ja, zum Beispiel

00:23:19.540 --> 00:23:21.640
einfach allein, dass die Methoden am CamelCase sind.

00:23:22.100 --> 00:23:23.520
Ja, okay. Dann,

00:23:23.740 --> 00:23:24.380
dass du halt

00:23:24.380 --> 00:23:27.560
Assert-Methoden hast auf dem Test,

00:23:27.660 --> 00:23:28.940
dass jeder Test eine Klasse sein muss.

00:23:29.940 --> 00:23:32.920
Das ist halt, also ich meine.

00:23:33.120 --> 00:23:33.760
Wie testet man überhaupt?

00:23:33.860 --> 00:23:37.620
Also man macht eine Testklasse und da setzt man quasi die Umgebung auf

00:23:37.620 --> 00:23:40.340
und dann prüft man, ob bestimmte Bedingungen erfüllt sind

00:23:40.340 --> 00:23:41.620
und dann baut man alles wieder auseinander.

00:23:43.500 --> 00:23:47.720
Ja, also wenn man jetzt so, wie Schreib- und Tests kommen,

00:23:47.900 --> 00:23:51.240
also da ist es halt, nennt man das so AAA, wie heißt das, Range?

00:23:53.080 --> 00:23:54.440
Ich glaube, wo ist das Intent, wenn man es braucht?

00:23:54.440 --> 00:23:57.920
Oder sowas und Assert oder weiß ich nicht.

00:23:58.320 --> 00:24:03.900
Also man arrangiert sozusagen die Dinge, die man halt, die Welt sozusagen so hinten, dass man testen kann.

00:24:03.980 --> 00:24:07.840
Dann ruft man halt die Funktion, die man testet, auf oder halt was auch immer man da testen möchte.

00:24:07.840 --> 00:24:14.920
Und dann guckt man hinterher, ist jetzt alles in sozusagen gefälliger Weise wieder drüber zerfallen.

00:24:15.440 --> 00:24:20.820
Und es ist so passiert, wie es hätte, wie ist der sozusagen Schornstein in die richtige Richtung,

00:24:20.980 --> 00:24:23.800
der Baum in die richtige Richtung umgefallen sozusagen nach dem, ja.

00:24:24.380 --> 00:24:26.420
Und das macht man halt

00:24:26.420 --> 00:24:28.400
bei Unit-Tests in der Klasse.

00:24:30.340 --> 00:24:32.160
Die Tastic-Testcase, ich glaube, Django-Testcase

00:24:32.160 --> 00:24:34.200
erbt auch von den Unit-Testcase, oder?

00:24:34.700 --> 00:24:36.280
Ja. Also es gibt bei Django

00:24:36.280 --> 00:24:38.720
vier Testcase-Klassen,

00:24:39.200 --> 00:24:40.520
aber ich glaube,

00:24:41.140 --> 00:24:42.280
die erben alle

00:24:42.280 --> 00:24:43.220
von Testcase, ja.

00:24:45.340 --> 00:24:46.520
Genau, bei PyTest ist es so,

00:24:46.620 --> 00:24:48.480
da können auch Tests einfach Funktionen sein

00:24:48.480 --> 00:24:50.700
und das ist halt nicht Camel-Case,

00:24:50.820 --> 00:24:52.560
sondern Snake-Case oder keine Ahnung,

00:24:52.760 --> 00:24:53.480
mit Underscores halt.

00:24:54.380 --> 00:24:55.840
Und man verwendet halt nicht

00:24:55.840 --> 00:24:58.480
Methoden auf dem Test, um zu testen,

00:24:58.540 --> 00:24:59.940
um zu asserten, sondern

00:24:59.940 --> 00:25:02.800
man benutzt einfach das Assert-Statement.

00:25:03.840 --> 00:25:05.080
Das macht PyTest ja jetzt auch dann.

00:25:05.320 --> 00:25:06.060
Das macht PyTest.

00:25:06.340 --> 00:25:07.180
Unitest macht das nicht.

00:25:07.660 --> 00:25:10.500
Also bei Unitest gibt es mal diese Assert-Equals, das hat mich immer so ein bisschen gewundert.

00:25:10.600 --> 00:25:12.380
Ja, genau, genau. Assert-Equals,

00:25:12.500 --> 00:25:13.800
super, super Beispiel, genau.

00:25:14.100 --> 00:25:16.460
Wisst ihr das, was die richtige Methode ist? Assert-Equals

00:25:16.460 --> 00:25:18.540
oder Assert-Equal? Ich glaube ohne S, oder?

00:25:20.120 --> 00:25:20.500
Ja, siehste,

00:25:20.500 --> 00:25:21.380
weiß ich jetzt auch gar nicht.

00:25:22.020 --> 00:25:23.980
Eins von beiden ist richtig, das andere ist nicht gut.

00:25:24.160 --> 00:25:26.260
PyCharm zeigt mir immer an, dass, glaube ich, das mit S,

00:25:26.340 --> 00:25:28.140
das ist immer durchgestrichen wegen Deprecation.

00:25:28.360 --> 00:25:28.540
Ja.

00:25:29.880 --> 00:25:30.400
Assert-Equal.

00:25:30.780 --> 00:25:32.160
Eins von beiden ist deprecated, genau.

00:25:33.000 --> 00:25:34.520
Aber das ist halt so, das ist halt das Problem,

00:25:34.580 --> 00:25:36.740
das man bekommt, wenn man halt so Spezialkram macht.

00:25:37.140 --> 00:25:38.100
Ja, das versteht man auch nicht.

00:25:38.180 --> 00:25:40.280
Warum kann man nicht einfach die Python-implementierte Funktion

00:25:40.280 --> 00:25:42.320
Assert nehmen und dann die zwei Dinge direkt vergleichen,

00:25:42.400 --> 00:25:43.900
anstatt Assert-Equal hinzuschreiben und zwei Dinge

00:25:43.900 --> 00:25:45.320
in diesem Funktionsaufbruch zu gehen?

00:25:45.640 --> 00:25:47.080
Da passieren irgendwelche magischen Dinge im Hintergrund,

00:25:47.120 --> 00:25:48.720
wo ich gar nicht weiß, ob das so stimmt.

00:25:48.760 --> 00:25:52.280
Ja gut, wenn du sozusagen bestimmte Sachen

00:25:52.280 --> 00:25:53.620
mit einem gefällten Test machen willst oder so,

00:25:53.640 --> 00:25:56.060
dann kannst du das ja quasi gar nicht

00:25:56.060 --> 00:25:57.420
so richtig gut anders machen, oder?

00:25:58.000 --> 00:26:00.100
Ich weiß es nicht, vielleicht ist es auch einfach nur Geschmacksgeschichte.

00:26:00.800 --> 00:26:01.760
Wie ist das denn

00:26:01.760 --> 00:26:03.520
mit zum Beispiel den anderen Asserts,

00:26:03.560 --> 00:26:04.720
zum Beispiel AssertRaises?

00:26:06.580 --> 00:26:07.960
Kannst du das auch über das AssertStatement

00:26:07.960 --> 00:26:09.040
abbilden bei PyTest?

00:26:10.680 --> 00:26:11.040
Ja,

00:26:12.200 --> 00:26:13.060
aber es kann sein, dass man...

00:26:13.060 --> 00:26:15.780
Also wenn man jetzt Tests zwar accept Asserts und AddRaises...

00:26:15.780 --> 00:26:17.380
Nein, nein, aber es kann sein,

00:26:17.620 --> 00:26:19.580
also es ist auch ein ContextManager,

00:26:19.580 --> 00:26:21.560
es ist irgendwie With irgendwas, Raises,

00:26:22.060 --> 00:26:23.620
Aber ich glaube, man importiert da irgendwas

00:26:23.620 --> 00:26:25.580
dann aus PyTest. Also der Hintergrund ist

00:26:25.580 --> 00:26:27.260
ja einfach nur, dass falls jemand,

00:26:27.500 --> 00:26:29.620
falls eine Funktion Fehler werfen soll und man

00:26:29.620 --> 00:26:30.920
genau diesen Case testen möchte.

00:26:31.720 --> 00:26:33.620
Ja, also das gibt es auf jeden Fall.

00:26:35.360 --> 00:26:37.240
Ich muss gestehen, ich nutze auch das, was

00:26:37.240 --> 00:26:38.880
Django von Haus aus mitbringt.

00:26:40.060 --> 00:26:41.800
Ich habe da, ich habe einen Kollegen,

00:26:41.920 --> 00:26:43.580
der sehr auf PyTest schwert und meint, das ist ja alles

00:26:43.580 --> 00:26:45.620
viel besser und schneller. Ich habe das auch

00:26:45.620 --> 00:26:47.080
auf meiner Liste, dass ich mir das nochmal anschaue.

00:26:49.020 --> 00:26:49.740
Ja, es

00:26:49.740 --> 00:26:51.420
ist halt sehr convenient, wenn du halt in der

00:26:51.420 --> 00:26:53.580
Django-eigenen Welt bleibst, dann

00:26:53.580 --> 00:26:55.380
muss man halt wenig

00:26:55.380 --> 00:26:57.280
nachdenken. Von Jochen jetzt

00:26:57.280 --> 00:26:59.060
PyTest irgendwie gelernt.

00:26:59.660 --> 00:27:01.640
Modus hast du mal vier und da gibt es halt

00:27:01.640 --> 00:27:03.460
diese Features. Gibt es die auch so

00:27:03.460 --> 00:27:04.000
bei

00:27:04.000 --> 00:27:07.540
Unit-Tests ohne PyTest? Also ich dachte, das wäre

00:27:07.540 --> 00:27:09.500
so ein PyTest-exklusives Feature. Also in Django

00:27:09.500 --> 00:27:11.460
kannst du es laden. Also in Django gibt es

00:27:11.460 --> 00:27:13.480
in dieser Django-Test-Case-Klasse kannst du

00:27:13.480 --> 00:27:13.880
einfach

00:27:13.880 --> 00:27:17.320
ein Array mit Strings

00:27:17.320 --> 00:27:19.200
und diese Strings sucht er dann,

00:27:19.460 --> 00:27:20.460
der sucht dann nach

00:27:20.460 --> 00:27:22.500
Fixture.json-Dateien.

00:27:22.580 --> 00:27:24.640
Okay, aber ich mache tatsächlich Fixture.json und ich muss

00:27:24.640 --> 00:27:26.480
halt dann dadurch meine Sachen... Genau, aber das ist jetzt nur

00:27:26.480 --> 00:27:28.220
Django, das ist nicht Unit-Test. Also ich weiß nicht, wie

00:27:28.220 --> 00:27:30.220
ein Test das machen würde. Also ich kenne das

00:27:30.220 --> 00:27:32.280
als PyTest, dass ich tatsächlich meine Fixture-Funktionen baue

00:27:32.280 --> 00:27:33.620
in der Comptest und dann irgendwie

00:27:33.620 --> 00:27:36.220
meine Objekte schon so erzeuge,

00:27:36.320 --> 00:27:38.240
wie sie, glaube ich, im

00:27:38.240 --> 00:27:40.380
echten, realen Django-Leben

00:27:40.380 --> 00:27:41.460
dann auch wären.

00:27:42.660 --> 00:27:44.200
Und das hat vielleicht auch viele Vorteile,

00:27:44.260 --> 00:27:46.220
weil ich halt genau auf die Attribute und so weiter alles zugreifen kann

00:27:46.220 --> 00:27:48.460
und ich dann halt Factories nutzen kann, um die zu erzeugen

00:27:48.460 --> 00:27:50.100
und halt eben nicht nur irgendwie

00:27:50.100 --> 00:27:52.200
Fixtures? Also das macht man im Unit-Test

00:27:52.200 --> 00:27:53.940
auch. Also so Factory-Boy oder

00:27:53.940 --> 00:27:55.300
Factories, um halt

00:27:55.300 --> 00:27:58.120
aber, ja, aber diese Art,

00:27:58.240 --> 00:28:00.020
wie man in Pytest halt, dass man das

00:28:00.020 --> 00:28:02.060
quasi einfach magisch, dass man das halt

00:28:02.060 --> 00:28:04.160
in den Testaufruf

00:28:04.160 --> 00:28:06.060
mit reinschreibt halt, das man haben möchte und es ist

00:28:06.060 --> 00:28:07.900
dann halt einfach da. Das ist auch so natürlich

00:28:07.900 --> 00:28:09.960
ein bisschen magisch. Das gibt es im Unit-Test nicht.

00:28:10.320 --> 00:28:11.320
Da muss man es explizit machen.

00:28:12.140 --> 00:28:13.760
Okay, ja, aber das finde ich eigentlich relativ smart, weil das

00:28:13.760 --> 00:28:15.800
gefällt mir. Ich kann einfach meine Fixtures definieren pro

00:28:15.800 --> 00:28:17.960
App, die ich dann irgendwie entwickelt habe und

00:28:17.960 --> 00:28:19.980
dann kann ich die importieren in anderen Apps als

00:28:19.980 --> 00:28:22.160
Confest und habe dann alle Funktionalitäten

00:28:22.160 --> 00:28:23.860
nicht, da brauche ich irgendwie... Ich löse das halt über

00:28:23.860 --> 00:28:25.960
Vererbung, also ich habe halt dann einen Basetest, der

00:28:25.960 --> 00:28:27.920
dann halt für mein Projekt halt irgendwie die Rollen,

00:28:28.020 --> 00:28:30.040
die User, vielleicht

00:28:30.040 --> 00:28:31.880
irgendwie ein wichtiges Projekt oder irgendwas

00:28:31.880 --> 00:28:33.900
erstellt und dann halt

00:28:33.900 --> 00:28:35.980
pro App, dass ich dann halt,

00:28:36.440 --> 00:28:37.560
wenn ich das brauche, dann nochmal

00:28:37.560 --> 00:28:39.960
eine Ebene dazwischen ziehe und dass dann jeder

00:28:39.960 --> 00:28:42.000
von den richtigen Tests, also

00:28:42.000 --> 00:28:43.100
die Endtests,

00:28:43.700 --> 00:28:45.920
dass die halt dann von dieser Klasse erben

00:28:45.920 --> 00:28:47.500
und da ist dann das dementsprechende Setup

00:28:47.500 --> 00:28:49.020
im Setup drin.

00:28:49.980 --> 00:28:53.460
Das heißt, ich nutze diese Django-Fixers auch eher selten.

00:28:54.980 --> 00:29:07.100
Ja, genau. Ich habe auch viel, also im Projekt mit Unitest, dass ich dann halt so viele Test-Mix-Ins importiere oder das habe ich halt früher immer gemacht dann, die dann halt bestimmte Funktionalität bieten.

00:29:07.400 --> 00:29:25.220
Und was ich jetzt aber inzwischen so mache, ist, ich erbe von Testcase oder halt Transaction Testcase oder was auch immer, also einem der Grundtesttypen von Django und mixe die Sachen dann da schon mal rein und verwende dann nur noch meine eigenen Testcases.

00:29:26.340 --> 00:29:35.420
Und sozusagen habe dann die ganzen Importe nicht mehr in den Tests stehen, sondern ich sage dann halt irgendwie, keine Ahnung, nimm halt den App-Test-Case von irgendeiner App und da sind die ganzen Mix-Ins dann halt drin.

00:29:36.120 --> 00:29:39.100
Und genau, dann ist es halt deutlich weniger Schreibarbeit.

00:29:39.480 --> 00:29:42.520
Ja, das sieht auch hübscher aus, glaube ich. Also ich habe, glaube ich, eine Sache gemacht, ich weiß nicht, ob man diese macht.

00:29:42.580 --> 00:29:50.880
Ich habe dynamische Importe gemacht für Tests von den Factories, die ich dann halt haben wollte in der Core-App, weil ich halt nicht genau weiß, wie viele Apps gibt es denn noch um die Core-App herum.

00:29:52.340 --> 00:29:55.000
Ich weiß nicht, ob das so eine gute Idee ist, aber das funktioniert bisher.

00:29:56.180 --> 00:29:57.540
dynamische Importe klingen zu müssen.

00:29:58.800 --> 00:29:59.660
Ja, naja.

00:29:59.900 --> 00:30:01.840
Ich meine, manchmal muss man auch Sachen ausprobieren und manchmal sind sie

00:30:01.840 --> 00:30:03.480
super. Wenn man stellt irgendwann fest,

00:30:03.800 --> 00:30:05.860
war nicht so gut, muss man es wieder ändern.

00:30:06.140 --> 00:30:07.020
Aber es ist halt, ja.

00:30:09.180 --> 00:30:09.620
Ja.

00:30:11.120 --> 00:30:11.960
Was ja fast

00:30:11.960 --> 00:30:13.880
schon ein Stichwort wäre zum... Ja, dynamische,

00:30:14.040 --> 00:30:16.160
genau. Zum Sachen ausprobieren.

00:30:16.800 --> 00:30:17.460
Ich hatte

00:30:17.460 --> 00:30:19.040
vor einiger Zeit

00:30:19.040 --> 00:30:21.860
habe ich eine Django-Software

00:30:21.860 --> 00:30:23.020
gebaut. Da ging es um

00:30:23.020 --> 00:30:25.820
Projektstundenerfassung und Zeiterfassung.

00:30:26.180 --> 00:30:38.360
Und alles, was irgendwie mit Daten, also Datums, also mit Zeit zu tun hat, ist ja schon relativ kompliziert. Und da ging es dann darum, dass halt eine Zeiterfassung abgebildet werden soll.

00:30:38.360 --> 00:30:56.460
Also Mitarbeiter können sich an und aus checken und dann gibt es natürlich so Späße wie jemand ist krank, jemand ist im Urlaub, es gibt einen Feiertag, es gibt halbe Feiertage, zum Beispiel Weihnachten und Silvester, also Heiligabend und Silvester sind halbe Feiertage, das heißt man hat, also wird je nach Firma anders ausgelegt, aber in dem Fall war das dann vier Stunden das normale Arbeitszeit wäre.

00:30:58.960 --> 00:31:16.160
Und die ganze Logik lief und hat auch gut funktioniert. Da habe ich immer gemerkt, wenn ich irgendwas refactoren möchte, ich hatte jedes Mal die Hosen voll und habe mich halt wirklich nicht daran getraut, weil das halt einfach so unmöglich zu testen ist. Und habe dann erst mal angefangen, ganz normal zu Fuß Tests zu schreiben, also einfach zu schauen.

00:31:16.160 --> 00:31:34.220
Und ich habe, ich setze den und den Case auf, also keine Ahnung, Mitarbeiter arbeitet normal fünf Tage die Woche, also diese ganzen Datenbankobjekte erstellt und habe gemerkt, da komme ich echt irgendwie nicht weit. Das sind so viele Fälle und auch immer diese ganzen Variationen. Was ist denn, wenn jemand zum Beispiel Teilzeit arbeitet und dann kommt ein Feiertag und dann vielleicht noch ein halber Feiertag und ja.

00:31:34.220 --> 00:31:40.340
Ach, ist ja ausgefallen, da ist die Vertretung und die Vertretung übernimmt dann aber noch anderthalb Tage, weil dann den halben Tag eine andere Vertretung dann reinkommt.

00:31:40.940 --> 00:31:52.180
Genau. Und dann habe ich angefangen, eine abstrakte Testklasse zu schreiben, die im Endeffekt alle Testmethoden implementiert.

00:31:53.180 --> 00:32:02.840
Und die quasi, diese Berechnung, also diese Zeitenberechnung, habe ich im Endeffekt nochmal abgespeckt, nachprogrammiert in dieser abstrakten Testklasse.

00:32:03.120 --> 00:32:24.300
Und diese abstrakte Klasse wird befüttert durch ein Dictionary von Objekten. Und diese Objekte, die sind zum Beispiel, der eine Mitarbeiter arbeitet ganz normal acht Stunden und macht so lange Pause. So, das ist ein Objekt, das da reingehen kann. Der andere ist zum Beispiel ein anderer Mitarbeiter, der ist nur halbtags da und der arbeitet diese, seine halbtags, also seine vier Stunden arbeitet der auch voll.

00:32:24.540 --> 00:32:26.400
Oder es ist ein Wochenendtag.

00:32:27.980 --> 00:32:34.600
Und ich konnte dann, wenn ich dann einen aktuellen, also einen tatsächlichen Test schreiben möchte, leite ich davon ab.

00:32:35.480 --> 00:32:45.480
Da sind gar keine Testmethoden in dieser Kindklasse drin, sondern ich befülle nur dieses Dictionary, diese Klassenvariable und gebe da eine Liste von Objekten rein.

00:32:45.540 --> 00:32:53.120
Sag zum Beispiel, okay, ich weiß der, keine Ahnung, 1.1.2017, 2017 habe ich es gemacht, darum, das war jetzt ein Sonntag.

00:32:53.120 --> 00:33:06.420
Das heißt, da gebe ich das Objekt rein, ist normaler Wochenendtag, da hat niemand gearbeitet. Am Montag kommt das Objekt rein, alle arbeiten normal und dann vielleicht die ganze Woche voll und dann schaue ich einfach, ob zu erwarten ist, dass niemand, also alle haben normal gearbeitet, dass es null Überstunden sind.

00:33:06.420 --> 00:33:23.420
Das macht dann aber wieder die abstrakte Klasse. Und das heißt, für jeden Testfall, den es gibt, also alle komischen Kombinationen, kann ich einfach diese Objekte befüllen. Und wenn ich jetzt einen neuen Testfall habe, muss ich entweder nur diese Liste neu zusammenstellen oder halt ein neues Objekt bauen, das halt die Sachen so einstellt, dass es funktioniert.

00:33:24.520 --> 00:33:37.700
War ziemlich abgefahren, ich habe auch ziemlich lange dafür gebraucht. Im Endeffekt war es ziemlich cool, weil jedes Mal, wenn ich einen Bug gefunden habe, konnte ich halt in drei Minuten, also literally drei Minuten, halt einfach diesen Fall nachstellen mit meinen ganzen Objekten und konnte sicherstellen, dass es beim nächsten Mal nicht mehr kaputt geht.

00:33:38.660 --> 00:33:50.480
Die größte Herausforderung dabei, und das ist auch so ein bisschen das große Fragezeichen dahinter, ist halt, wer kontrolliert den Kontrolleur? Weil ich habe ja den Code nochmal teilweise nachgebaut. Also ich habe ihn jetzt explizit nicht kopiert, sondern ich habe ihn neu geschrieben und auch ein bisschen abgespeckt.

00:33:50.960 --> 00:33:54.440
Aber was ist, wenn man jetzt einen Bug im Testcase hat?

00:33:54.480 --> 00:33:57.680
Und tatsächlich, glaube ich, 80 Prozent der fehlgeschlagenen Tests

00:33:57.680 --> 00:34:00.180
lagen daran, dass ich in der Nachimplementierung einen Bug hatte.

00:34:00.260 --> 00:34:01.620
Ich glaube, ich hatte eine richtige Implementierung,

00:34:01.680 --> 00:34:04.580
die ich damals noch vor vielen, vielen Jahren ohne Tests geschrieben habe.

00:34:04.880 --> 00:34:06.420
Da war tatsächlich auch kein Fehler mehr drin,

00:34:06.460 --> 00:34:08.500
weil es halt schon so lange lief und die alle ausgemerzt waren.

00:34:09.980 --> 00:34:11.700
Ich war mir sehr unsicher,

00:34:11.800 --> 00:34:13.600
ob das überhaupt eine gute Idee ist, das so zu machen,

00:34:13.700 --> 00:34:15.760
wegen der offensichtlichen Nachteile, die es halt gibt.

00:34:15.880 --> 00:34:18.000
Also dauert lang und wer kontrolliert das nachher?

00:34:18.080 --> 00:34:19.100
Oder wie kontrolliert man das?

00:34:19.800 --> 00:34:29.020
Und habe dann auf dem PyCologne Meetup, zufällig war da jemand, der mehr oder weniger in einer großen Firma genau sowas macht für sehr komplizierte Fälle.

00:34:29.140 --> 00:34:32.400
Ich glaube, das war medizinischer Bereich, wo es halt wirklich stimmen muss.

00:34:32.520 --> 00:34:36.040
Und der meinte, wenn es wirklich, wirklich kompliziert ist, dann geht es nicht anders.

00:34:36.040 --> 00:34:44.800
Also die meinte, es gibt sogar Software, die so kritisch ist, dass die einfach den Auftrag, das gleiche Pflichtenheft an zwei verschiedene Teams geben, die sich nicht kennen.

00:34:45.200 --> 00:34:47.980
Lass uns beide programmieren und das eine ist halt das Testsystem vom anderen.

00:34:49.100 --> 00:34:50.460
Ja, also es ist schon absurd.

00:34:51.100 --> 00:34:52.720
Das ist ja Mocken auf einem ganz hohen Niveau.

00:34:52.720 --> 00:34:59.160
Ja, das ist, ich meine, das ist ja auch immer die Frage, wie aufwendig ist es halt, irgendwas zu ändern.

00:34:59.360 --> 00:35:02.060
Also wenn man jetzt, ich meine, die Prozessorhersteller machen das ja auch,

00:35:02.620 --> 00:35:09.360
dass sie halt irgendwie wahnsinnig viele Tests machen, dann Stresstests irgendwie für neue Designs von ihren Chips und so

00:35:09.360 --> 00:35:13.600
und versuchen das letzte bisschen, was überhaupt testbar ist, da rauszukitzeln.

00:35:13.700 --> 00:35:18.900
Einfach deswegen, weil wenn die Maschinen erstmal eingestellt sind und die Wafer irgendwie belichtet,

00:35:18.900 --> 00:35:21.000
dann ist halt schlecht, wenn das irgendwie schiefgegangen

00:35:21.000 --> 00:35:22.900
ist, weil man kann man auch nicht

00:35:22.900 --> 00:35:24.620
mehr ändern, kann man halt hinterher nicht mehr fixen

00:35:24.620 --> 00:35:26.960
während, naja, Code kann man halt noch

00:35:26.960 --> 00:35:27.940
ändern, das heißt so

00:35:27.940 --> 00:35:31.040
furchtbar intensiv muss man es vielleicht auch nicht testen

00:35:31.040 --> 00:35:32.860
aber natürlich

00:35:32.860 --> 00:35:34.980
ist es halt immer noch blöd, wenn Sachen schief gehen

00:35:34.980 --> 00:35:37.100
daher, ja, irgendwo ist da ein Sweet Spot

00:35:37.100 --> 00:35:38.700
aber ist halt nicht so ganz klar, wo

00:35:38.700 --> 00:35:40.920
testen ist ja schon ein bisschen

00:35:40.920 --> 00:35:42.760
dunkle Magie auch, also ich hatte

00:35:42.760 --> 00:35:45.040
das Problem, ich habe einen Test geschrieben

00:35:45.040 --> 00:35:46.620
dann habe ich die Tests

00:35:46.620 --> 00:35:48.320
ausgeführt, dann

00:35:48.320 --> 00:35:50.500
war kein Problem mehr, alles richtig, dann habe ich es nochmal

00:35:50.500 --> 00:35:52.260
ausgeführt, einfach ohne irgendwas zu ändern und dann

00:35:52.260 --> 00:35:52.980
schlug der Test fehl.

00:35:53.980 --> 00:35:55.560
Was ist denn das jetzt?

00:35:56.340 --> 00:35:57.820
Habe ich nochmal ausgeführt, dann ging es wieder,

00:35:57.960 --> 00:35:59.900
dann habe ich nochmal ausgeführt, dann ging es wieder, dann habe ich nochmal ausgeführt,

00:35:59.960 --> 00:36:02.220
dann schlug es wieder fehl. Dann hat mir jemand erklärt,

00:36:02.260 --> 00:36:04.000
ich habe einen non-deterministischen Test geschrieben,

00:36:04.220 --> 00:36:05.500
also einen Test, der in Ausgang ungewiss ist.

00:36:05.920 --> 00:36:07.740
Und ich habe überhaupt nicht verstanden, von welchen

00:36:07.740 --> 00:36:09.280
Zeiteffekten, von welchen

00:36:09.280 --> 00:36:11.740
Gegebenheiten das hätte kommen können.

00:36:12.080 --> 00:36:13.840
Das fand ich total schwierig zu begreifen,

00:36:14.220 --> 00:36:15.400
warum der gleiche Test in

00:36:15.400 --> 00:36:18.140
mehrfacher Ausführung mal B-Check, mal nicht.

00:36:18.320 --> 00:36:47.560
Ja, das Ganze gibt es dann natürlich auch irgendwie in sozusagen Reihenfolgenabhängigkeiten, das ist wahrscheinlich somit das Häufigste, dass man quasi zwei Tests hatte und da, ohne dass man das jetzt beim Schreiben vielleicht so gedacht hätte, man macht es halt einfach so, weil das dann halt logisch hinterher passiert oder so, man macht zuerst das, dann testet man das nächste und verändert aber den State jetzt bei einem Django-Modell irgendwie so, dass der zweite Test halt funktioniert und wenn man jetzt die Tests in umgekehrter Reihenfolge ausführt, dann funktioniert das nicht mehr.

00:36:48.320 --> 00:36:54.840
Und das ist halt auch so ein Ding. Man muss halt eigentlich sicherstellen, dass die ganzen Tests isoliert funktionieren, weil ansonsten kann man nämlich...

00:36:54.840 --> 00:37:06.160
Da gibt es ein sehr schönes Beispiel, das ist auch ganz brandaktuell zu Django 3.1. Die haben da jetzt nämlich einen Bug gefixt, der schon, glaube ich, seit 2012 drin war, mit dem Order-By beim Aggregate. Ich weiß nicht, ob euch das mal über den Weg gelaufen ist.

00:37:06.780 --> 00:37:30.440
Ist mir am Anfang, als ich neu mit Junko war, immer wieder mal passiert, dass, ich bin mir nicht mehr so 100% sicher, ich habe es länger nicht mehr selber erlebt, aber wenn man eine Aggregierung oder ein Annotate macht und dann Order Buy, beziehungsweise nein, wenn das Model selbst in der Meta-Option, in Order Buy, der so eine standardmäßige Notierung aktiv hat, dann gab es Bugs.

00:37:30.440 --> 00:37:34.360
dann hat das ORM teilweise komische oder falsche Sachen zurückgegeben.

00:37:35.220 --> 00:37:37.620
Das ist wie der Bug, das Ticket ist 3000 Jahre alt

00:37:37.620 --> 00:37:39.940
und die haben das jetzt tatsächlich repariert

00:37:39.940 --> 00:37:44.340
und das führt dazu, dass die Lösung war einfach,

00:37:44.460 --> 00:37:47.480
das ist halt aus Gründen, funktioniert es nicht

00:37:47.480 --> 00:37:49.640
und das heißt, wenn du aggregierst oder annotierst,

00:37:50.220 --> 00:37:53.700
dann wird dieses Order By im Model Meter ignoriert.

00:37:54.600 --> 00:37:58.020
Das heißt, bei meinen Cases, wo ich das gemacht hatte,

00:37:58.080 --> 00:37:59.620
habe ich in meinen Test Cases natürlich erwartet,

00:37:59.620 --> 00:38:01.160
dass die Sachen sortiert kommen, weil ich ja wusste,

00:38:01.480 --> 00:38:04.120
meine Projektliste oder meine Mitarbeiterliste,

00:38:04.180 --> 00:38:06.160
die wird ja

00:38:06.160 --> 00:38:07.700
übers Model sortiert. Hatte ich natürlich

00:38:07.700 --> 00:38:08.800
kein explizites Order bei gemacht.

00:38:09.760 --> 00:38:11.600
Plötzlich schlagen irgendwelche Tests fehl, nachdem ich auf

00:38:11.600 --> 00:38:13.800
Django 3.1 hochgegangen bin, weil die Reihenfolge anders ist.

00:38:13.840 --> 00:38:15.780
Weil es gibt jetzt kein Order bei mir. Es gibt halt irgendeine

00:38:15.780 --> 00:38:17.160
Reihenfolge, die die Datenbank zurückgibt.

00:38:18.820 --> 00:38:19.680
Okay, ja, das ist

00:38:19.680 --> 00:38:21.580
aufgefallen, ja. Ziemlich abgefallen.

00:38:21.620 --> 00:38:23.000
Ich habe auch erst gedacht, das kann doch nicht sein.

00:38:23.280 --> 00:38:25.520
Ich habe Django hochgezogen, was ist denn da los?

00:38:25.920 --> 00:38:27.660
Bis mir dann ein

00:38:27.660 --> 00:38:29.140
lieber Kollege sagte, schau mal,

00:38:29.620 --> 00:38:31.540
Such mal nach Order-By in den...

00:38:31.540 --> 00:38:32.860
Also Order-By ist echt rausgeflogen?

00:38:33.460 --> 00:38:35.200
Nee, das ist nur für diesen Sonderfall.

00:38:35.260 --> 00:38:37.720
Das war ein Bug und den haben die jetzt rausgenommen.

00:38:38.240 --> 00:38:40.000
Also den haben die gefixt und die Lösung dafür ist,

00:38:40.060 --> 00:38:41.140
dass es halt nicht mehr genommen wird.

00:38:41.820 --> 00:38:43.960
Du kannst es manuell dahinter schreiben, dann funktioniert es.

00:38:44.000 --> 00:38:44.900
Aber du musst es halt manuell machen.

00:38:45.020 --> 00:38:46.020
Aber in der Meta-Klasse geht es nicht mehr?

00:38:47.600 --> 00:38:49.660
Immer, außer du machst Annotated Aggregate.

00:38:49.780 --> 00:38:50.120
Ah, okay.

00:38:51.280 --> 00:38:52.740
Da gibt es auch einen eigenen Eintrag dazu.

00:38:52.820 --> 00:38:54.860
Das ist auch irgendwo im Ticket nochmal festgehalten und verlinkt etc.

00:38:56.160 --> 00:38:58.400
Ich bin da jetzt auch nicht 100% in Details drin.

00:38:58.460 --> 00:38:59.520
Ich bin halt nur drüber gestolpert.

00:38:59.620 --> 00:39:13.720
Weil das war auch genau das mit der Reihenfolge. Plötzlich war mein Element, dass ich an Stelle 1 erwarte, an Stelle 2 und umgekehrt. Und wenn man halt die Tests so gebaut hat, dass der halt die Reihenfolge explizit erwartet, weil ich ja wusste, dass er damals noch sortiert war, dann steht man da plötzlich.

00:39:15.140 --> 00:39:19.800
Ja, und das mit der Reihenfolge von Tests ist halt…

00:39:19.800 --> 00:39:39.100
Und das ist halt auch deswegen so wichtig, weil nämlich ein Feature braucht quasi die Isolation, also dass halt alle Tests einzeln isoliert voneinander sind und nicht abhängig von irgendwelchen anderen Tests sind. Und das ist nämlich, dass man die Tests, wenn man die Tests parallel ausführen möchte, dann müssen die so sein, weil ansonsten kriegt man halt ein Problem.

00:39:40.460 --> 00:40:01.560
Und da gibt es dann halt auch, ich weiß nicht, ich glaube, da muss man irgendwas installieren, ich weiß es nicht mehr so genau. Also man kann auf jeden Fall, und ich weiß auch nicht, das ist bei PyTest und bei Unitest anders, aber man kann halt mit einer bestimmten Option sagen, so für die Tests mal eine umgekehrte Reihenfolge aus. Wenn das schief geht, dann weiß man schon, dass man ein Problem hat. Oder für die mal eine zufällige Reihenfolge aus, dann muss man es halt wahrscheinlich ein paar Mal ausführen und wenn es dann funktioniert hat, hat man vielleicht Glück gehabt und man kann es parallelisieren.

00:40:02.120 --> 00:40:18.000
Aber genau, wenn die Tests isoliert voneinander funktionieren, dann kann man halt die halt auch parallel ausführen und dann halt es halt quasi um den Faktor, wie viele CPUs man halt hat, beschleunigen. Und das ist natürlich auch sehr nett, weil ich meine, ja.

00:40:18.480 --> 00:40:21.000
Und wir haben heute nicht schon ganz, ganz viele CPUs zur Verfügung.

00:40:21.780 --> 00:40:22.500
Genau, ja.

00:40:23.260 --> 00:40:25.300
Ja, es gibt sogar noch ein Ding, Xist oder so,

00:40:25.340 --> 00:40:27.840
mit dem kann man dann halt Sachen noch auf mehrere Rechner verteilen.

00:40:28.120 --> 00:40:29.860
Aber ein Rechner ist ja schon mal nicht so schlecht.

00:40:29.920 --> 00:40:30.720
Wenn man da so acht Cores hat,

00:40:31.040 --> 00:40:32.780
dann geht das schon mal deutlich schneller,

00:40:32.900 --> 00:40:33.940
wenn man die alle verwenden kann.

00:40:34.960 --> 00:40:36.780
Aber wenn man eine große Basis,

00:40:37.000 --> 00:40:39.400
ein Projekt hat mit vielen Tests, Testbasis,

00:40:39.880 --> 00:40:41.300
und die sind nicht unabhängig voneinander,

00:40:41.820 --> 00:40:43.760
dann kann man das mit dem Parallelisieren eigentlich fast vergessen,

00:40:43.860 --> 00:40:45.520
weil das kriegst du halt nicht so einfach umgestellt.

00:40:46.120 --> 00:40:46.480
Ja.

00:40:48.480 --> 00:40:55.180
Ja, genau. Wie ist das? Habt ihr da häufig Probleme mit langlaufenden Tests?

00:40:56.720 --> 00:41:00.560
Wie viele Tests habt ihr denn überhaupt? Bei großen Projekten muss das ja in die Zehntausende gehen.

00:41:01.040 --> 00:41:10.800
Ja, tatsächlich. Also bei unseren langlaufendsten Projekten bin ich nicht mehr aktiv dabei.

00:41:11.920 --> 00:41:23.620
Also bin ich nicht im Dev-Team, das heißt, ich habe da jetzt keine Zahlen, aber ich weiß, dass die Pipelines da teilweise auch Stunden brauchen. Also einfach, weil, also die haben da inzwischen noch Optimierung gemacht.

00:41:23.820 --> 00:41:26.840
Das kommt ja gar nicht nach jedem Feature Release, wenn man da irgendwie Agile irgendwie dran sitzt.

00:41:28.260 --> 00:41:40.080
Natürlich haben wir da jetzt auch Lösungen irgendwie gebaut, dass halt manche Tests laufen dann irgendwie nicht mehr pro Commit oder irgendwie Sachen werden lokal getestet, weil es lokal doch manchmal ein bisschen schneller geht oder es ist eine Parallelisierung.

00:41:41.100 --> 00:42:03.300
Bei dem längsten Projekt, das ich betreue, das ist eine Internet-Software, da habe ich jetzt die 1200, glaube ich, geknackt. Ja, und das ist ganz lustig. Ich hatte da, ja, das waren ungefähr, ja, also in der Pipeline lief das immer so 25 Minuten, die Tests.

00:42:05.940 --> 00:42:08.360
vertretbar ist, aber es hat mich trotzdem immer ein bisschen geärgert

00:42:08.360 --> 00:42:09.860
und

00:42:09.860 --> 00:42:11.560
habe ich irgendwann mal einen Artikel

00:42:11.560 --> 00:42:14.000
auf Medium gefunden, wo jemand meinte,

00:42:14.120 --> 00:42:16.000
ja, wenn man die Tests ganz

00:42:16.000 --> 00:42:17.920
klassisch mit Setup geschrieben hat, dann

00:42:17.920 --> 00:42:19.540
das geht besser,

00:42:19.660 --> 00:42:21.740
weil bei dem Setup, also wir reden jetzt wieder vom

00:42:21.740 --> 00:42:23.680
Django-Unit-Test-Welt und ich glaube, das ist insgesamt

00:42:23.680 --> 00:42:25.900
Unit-Test-Welt, beim Setup ist es halt so,

00:42:25.980 --> 00:42:27.820
dass halt vor jeder Testmethode alles, was im Setup

00:42:27.820 --> 00:42:29.620
steht, ausgeführt wird und es gibt

00:42:29.620 --> 00:42:31.780
eine Klassenmethode,

00:42:31.860 --> 00:42:33.220
die halt quasi nur einmal pro

00:42:33.220 --> 00:42:35.860
Testklasse ausgeführt ist, also hat eine Testklasse

00:42:35.860 --> 00:42:37.760
jetzt hier einen Test, dann wird es halt nur einmal ausgeführt, bei Setup

00:42:37.760 --> 00:42:39.760
wird es jedes Mal ausgeführt und Django hat halt

00:42:39.760 --> 00:42:41.640
so eine magische Funktion, das nennt sich

00:42:41.640 --> 00:42:43.580
SetupTestData und

00:42:43.580 --> 00:42:45.240
da wird es

00:42:45.240 --> 00:42:47.680
in eine Transaction

00:42:47.680 --> 00:42:48.740
gerappt, das heißt

00:42:48.740 --> 00:42:51.440
die Daten werden nur einmal ausgeführt,

00:42:51.640 --> 00:42:53.460
also es ist auch eine ClassMethod, also es ist nur einmal pro Klasse,

00:42:53.880 --> 00:42:55.660
aber die kann man quasi recyceln,

00:42:55.780 --> 00:42:56.440
also bei jedem

00:42:56.440 --> 00:42:59.580
Testaufbau, das heißt man hat so ein bisschen das Beste von beiden

00:42:59.580 --> 00:43:01.760
Welten. Ich habe das dann gelesen, fand das cool

00:43:01.760 --> 00:43:03.460
und dachte, ach mal gucken, was das bringt, habe gedacht,

00:43:03.540 --> 00:43:05.600
1000 Tests, das dauert bestimmt ewig,

00:43:05.600 --> 00:43:26.240
Aber tatsächlich ging es relativ fix. Nach zwei, drei Stunden war ich fertig. Und ja, habe die Pipeline von 25 Minuten auf fünf Minuten gedrückt für die Tests. Und das hat mich halt echt richtig, richtig, richtig überrascht, dass das so viel bringt tatsächlich. Ich meine, klar, wenn man überlegt, dass jede Testklasse vielleicht 20 Tests hat, dann, ja, fünf Tage schneller.

00:43:26.240 --> 00:43:28.400
Da gab es doch jetzt auch genau dieses Buch dazu,

00:43:28.740 --> 00:43:29.900
wie man Django-Tests...

00:43:29.900 --> 00:43:32.200
Ja, von Adam Johnson, jetzt irgendwann im Mai rausgekommen.

00:43:33.040 --> 00:43:34.540
Speed Up Your Django-Tests

00:43:34.540 --> 00:43:35.600
heißt das irgendwie.

00:43:36.360 --> 00:43:37.100
Genau, und

00:43:37.100 --> 00:43:40.260
da, ich habe es nicht ganz

00:43:40.260 --> 00:43:41.920
komplett gelesen, ich habe so ein bisschen, also ich habe es

00:43:41.920 --> 00:43:44.200
auch so ein bisschen quer gelesen schon, aber noch nicht so.

00:43:45.120 --> 00:43:46.380
Ja, da stehen viele, viele

00:43:46.380 --> 00:43:47.780
coole Sachen drin, also auch ganz...

00:43:47.780 --> 00:43:49.800
Das sagt der Jochen erst wieder, weil der ist Glossar noch nicht bis zum letzten Mal.

00:43:49.800 --> 00:43:51.220
Nein, ich habe es wirklich, ich habe

00:43:51.220 --> 00:43:53.860
ein ganzes Kapitel noch gar nicht gelesen.

00:43:53.980 --> 00:43:55.860
Aber da stehen auch viele interessante Dinge drin.

00:43:56.160 --> 00:44:02.520
Also zum Beispiel, dass man halt, ja, also auch im Vergleich Unitest, PyTest zum Beispiel,

00:44:02.620 --> 00:44:05.200
der sagt da halt auch, ja, PyTest ist eigentlich schon cooler.

00:44:05.720 --> 00:44:08.440
Bei vielen Kapiteln steht dran, so, das ist jetzt nur für Unitest relevant,

00:44:08.560 --> 00:44:11.620
bei PyTest muss man das nicht machen, da ist das schon richtig so von Natur aus sozusagen.

00:44:13.820 --> 00:44:16.020
Und der schreibt auch, ja, PyTest ist ein Stück schneller.

00:44:16.760 --> 00:44:22.000
Es ist auch so, wenn man das zum Beispiel, sowohl PyTest wie Unitest geben ja aus, wie lang sie laufen.

00:44:22.560 --> 00:44:24.020
Aber Unitest ist so ein bisschen gemogelt.

00:44:24.020 --> 00:44:46.480
Also viele Sachen kommen da nicht mit rein, da muss man halt, also auf dem Unix schreibt man halt Time davor, um halt zu sehen, wie lange hat es denn wirklich gedauert und tatsächlich die Real Time, wie lange hat das gedauert, ist halt das, was einen eigentlich interessiert und da ist PyTest schon normalerweise ein Stück schneller und bei der reporteten Zeit ist es relativ ähnlich, aber das liegt halt daran, dass PyTest einfach mehr Sachen dazu zählt, zudem, dass halt jetzt so lange hat der Test gedauert.

00:44:48.900 --> 00:45:07.140
Ja, also was er empfiehlt, was man halt am Anfang machen kann, ist, also man sollte erstmal messen, also halt zum Beispiel sich anschauen, was sind denn eigentlich so die langsamsten Tests, die man so hat, weil normalerweise hat man da auch so eine Pareto-Verteilung, dass halt 20% der Tests machen halt 80% der Zeit aus.

00:45:08.620 --> 00:45:21.800
Und mit Pytest geht das einfach so mit Minus-Minus-Durations und dann eine Zahl und dann kriegt man halt die Zahl langsamsten Tests einfach am Schluss ausgegeben und bei Unit-Tests muss man halt irgendwie Django-Slow-Tests installieren oder so.

00:45:22.620 --> 00:45:34.740
Aber damit geht das dann auch und dann den Test-Runner ersetzen und dann kriegt man die halt auch ausgegeben und dann kann man halt bei den Tests halt mit einem Profiler nachgucken, was macht die eigentlich so langsam und dann findet man wahrscheinlich schon Dinge, die man halt verbessern kann.

00:45:35.760 --> 00:45:51.320
Und ja, da gibt es dann auch so Dinge wie, ja, man kann halt, es gibt diverse Tools, mit denen man sich dann, man kann ein C-Profile, kann man Ausgaben an Zeugen, wie man sich dann gucken kann, mit K-Cache-Grind oder, naja gut, muss man sich, da gibt es eine Menge Zeugs.

00:45:53.600 --> 00:46:01.100
Dann gibt es so Easy-Wins, so einfache Dinge, die man halt mal tun kann, um halt die Geschwindigkeit von Tests zu verbessern.

00:46:01.600 --> 00:46:05.940
Und da ist, glaube ich, das Erste, was er schreibt, ist halt den Passwort-Hasher zu ersetzen.

00:46:06.700 --> 00:46:10.400
Das ist halt auch mal so ein Standard, weil man erzeugt halt viele User und so.

00:46:11.200 --> 00:46:18.220
Und die echten Passwort-Hash-Algorithmen sind natürlich extra so designt, dass sie möglichst langsam sind,

00:46:18.360 --> 00:46:22.540
damit man halt nicht viele Hashes durchprobieren kann, weil es einfach zu teuer wäre.

00:46:23.220 --> 00:46:24.960
Das will man jetzt natürlich, wenn man Sachen beschleunigen

00:46:24.960 --> 00:46:26.820
möchte, möchte man nicht. Man möchte es halt aber eher

00:46:26.820 --> 00:46:28.920
schnell haben. Und dann, wenn man dann den MD5

00:46:28.920 --> 00:46:30.500
Hasher nimmt oder so, der ist halt nicht sicher, aber

00:46:30.500 --> 00:46:31.880
der ist halt egal.

00:46:32.460 --> 00:46:34.780
Bei der Test ist es halt egal, weil da kennt man die Passwörter

00:46:34.780 --> 00:46:36.740
ja eh, die man da hasht. Das würde man dann

00:46:36.740 --> 00:46:38.560
über eine Mock-Funktion wahrscheinlich machen, oder?

00:46:38.740 --> 00:46:40.420
Nee, das kann man einstellen. Das ist ein Setting.

00:46:40.900 --> 00:46:42.940
Du kannst die Middleware einfach in den Settings testen.

00:46:43.000 --> 00:46:44.560
Kannst du die Middleware dann einfach...

00:46:44.560 --> 00:46:46.720
Nee, das ist keine Middleware. Du kannst den Passwort

00:46:46.720 --> 00:46:48.480
Hasher setzen. Ja, okay.

00:46:48.920 --> 00:46:50.600
In den Settings. Du sagst dann halt nicht

00:46:50.600 --> 00:46:51.680
Passwort Hasher

00:46:51.680 --> 00:46:54.540
irgendwas von den, importierst halt

00:46:54.540 --> 00:46:56.580
deinen MD5-Password-Hasher oder schreibst halt

00:46:56.580 --> 00:46:58.320
den String zu dem

00:46:58.320 --> 00:47:00.260
Hasher einfach in die Config rein.

00:47:00.720 --> 00:47:02.560
Fertig. Ich meine, rein theoretisch braucht man auch gar keinen

00:47:02.560 --> 00:47:04.560
Password-Hasher. Ich meine, du willst dich ja nicht einloggen in Tests.

00:47:05.380 --> 00:47:06.320
Ja. Ja.

00:47:06.640 --> 00:47:08.480
Ja, keine Ahnung. Ich weiß nicht, es wird halt empfohlen,

00:47:08.540 --> 00:47:09.920
den MD5-Dings zu nehmen. Keine Ahnung, warum.

00:47:10.380 --> 00:47:12.480
Vielleicht hat das auch noch irgendwelche Seiteneffekte. Ich weiß es nicht genau.

00:47:12.600 --> 00:47:14.480
Wenn man jetzt da sagt, gar nichts, ob das irgendwas

00:47:14.480 --> 00:47:16.020
ändert. Ich weiß es nicht.

00:47:16.880 --> 00:47:18.520
Auch noch nicht gemacht. Keine Ahnung.

00:47:19.880 --> 00:47:20.660
Genau, das war so

00:47:20.660 --> 00:47:22.680
das ist so das Erste, was er empfiehlt.

00:47:23.220 --> 00:47:24.740
Dann sagt er sowas wie

00:47:24.740 --> 00:47:26.380
ja, irgendwie

00:47:26.380 --> 00:47:28.580
die, vor allen Tests wird irgendwie

00:47:28.580 --> 00:47:29.940
die Datenbank serialisiert.

00:47:30.380 --> 00:47:32.060
Man kann jetzt an den Datenbank-String ranschreiben,

00:47:32.860 --> 00:47:34.720
also für die Test-Datenbank

00:47:34.720 --> 00:47:36.420
serializable

00:47:36.420 --> 00:47:38.720
Doppelpunkt false oder so, auch eine Config-Option

00:47:38.720 --> 00:47:39.980
und dann wird das halt nicht gemacht.

00:47:40.100 --> 00:47:42.700
Man braucht das eigentlich fast nie. Es gibt ganz selten

00:47:42.700 --> 00:47:44.160
Testfälle, die sowas benötigen, aber

00:47:44.160 --> 00:47:46.020
eigentlich braucht man das nicht und

00:47:46.020 --> 00:47:47.580
macht auch Sachen schneller.

00:47:50.260 --> 00:48:05.580
Und dann, was war da noch drin? Also solche Dinge, wie man kann, das kannte ich gar nicht. Also das war mir neu. Ich habe tatsächlich, oder ich weiß nicht, wie du das machst mit Files, wenn du halt irgendwelche Bilddaten oder so testest oder so, da hat man ja auch viel mit Files zu tun.

00:48:07.680 --> 00:48:30.300
Ich hatte zum Beispiel immer das Problem, dass dann halt viele Files einfach noch am Schluss rumgelegen sind und dann habe ich halt irgendwelche Dinger geschrieben, nicht Clean-up-Scripts, sondern halt schon das quasi so mit in die, ich habe dann das in Dekoratoren reingeschrieben und dann halt die Testklassen dekoriert und die haben dann hinterher quasi das Media-Root wieder aufgeräumt oder so.

00:48:31.100 --> 00:48:32.680
Ich weiß gar nicht mehr genau, wie ich das gemacht habe.

00:48:33.200 --> 00:48:34.760
Aber auf jeden Fall habe ich da halt irgendwie

00:48:34.760 --> 00:48:36.700
Aufwand reingesteckt und dachte so, das war ätzend.

00:48:37.320 --> 00:48:37.860
Und es gibt

00:48:37.860 --> 00:48:40.900
DJ-In-Memory-Storage, heißt das Paket,

00:48:41.020 --> 00:48:43.200
glaube ich. Und da kann man

00:48:43.200 --> 00:48:45.000
das Default-Storage

00:48:45.000 --> 00:48:47.560
ersetzen durch halt In-Memory-Storage.

00:48:47.980 --> 00:48:49.160
Und dann wird überhaupt nichts gespeichert.

00:48:49.260 --> 00:48:50.600
Und das ist halt viel schneller, weil es ist halt In-Memory.

00:48:51.000 --> 00:48:52.780
Es funktioniert halt genauso, aber

00:48:52.780 --> 00:48:54.600
es landet hinterher gar nichts auf der Platte.

00:48:54.680 --> 00:48:55.640
Und wenn man viel mit Files macht,

00:48:56.700 --> 00:48:58.700
dann ist es halt sofort deutlich schneller.

00:49:00.200 --> 00:49:00.360
Ja,

00:49:00.740 --> 00:49:02.340
Das fand ich echt gut.

00:49:03.200 --> 00:49:04.600
Das ist sehr praktisch.

00:49:05.360 --> 00:49:07.020
Dann gab es noch so

00:49:07.020 --> 00:49:08.780
Celery-Optimierungen. Da kann man auch

00:49:08.780 --> 00:49:10.340
ein Memory-Backend verwenden.

00:49:12.320 --> 00:49:13.160
Und naja, man muss halt

00:49:13.160 --> 00:49:15.040
gucken, dass man halt

00:49:15.040 --> 00:49:17.080
Always-Eager auf True setzt und

00:49:17.080 --> 00:49:18.980
auch noch irgendwas anderes, weiß ich nicht mehr genau.

00:49:20.240 --> 00:49:21.080
Ja, sowieso

00:49:21.080 --> 00:49:23.660
diese ganzen Async-Task-Dinger.

00:49:24.200 --> 00:49:25.580
Da gibt es dann halt Jungle-Queue.

00:49:25.840 --> 00:49:27.120
Das will ich mir mal angucken. Celery habe ich

00:49:27.120 --> 00:49:28.140
letztens wieder. Ah, Celery!

00:49:28.840 --> 00:49:29.460
Ja, genau.

00:49:30.740 --> 00:49:34.160
euch vielleicht auch, mich hat es auf jeden Fall

00:49:34.160 --> 00:49:36.200
vor ein paar Tagen ein bisschen mal wieder

00:49:36.200 --> 00:49:38.100
als ich irgendwie

00:49:38.100 --> 00:49:38.920
dachte so, irgendwie

00:49:38.920 --> 00:49:41.220
seltsam ruhig hier so alles

00:49:41.220 --> 00:49:44.240
irgendwie, passiert da zu wenig

00:49:44.240 --> 00:49:46.080
auf dem Produktionssystem, wie kommt denn das

00:49:46.080 --> 00:49:47.120
und ich hatte gerade irgendwie released

00:49:47.120 --> 00:49:50.080
und guckte dann halt so in die Logfile und denke so

00:49:50.080 --> 00:49:51.800
was ist mit den ganzen Sanitars

00:49:51.800 --> 00:49:53.500
warum, wie, wo sind die

00:49:53.500 --> 00:49:55.180
wieso, was

00:49:55.180 --> 00:49:57.880
warum werden da keine Sanitars mehr ausgeführt

00:49:57.880 --> 00:49:59.680
und dann habt ihr so ein bisschen gegoogelt

00:49:59.680 --> 00:50:01.680
und dann ja, ich glaube 4.4.7 war das

00:50:01.680 --> 00:50:03.060
oder so, hat irgendeine Regression,

00:50:03.280 --> 00:50:05.280
böse Regression drin gehabt, dass halt die

00:50:05.280 --> 00:50:07.560
Celery Broker URL

00:50:07.560 --> 00:50:09.180
oder so aus den Settings nicht mehr benutzt wird.

00:50:10.140 --> 00:50:10.980
Und ja,

00:50:11.340 --> 00:50:13.840
ich weiß nicht, wie viele Produktionssysteme das weltweit gebrochen hat.

00:50:14.040 --> 00:50:14.960
Es dürften viele gewesen sein.

00:50:16.200 --> 00:50:17.320
Ja, ein netter Change, ja.

00:50:17.320 --> 00:50:19.140
Ja, und dann habe ich wieder

00:50:19.140 --> 00:50:21.380
Downgraded auf 4.4.6 oder sowas und dann war es wieder okay.

00:50:21.540 --> 00:50:23.340
Aber so, wow, okay.

00:50:23.580 --> 00:50:25.460
Das war schon, hm, naja.

00:50:25.780 --> 00:50:27.080
Ich muss mir mal Jungle Q angucken.

00:50:27.880 --> 00:50:31.800
Eine Sache,

00:50:32.420 --> 00:50:34.280
die eigentlich

00:50:34.280 --> 00:50:36.360
total selbstverständlich ist,

00:50:36.500 --> 00:50:38.480
die ich aber für mich persönlich erst relativ spät

00:50:38.480 --> 00:50:39.760
erkannt habe, ist,

00:50:40.560 --> 00:50:42.320
wenn man, also man hat

00:50:42.320 --> 00:50:44.200
eine Funktion, also man hat einen Service, man hat

00:50:44.200 --> 00:50:46.560
eine höherlevelige Funktion,

00:50:46.640 --> 00:50:48.440
die man testen möchte. Und darunter laufen

00:50:48.440 --> 00:50:50.320
auch andere Sachen, zum Beispiel, es können jetzt API-Calls

00:50:50.320 --> 00:50:52.380
sein, da kam ich jetzt gerade drauf, wegen diesen externen

00:50:52.380 --> 00:50:54.380
Sachen mit den Files, aber auch andere Sachen,

00:50:54.480 --> 00:50:55.620
die tendenziell auch länger laufen.

00:50:56.460 --> 00:51:11.540
Und wenn man den Aufruf der unterliegenden Funktion einfach mockt, dann spart man natürlich einen ganzen Laufen Zeit, weil der halt dann nicht versucht, eine API anzusprechen, weil man irgendwie die API mocken muss oder keine Ahnung was, sondern man sagt einfach, das Ding gibt 27 zurück und gut ist.

00:51:12.640 --> 00:51:18.120
Und auf der anderen Seite werden die Tests natürlich auch deutlich besser, weil man isoliert nun den Teil testet, den man eigentlich testen möchte.

00:51:18.320 --> 00:51:24.320
Also du musst jetzt einmal noch kurz, einmal musst du ganz kurz erklären, was überhaupt Services sind, vielleicht für alle Menschen, die das noch nicht so benutzt haben.

00:51:24.320 --> 00:51:49.020
Okay. Also Django hat von sich aus ja keinen, bringt da keinen Pattern mit, wo man Logik hinpackt. Ja, es gibt Manager für Datenbank-Querys, es gibt Models, es gibt Views, aber wenn man jetzt einfach Logik bauen möchte, die irgendwas tut, also die irgendwie ein CSV generiert, Daten verarbeitet, dafür gibt es halt offiziell nichts, wo man das hinpacken kann.

00:51:49.020 --> 00:51:50.120
U-Tilt, Helpers.

00:51:51.200 --> 00:51:53.480
Nee, U-Tilt, immer wenn du

00:51:53.480 --> 00:51:54.800
ein Modul hast, das U-Tilt heißt.

00:51:55.820 --> 00:51:57.520
Das ist schon so ein...

00:51:57.520 --> 00:51:58.700
Tatsächlich auf der

00:51:58.700 --> 00:52:01.560
Kopenhagener DjangoCon letztes Jahr.

00:52:01.720 --> 00:52:03.360
Jetzt muss ich meine ganze Applikation

00:52:03.360 --> 00:52:04.360
refactoren, das weißt du.

00:52:05.640 --> 00:52:07.460
Ich weiß, ich habe selber solche,

00:52:07.740 --> 00:52:09.940
aber eigentlich ist das keine gute Idee.

00:52:10.400 --> 00:52:11.360
Weil das Problem ist halt,

00:52:11.580 --> 00:52:13.600
naja, was sagt dir das, wenn du

00:52:13.600 --> 00:52:16.120
bei irgendjemandem siehst, da liegt halt ein U-Tilt-Modul

00:52:16.120 --> 00:52:17.300
rum, was ist da drin?

00:52:17.940 --> 00:52:19.140
Ja, das ist wirklich Unsinn.

00:52:19.520 --> 00:52:20.220
Ja, weißt du halt nicht.

00:52:20.460 --> 00:52:23.300
Aber das ist eigentlich gar nicht so gut, wenn du da zack rumliegst und weißt nicht, was das ist.

00:52:23.880 --> 00:52:27.880
Tatsächlich gab es da auch einen Vortrag auf der letzten JungleCon in Kopenhagen,

00:52:27.960 --> 00:52:30.180
wo dann auch ein paar Franzosen, glaube ich, drüber geredet haben,

00:52:30.560 --> 00:52:33.640
dass sie halt das Konzept vermissen, dass das nicht offiziell in der Doku drinsteht.

00:52:33.700 --> 00:52:34.280
Macht das so.

00:52:34.720 --> 00:52:37.360
Weil es halt sehr viele Leute so machen, dass man einfach eine Klasse anlegt,

00:52:37.440 --> 00:52:39.100
die kann man dann einsortieren, die kann man sinnvoll benennen.

00:52:40.600 --> 00:52:44.560
Und dass man da dann halt seinen Code halt irgendwo sinnvoll parken kann.

00:52:45.500 --> 00:52:47.660
dann auch, ich meine, das ist halt so eine Art

00:52:47.660 --> 00:52:49.420
Best Practice, das ist halt kein offizielles Django-Pattern, aber

00:52:49.420 --> 00:52:51.340
ich glaube, das gilt inzwischen als Best Practice.

00:52:52.460 --> 00:52:53.620
Korrigiere mich, wenn du es anders siehst,

00:52:53.700 --> 00:52:54.840
aber... Nee, ich

00:52:54.840 --> 00:52:57.460
weiß, hörst du es nicht, ich weiß

00:52:57.460 --> 00:52:59.500
jetzt, das ist aber nicht diese Geschichte, wo

00:52:59.500 --> 00:53:01.340
irgendwelche Leute versucht haben, den ORM so

00:53:01.340 --> 00:53:02.820
ein bisschen wegzuabstrahieren.

00:53:03.360 --> 00:53:05.620
Ich glaube nicht. Genau, auch auf Django News,

00:53:05.680 --> 00:53:06.640
die haben auch da Werbung gemacht,

00:53:08.180 --> 00:53:09.640
die haben das auch irgendwie Services genannt,

00:53:09.720 --> 00:53:11.560
aber ich glaube, das war was anderes. Es ging, das war

00:53:11.560 --> 00:53:13.360
dieses Projekt, irgendwie Maintaining a Django Project

00:53:13.360 --> 00:53:15.420
over 10.000 Commits oder sowas hieß das.

00:53:15.500 --> 00:53:17.900
die hatten so ein paar ketzerische Ideen, die wollten absichtlich

00:53:17.900 --> 00:53:19.880
ein bisschen Unruhe stiften, glaube ich, im positiven

00:53:19.880 --> 00:53:21.860
Sinne. Ja, ist ja gut.

00:53:22.380 --> 00:53:23.380
Muss ich mir, glaube ich, mal angucken.

00:53:23.760 --> 00:53:25.700
Kenn ich gar nicht. Ja, also wie gesagt, waren halt

00:53:25.700 --> 00:53:27.420
so ein paar ketzerische Ideen, die waren dann auch

00:53:27.420 --> 00:53:29.580
und meinten dann so, sie nutzen eigentlich gar keine Packages

00:53:29.580 --> 00:53:31.480
mehr, weil wenn das Projekt so lange läuft, hast du

00:53:31.480 --> 00:53:33.620
früher oder später immer Scherereien und sowas. Wie gesagt,

00:53:33.720 --> 00:53:35.680
die waren da gebrannte

00:53:35.680 --> 00:53:37.020
Kinder auf jeden Fall, das hat man gemerkt.

00:53:38.680 --> 00:53:39.680
Aber wie gesagt, die haben halt dann

00:53:39.680 --> 00:53:41.100
auch, ich habe nachher im Nachgang auch mit denen

00:53:41.100 --> 00:53:43.300
gesprochen und die meinten halt auch, dass

00:53:43.300 --> 00:53:45.720
die das halt sehr cool fänden, wenn dieses Django-Dinge

00:53:45.720 --> 00:53:47.740
in die Django-Doku reinkommen würde, das mit den Services.

00:53:48.640 --> 00:53:49.740
Einfach, dass dann halt auch

00:53:49.740 --> 00:53:51.680
Newbies, die halt vielleicht nicht so genau wissen, wie es mir

00:53:51.680 --> 00:53:53.540
damals auch ging, ich wusste auch nicht, wie ich das mache. Ich habe auch mit

00:53:53.540 --> 00:53:55.560
Utils angefangen und hatte dann immer ein ziemliches Chaos

00:53:55.560 --> 00:53:57.520
überall rum. Core-App und

00:53:57.520 --> 00:53:59.780
Utils. Ja, Core-App ist auch, ja.

00:54:01.480 --> 00:54:01.800
Genau.

00:54:02.900 --> 00:54:03.620
Ja, das

00:54:03.620 --> 00:54:05.720
zu Services. Ja, und du hast gesagt, die kann man

00:54:05.720 --> 00:54:07.660
mocken oder die will man mocken oder wann möchte man

00:54:07.660 --> 00:54:09.520
das? Genau, also es gibt ja beim

00:54:09.520 --> 00:54:11.800
Testing kann man ja alles mögliche

00:54:11.800 --> 00:54:17.160
Also man kann die aktuelle Zeit mocken, was ja praktisch ist. Also einfach sagen, heute ist nicht heute, sondern irgendwann anders.

00:54:17.240 --> 00:54:17.640
Montag.

00:54:18.280 --> 00:54:36.200
Genau. Und man kann aber auch ein Mockblock verwenden. Das heißt, man kann einfach dann sagen, alles, was in diesem Mockblock passiert, wenn da eine bestimmte Funktion aufgerufen wird, füllt ihr die nicht aus, sondern gibt einen festen Wert zurück.

00:54:36.200 --> 00:54:42.420
Zum Beispiel, wenn man eine Funktion hat, Load-Data vom API oder sowas, kann man einfach sagen, das gibt ein fixes JSON zurück.

00:54:42.820 --> 00:54:44.180
Ein Mock-Block. Schön.

00:54:45.360 --> 00:54:46.380
Ja, sagt man, oder?

00:54:49.540 --> 00:55:03.340
Und wie gesagt, wenn man das Mocking einmal gesehen hat, ist es eigentlich total offensichtlich, aber ich habe halt irgendwie nie so realisiert oder lange nicht realisiert, dass es halt einerseits total viel Zeit sparen kann und andererseits auch noch deinen Test-Code verbessert.

00:55:03.340 --> 00:55:18.060
Weil dadurch, dass halt die unterliegenden Funktionen einen festen Rückgabewert haben, wenn da jetzt ein Fehler drin ist, dann tangiert das halt nicht die anderen Sachen, sondern die Umwandlungsfunktionen, die ja hoffentlich auch getestet sind, fehlen dann isoliert und man hat dann nachher nicht irgendwie 50 gefehlte Tests.

00:55:18.060 --> 00:55:34.620
Man muss erstmal anfangen zu suchen, sondern im Optimalfall, wenn alles isoliert genug ist, fällt genau der Test ja nicht mehr, das bringt, was er möchte. Und diesen Doppel-Win, das fand ich echt ziemlich neat, das nochmal so zu realisieren.

00:55:37.880 --> 00:55:40.140
Ja, klingt gut. Also ich packe meistens

00:55:40.140 --> 00:55:42.100
meine Logik irgendwie so in

00:55:42.100 --> 00:55:44.360
den Model-Layer, mehr oder weniger.

00:55:45.080 --> 00:55:46.500
Erdmodels, nennt man das.

00:55:46.520 --> 00:55:48.420
Genau, oder beziehungsweise dann halt in Mixins,

00:55:48.420 --> 00:55:50.520
die dann halt

00:55:50.520 --> 00:55:51.720
irgendwie... Die Models aufblähen.

00:55:52.460 --> 00:55:54.460
Ja, die ich dann auch oft, wenn es dann zu lang

00:55:54.460 --> 00:55:56.320
wird, stecke ich halt in andere Files und importiere die

00:55:56.320 --> 00:55:58.040
dann aus Models.py, dann halt da rein und

00:55:58.040 --> 00:55:59.820
genau, aber ja,

00:56:00.320 --> 00:56:02.220
ja, ich weiß auch noch nicht so genau. Ich muss mir

00:56:02.220 --> 00:56:03.500
den Vortrag angucken.

00:56:04.460 --> 00:56:04.820
Genau.

00:56:06.180 --> 00:56:07.560
Es gibt verschiedene Meinungen dazu, glaube ich, ja.

00:56:07.700 --> 00:56:08.780
Ja, definitiv.

00:56:09.160 --> 00:56:09.820
Das ist wahrscheinlich auch der Grund,

00:56:09.900 --> 00:56:11.300
warum das noch nicht in der Dango-Doku gelandet ist.

00:56:11.500 --> 00:56:12.440
Ja, bei TwoScoops sagt er auch,

00:56:12.520 --> 00:56:13.780
das ist total katastrophal für Fat Models,

00:56:13.820 --> 00:56:14.980
aber ich finde das eigentlich auch gar nicht so schlecht,

00:56:15.120 --> 00:56:16.240
weil ich es bei Jochen gesehen habe natürlich,

00:56:16.840 --> 00:56:19.000
dass man da viele gute Dinge reinpackt,

00:56:19.060 --> 00:56:19.960
die halt da hingehören irgendwie.

00:56:20.460 --> 00:56:22.640
So vom Gefühl her machen die halt Sachen mit der Datenbank oder so.

00:56:23.380 --> 00:56:23.480
Ja.

00:56:23.480 --> 00:56:24.880
Vielleicht sind sie dann am Modeln.

00:56:24.880 --> 00:56:25.560
Ich mag das auch.

00:56:25.680 --> 00:56:27.000
Also ich würde es nicht sagen,

00:56:27.080 --> 00:56:28.300
ich mache jetzt, da ist alles dran,

00:56:28.300 --> 00:56:30.060
weil wie gesagt, ich finde das Service-Prinzip ganz nett

00:56:30.060 --> 00:56:32.180
und mag das auch ganz gern,

00:56:32.340 --> 00:56:35.660
aber die sind auf jeden Fall nicht dünn, die Models, die ich baue.

00:56:37.520 --> 00:56:37.840
Ja.

00:56:39.280 --> 00:56:41.180
Ja, aber wir hatten noch mal ganz kurz über das Mocken geredet.

00:56:41.280 --> 00:56:43.560
Und ich glaube, Mocken ist auch etwas, was noch sehr interessant ist.

00:56:44.260 --> 00:56:46.660
Weil man kann natürlich alles mocken und so tun,

00:56:46.720 --> 00:56:47.980
als gäbe es irgendeine Umgebung.

00:56:48.420 --> 00:56:50.500
Und dann da testen, ob dann das, was man so geschrieben hat,

00:56:50.560 --> 00:56:52.280
für diese isolierte Umgebung dann funktioniert.

00:56:52.480 --> 00:56:54.220
Ja, und dann funktioniert es in der Realität nicht mehr,

00:56:54.280 --> 00:56:55.780
weil der Mock halt anders aussieht als die Realität.

00:56:55.900 --> 00:56:56.560
Das ist halt, ja.

00:56:56.860 --> 00:56:58.140
Ja, genau. Und vielleicht ist das eines der Probleme.

00:56:58.280 --> 00:56:59.760
Also ich habe das schon öfter mal mitbekommen,

00:56:59.820 --> 00:57:01.720
dass gerade Menschen, die irgendwie viel Coverage erreichen wollen,

00:57:01.800 --> 00:57:03.500
irgendwie sich dann mit vielen moxt und

00:57:03.500 --> 00:57:06.040
also es gab sogar Menschen, die haben sich dann Screenshots

00:57:06.040 --> 00:57:07.460
von den Webseiten irgendwie

00:57:07.460 --> 00:57:10.020
besorgt und dann geguckt, ob die

00:57:10.020 --> 00:57:11.940
dann am Ende genauso aussieht, weil sie dann irgendwie Templates

00:57:11.940 --> 00:57:13.780
noch versucht haben zu generieren und

00:57:13.780 --> 00:57:16.000
dann die Bilder miteinander verglichen

00:57:16.000 --> 00:57:17.660
und solche Sachen, also wirklich

00:57:17.660 --> 00:57:18.520
abgefahrener Quatsch.

00:57:19.760 --> 00:57:22.040
Ja, mockt ihr überhaupt irgendwas

00:57:22.040 --> 00:57:23.820
oder findest du anstrengend oder

00:57:23.820 --> 00:57:25.040
wann macht man das?

00:57:25.540 --> 00:57:27.320
Ich benutze das

00:57:27.320 --> 00:57:29.640
sehr häufig und

00:57:29.640 --> 00:57:31.660
muss man auch, denke ich, also gerade wenn man

00:57:31.660 --> 00:57:34.280
irgendwie APIs fragt oder so, mit externen

00:57:34.280 --> 00:57:35.880
sonstigen Systemen redet, dann geht das ja quasi

00:57:35.880 --> 00:57:38.020
gar nicht anders. Das heißt, du hast externen Antworten

00:57:38.020 --> 00:57:39.940
von Dingen, die du nicht im Test eigentlich abbilden

00:57:39.940 --> 00:57:41.100
kannst, die musst du dann tatsächlich emulieren.

00:57:41.100 --> 00:57:43.980
Die muss man nicht immer bocken, denke ich, das geht gar nicht anders.

00:57:44.160 --> 00:57:45.760
Ja gut, das sind Abfragen von externen APIs,

00:57:45.920 --> 00:57:47.520
kann man sich tatsächlich vorstellen, dass das sinnhaft ist.

00:57:48.460 --> 00:57:50.140
Ich mache es tatsächlich bei Daten

00:57:50.140 --> 00:57:51.820
enorm viel, weil das halt einfach,

00:57:52.180 --> 00:57:53.760
also das ist nicht schlimmer, als wenn du irgendwie

00:57:53.760 --> 00:57:55.700
am Freitag einen Test ausführst und plötzlich geht er nicht mehr.

00:57:55.740 --> 00:57:57.620
Was sind Daten? Also Datums.

00:57:58.280 --> 00:58:00.060
Ja, ja, okay, das ist ein bisschen

00:58:00.060 --> 00:58:00.740
schwierig im Deutschen.

00:58:01.660 --> 00:58:19.760
Aber also wirklich irgendwelche Zeiten, das ist total super. Man kann auch mit diesem, also das heißt Freescan, das Tool, mit dem man das machen kann und da kann man halt auch einen Block machen, also sprich alles, was eingerückt unter diesem With-Tag ist, kriegt dann einen anderen Timestamp, was halt sehr praktisch ist.

00:58:19.760 --> 00:58:21.480
man kann das als Decorator verwenden, zum Beispiel sagen,

00:58:21.580 --> 00:58:23.220
heute ist der 26.06.

00:58:24.720 --> 00:58:25.820
Obwohl das, also egal,

00:58:25.920 --> 00:58:27.700
wann der Test läuft. Und wenn man jetzt aber zum Beispiel

00:58:27.700 --> 00:58:29.520
sagt, ich möchte jetzt aber Objekte erstellen mit

00:58:29.520 --> 00:58:30.480
einem bestimmten Timestamp,

00:58:31.480 --> 00:58:33.000
dann

00:58:33.000 --> 00:58:35.720
kann ich halt das

00:58:35.720 --> 00:58:37.720
in diesem Whiz-Tag machen, obwohl der ganze Test

00:58:37.720 --> 00:58:40.080
sagt, ich bin am 26.06.,

00:58:40.080 --> 00:58:41.740
kann ich dann trotzdem sagen, dieses Objekt

00:58:41.740 --> 00:58:43.940
ist aber schon zwei Jahre alt. Das ist halt ziemlich praktisch.

00:58:44.000 --> 00:58:45.840
Wenn man da so zwei, drei Dinge verstanden hat,

00:58:45.840 --> 00:58:47.460
dann kann man sich das Leben sehr leicht machen.

00:58:48.260 --> 00:58:59.680
Ansonsten das Mocken nutze ich viel weniger, als man es wahrscheinlich sollte. Ich nutze es halt für APIs, also für externe Sachen, die ich halt mocken muss auf Unit- oder Functional-Test-Ebenen.

00:58:59.700 --> 00:59:19.940
Und ansonsten, wenn ich halt eine Funktion habe, die halt sehr lange läuft, wo ich halt weiß, ich will die nicht jedes Mal durchjubeln auf allen höheren Ebenen, weil mir das einfach zu lange dauert. Aber wahrscheinlich wäre es sinnvoll, das mehr zu machen. Obwohl natürlich du auch vollkommen recht hast, umso mehr man sich irgendwie da seine Fantasiewelt aufbaut, umso weiter weg bist du doch irgendwann natürlich von der Realität.

00:59:23.680 --> 00:59:25.120
Ja, also User-Input oder sowas,

00:59:25.160 --> 00:59:26.820
das kann man ja auch ins Frontend weiterdenken, was man

00:59:26.820 --> 00:59:29.120
irgendwie alles dann mocken kann. Habt ihr viel Frontend

00:59:29.120 --> 00:59:31.200
schon getestet? Was gibt's da alles? Beispielsweise Mocha

00:59:31.200 --> 00:59:33.320
und... Nee, nicht wirklich

00:59:33.320 --> 00:59:33.980
viel, ja.

00:59:34.840 --> 00:59:37.180
So Unit-Tests im Frontend, das ist ja

00:59:37.180 --> 00:59:39.000
glaube ich, hat sich inzwischen so Jest als der

00:59:39.000 --> 00:59:40.200
Standard etabliert, so ein bisschen.

00:59:41.140 --> 00:59:42.900
Reden wir jetzt von JavaScript oder reden wir von

00:59:42.900 --> 00:59:44.760
normalen Django-Templaten?

00:59:44.920 --> 00:59:45.440
Zum Beispiel JavaScript.

00:59:46.260 --> 00:59:48.620
Ich bin bei Frontend da direkt immer schon bei JavaScript.

00:59:48.780 --> 00:59:50.680
Ja, ja, eh, aber... Ja, leider, leider.

00:59:50.680 --> 00:59:52.460
Ja, das ist ja kurz von der Python-Welt aus,

00:59:52.520 --> 00:59:53.900
aber vielleicht ist ein Tester das selbe Thema.

00:59:55.580 --> 00:59:56.560
Ja, meintest du denn

00:59:56.560 --> 00:59:57.980
Django-Templates-Tests?

00:59:58.400 --> 01:00:00.480
Nein, ich meine tatsächlich die JavaScript-Mutter

01:00:00.480 --> 01:00:02.560
und was man da alles so bauen kann.

01:00:02.980 --> 01:00:04.440
Ja, also ich würde sagen,

01:00:04.500 --> 01:00:05.960
da gibt es halt eben den Unterschied zwischen

01:00:05.960 --> 01:00:08.320
End-to-End-Tests, also Cypress oder weiß ich nicht,

01:00:08.360 --> 01:00:09.580
was Leute da noch verwenden, Selenium.

01:00:09.600 --> 01:00:11.680
Da ist wohl die neue Version heute rausgekommen, habe ich gelesen.

01:00:13.020 --> 01:00:14.800
Ah ja, habe ich gar nicht mitbekommen, ja.

01:00:15.640 --> 01:00:15.900
Cool.

01:00:17.200 --> 01:00:18.620
Ja, und ich habe so ein bisschen

01:00:18.620 --> 01:00:20.540
was damit gemacht, aber noch nicht so wahnsinnig viel.

01:00:21.760 --> 01:00:22.940
Muss man da mehr mocken?

01:00:25.300 --> 01:00:26.440
Nö, eigentlich nicht.

01:00:27.500 --> 01:00:28.440
Ja gut, ich meine, ja.

01:00:32.440 --> 01:00:34.940
Aber ich habe da auch nicht so wahnsinnig viel Erfahrung.

01:00:37.540 --> 01:00:38.560
Meistens auf der Django-Seite.

01:00:39.520 --> 01:00:40.640
Ja, also entweder braucht man halt gute,

01:00:40.800 --> 01:00:43.180
richtig gut funktionierende Apps schon von sich aus,

01:00:43.280 --> 01:00:44.840
oder man braucht halt Tests.

01:00:49.040 --> 01:00:51.200
Ja, man kann halt auch tatsächlich andersrum anfangen

01:00:51.200 --> 01:00:52.980
und kann sagen, man baut zuerst seine

01:00:52.980 --> 01:00:55.120
Tests. Das nennt man dann Test-Driven

01:00:55.120 --> 01:00:57.200
Development. Und wenn man erst die Tests hat,

01:00:57.500 --> 01:00:59.140
die alle verschiebt gehen, dann den Code baut,

01:01:00.000 --> 01:01:01.120
was haltet ihr denn davon? Also vielleicht

01:01:01.120 --> 01:01:02.860
für mich, ich finde das immer sehr verwirrend,

01:01:03.420 --> 01:01:04.200
sowas zu tun, weil

01:01:04.200 --> 01:01:06.960
um das zu tun, also erst Tests zu bauen, dann müsste ich

01:01:06.960 --> 01:01:08.720
erstmal wissen, was meine Anwendung überhaupt machen soll

01:01:08.720 --> 01:01:11.100
oder macht, um dann Tests bauen zu können,

01:01:11.180 --> 01:01:12.940
wo die dann diese hypothetische Anwendung irgendwie

01:01:12.940 --> 01:01:14.960
stimmen können. Und das alleine ist schon ziemlich

01:01:14.960 --> 01:01:15.720
herausfordernd, finde ich.

01:01:18.400 --> 01:01:18.760
Ja.

01:01:20.500 --> 01:01:35.080
Ehrlich gesagt, ich habe das noch nie so wirklich probiert, weil ich immer dachte, ich muss das vielleicht mal machen, tatsächlich mal versuchen, wie es ist, testdriven zu entwickeln. Aber ja, da ist die Idee ja im Grunde, dass du genau erst immer den Test schreibst und dann erst den Code.

01:01:35.080 --> 01:01:37.000
man hört dann halt auf, wenn der Test

01:01:37.000 --> 01:01:39.060
funktioniert, aber

01:01:39.060 --> 01:01:41.360
also gerade auch bei Django

01:01:41.360 --> 01:01:43.040
ich fange meistens, wenn ich

01:01:43.040 --> 01:01:45.300
anfange irgendwas zu schreiben

01:01:45.300 --> 01:01:47.340
schreibe ich erstmal das in einem Jupyter Notebook

01:01:47.340 --> 01:01:48.740
weil

01:01:48.740 --> 01:01:50.760
genau, also da gibt es halt

01:01:50.760 --> 01:01:53.380
die Django Shell Plus

01:01:53.380 --> 01:01:54.780
zum Beispiel, den Django Extensions

01:01:54.780 --> 01:01:57.120
wo man halt die ganzen Modelle schon drin hat

01:01:57.120 --> 01:01:58.540
sozusagen, das gibt es halt auch

01:01:58.540 --> 01:02:01.480
in der Jupyter Frontend

01:02:01.480 --> 01:02:03.340
und man hat dann

01:02:03.340 --> 01:02:05.200
quasi so eine Umgebung wie in der Shell Plus,

01:02:05.360 --> 01:02:07.280
bloß halt mit dem ganzen anderen Jupyter-Kram

01:02:07.280 --> 01:02:09.180
drumherum. Genau, man kann halt die ganzen Zellen immer wieder ausführen.

01:02:09.320 --> 01:02:11.300
Genau, dann probiere ich halt so lange rum,

01:02:11.460 --> 01:02:13.340
bis ich weiß, dass es ungefähr das tut, was ich

01:02:13.340 --> 01:02:13.880
gerne hätte.

01:02:15.240 --> 01:02:17.440
Das ist super, gerade wenn man so Funktionen machen möchte,

01:02:17.540 --> 01:02:19.820
die Modellsachen machen.

01:02:19.820 --> 01:02:21.420
Ja, weil oft Sachen muss man halt irgendwie ausprobieren.

01:02:21.840 --> 01:02:23.500
Das geht nicht, dann muss man es irgendwie anders machen

01:02:23.500 --> 01:02:25.400
und dann, und damit

01:02:25.400 --> 01:02:27.180
geht das eigentlich tatsächlich sehr, sehr

01:02:27.180 --> 01:02:29.500
schön, während man halt,

01:02:29.580 --> 01:02:31.340
wenn man jetzt das tatsächlich direkt in Code schreiben würde,

01:02:31.880 --> 01:02:33.340
müsste man das immer irgendwie ausführen.

01:02:33.680 --> 01:02:35.840
Man müsste jetzt erstmal an die Stelle kommen, wo das dann ausgeführt wird.

01:02:36.200 --> 01:02:37.580
Und das ist halt immer ein bisschen

01:02:37.580 --> 01:02:39.640
schwieriger. Und

01:02:39.640 --> 01:02:41.640
im Notebook hast du das halt, da änderst du

01:02:41.640 --> 01:02:43.600
dann deinen Code, führst nochmal die Zelle aus und weißt dann,

01:02:43.680 --> 01:02:45.660
okay, ah, jetzt passt's. Und dann, also

01:02:45.660 --> 01:02:47.340
meistens, also da fange ich an,

01:02:47.560 --> 01:02:49.280
Sachen zu basteln. Und wenn das dann halt so halbwegs

01:02:49.280 --> 01:02:51.700
passt, dann überführe ich

01:02:51.700 --> 01:02:52.320
es halt in

01:02:52.320 --> 01:02:55.660
tatsächlich Django-App-Code

01:02:55.660 --> 01:02:57.600
irgendwo. Und dann fange ich meistens dann auch

01:02:57.600 --> 01:02:59.480
Tests zu schreiben. Manchmal

01:02:59.480 --> 01:03:01.540
stelle ich dann noch was um, weil es

01:03:01.540 --> 01:03:04.080
einfacher ist zu testen oder so, aber

01:03:04.080 --> 01:03:06.100
oft ist es dann auch mehr oder weniger schon so fertig.

01:03:06.360 --> 01:03:08.220
Das heißt, das Test-Driven ist quasi

01:03:08.220 --> 01:03:10.060
gar nicht erst Testschreiben

01:03:10.060 --> 01:03:12.540
bei dir, sondern eher so Experimente

01:03:12.540 --> 01:03:13.900
machen in so einem Notebook,

01:03:14.260 --> 01:03:16.060
die halt so lange durchgehen, bis du halt was

01:03:16.060 --> 01:03:17.500
gerade getrunken hast. Also das ist so ein bisschen

01:03:17.500 --> 01:03:19.900
Learning by Doing oder man könnte es auch sagen,

01:03:20.220 --> 01:03:21.840
ausprobieren

01:03:21.840 --> 01:03:24.200
und bis jetzt irgendwas

01:03:24.200 --> 01:03:26.160
funktioniert, aber ich sage mal, in Notebooks ist

01:03:26.160 --> 01:03:27.880
diese Iterationsschleife relativ kurz.

01:03:27.900 --> 01:03:30.060
Relativ kurz, das ist der große Vorteil

01:03:30.060 --> 01:03:31.660
Ich kenne es halt aus dem Data-Science-Bereich so.

01:03:32.820 --> 01:03:34.120
Und ich weiß nicht, ob das,

01:03:34.380 --> 01:03:36.000
ich meine, diese Art, das so zu machen,

01:03:36.220 --> 01:03:38.260
gab es halt vorher auch, glaube ich, so noch gar nicht.

01:03:39.360 --> 01:03:40.160
Ja, das Pile-and-Error

01:03:40.160 --> 01:03:42.240
wird halt einfach dann unheimlich viel schneller.

01:03:43.040 --> 01:03:43.600
Und wenn man irgendwann

01:03:43.600 --> 01:03:45.960
ungefähr weiß, in welche Richtung man möchte, dann

01:03:45.960 --> 01:03:47.900
ja. Ja, also

01:03:47.900 --> 01:03:49.740
insofern habe ich das so,

01:03:50.160 --> 01:03:51.780
das ist halt das, wie ich das momentan mache, aber

01:03:51.780 --> 01:03:53.440
wäre vielleicht auch mal ganz interessant,

01:03:53.580 --> 01:03:55.940
Test-Driven-Development mal so wirklich auszuprobieren

01:03:55.940 --> 01:03:58.020
oder mal gezeigt zu bekommen von jemandem, der das so wirklich kann.

01:03:58.020 --> 01:03:59.760
Aber ja, daher

01:03:59.760 --> 01:04:01.560
ist das bei mir eigentlich nie. Das ist das, was

01:04:01.560 --> 01:04:04.160
quasi dann im Applikationscode

01:04:04.160 --> 01:04:05.800
in der General App landet, eigentlich meistens

01:04:05.800 --> 01:04:07.740
schon relativ fertig und die

01:04:07.740 --> 01:04:09.680
Tests, die dazu, also meistens weiß ich

01:04:09.680 --> 01:04:11.660
dann auch schon, welche Tests ich dann schreiben muss und

01:04:11.660 --> 01:04:13.380
dann, ja.

01:04:16.340 --> 01:04:17.160
Macht ihr Tests?

01:04:17.660 --> 01:04:19.860
Es gibt ein paar Leute bei uns,

01:04:19.960 --> 01:04:21.760
die das machen. Ich persönlich

01:04:21.760 --> 01:04:22.320
mache es nicht.

01:04:23.600 --> 01:04:25.700
Ich bin da ähnlich wie Jochen,

01:04:25.760 --> 01:04:27.220
dass ich denke, ich sollte es eigentlich

01:04:27.220 --> 01:04:29.540
mir nochmal im Detail angeschaut haben und nochmal vernünftig

01:04:29.540 --> 01:04:30.180
zeigen lassen.

01:04:31.820 --> 01:04:33.460
Mein Jupyter Notebook ist halt,

01:04:33.500 --> 01:04:35.720
dass ich halt meistens mit aktivem Debugger arbeite.

01:04:36.100 --> 01:04:37.620
Also sprich, ich springe mit dem

01:04:37.620 --> 01:04:39.080
Debugger in den Code, soweit ich bin.

01:04:39.600 --> 01:04:41.640
Debugger heißt also, welche Entwicklungs-MG benutzt du?

01:04:41.980 --> 01:04:43.460
PyCharm von IntelliJ.

01:04:44.360 --> 01:04:45.620
Und ich habe

01:04:45.620 --> 01:04:46.620
mir das irgendwann mal

01:04:46.620 --> 01:04:49.320
angefangen anzugewöhnen, weil das Schöne ist halt,

01:04:49.340 --> 01:04:51.700
du kannst halt dann mit diesem Evaluate Expression

01:04:51.700 --> 01:04:53.580
im Debugger, kannst du halt direkt Sachen

01:04:53.580 --> 01:04:55.540
testen und ausprobieren. Also sprich, wenn du dir nicht

01:04:55.540 --> 01:04:57.680
ganz sicher bist, zum Beispiel, ob eine Query das zurückgibt

01:04:57.680 --> 01:04:59.720
oder wenn man jetzt irgendein komplizierteres

01:04:59.720 --> 01:05:01.340
Aggregate macht, geht das, funktioniert das wirklich

01:05:01.340 --> 01:05:03.580
und solange man nicht versehentlich auf

01:05:03.580 --> 01:05:05.680
Steuerung S, also Speichern drückt und der die Seite

01:05:05.680 --> 01:05:07.860
neu lädt und dann der Debugger neu startet,

01:05:08.680 --> 01:05:09.700
hat man halt

01:05:09.700 --> 01:05:11.640
den Debugger, auch wenn man da ganz viele Änderungen macht

01:05:11.640 --> 01:05:13.800
und kann sich dann natürlich irgendwelche Zwischen-State

01:05:13.800 --> 01:05:15.520
in eine neue Variable speichern und weitermachen

01:05:15.520 --> 01:05:17.060
und...

01:05:17.060 --> 01:05:19.300
Das ist ein sehr interessanter Ansatz, würde ich gerne tatsächlich mal live sehen,

01:05:19.680 --> 01:05:21.440
also weil so, ich glaube so ein bisschen

01:05:21.440 --> 01:05:23.000
macht der Jochen das und ich mache das auch,

01:05:23.080 --> 01:05:25.140
ein bisschen abgucken mit den Notebooks, weil du da halt auch immer diese

01:05:25.140 --> 01:05:27.120
Iterationen dabei hast und auch, also

01:05:27.120 --> 01:05:29.140
ich benutze VS Code manchmal,

01:05:29.860 --> 01:05:31.200
da kann man das ja auch machen

01:05:31.200 --> 01:05:33.280
mit dem Debugger, den ich aber selten für sowas benutze,

01:05:33.360 --> 01:05:35.220
also nur wirklich, wenn ich ein Problem habe, was ich so nicht so einfach

01:05:35.220 --> 01:05:36.920
verstehe, dann gucke ich da mal rein

01:05:36.920 --> 01:05:38.940
und Python macht das. Also für mich

01:05:38.940 --> 01:05:40.940
persönlich, also mir geht es ein bisschen so,

01:05:41.080 --> 01:05:42.480
wie das verstand ab euch beiden auch,

01:05:43.000 --> 01:05:44.960
ich weiß halt am Anfang meistens

01:05:44.960 --> 01:05:46.460
nicht so genau, was nachher rauskommt, also

01:05:46.460 --> 01:05:48.920
wenn die meisten Sachen, die man

01:05:48.920 --> 01:05:50.700
ja so zu testen hat, sind ja dann bei mir jetzt in Services

01:05:50.700 --> 01:05:53.020
und ich weiß halt einfach

01:05:53.020 --> 01:05:54.820
nicht, wie der Service nachher aussieht.

01:05:54.880 --> 01:06:00.820
Hat der nur eine Process-Methode, hat der mehrere Methoden, wie sehen meine internen Methoden aus?

01:06:01.080 --> 01:06:07.620
Ich habe dann noch nicht so ein Bild davon, das entsteht erst während ich daran arbeite und ich dann merke, ah, ich habe vielleicht noch was vergessen und das wächst dann irgendwie.

01:06:07.620 --> 01:06:24.820
Das heißt, ich fange dann eher an, baue einen Service, also eine Klasse, packe da einen Process rein und überlege dann, okay, dann schreibe ich ein bisschen Code mit dem Debugger an, merke, okay, das müsste ich kapseln, das ist nicht testbar sonst, weil da sind zu viele Sachen drin, ziehe das raus, dann baue ich da wieder Sachen dazu und so wächst das dann halt mehr oder weniger von innen nach außen.

01:06:24.880 --> 01:06:46.360
Und ich müsste halt sehr meine Denke umstellen, wenn ich halt erst mir überlege, was möchte ich denn eigentlich so genau alles testen, also was kommt nachher alles raus, weil teilweise manchmal habe ich auch, wenn ich anfange, eine ganz andere Idee von dem, was nachher rauskommt, was ich nachher habe, weil ich nachher eine gute Idee habe und merke, das könnte man vielleicht alles besser, schneller, effizienter, komplett anders machen und ja.

01:06:46.360 --> 01:06:56.900
Also ich denke, TDD ist auf jeden Fall ein sehr hehres Ziel, das zu machen und ich glaube auch, dass Leute, die, sag ich mal, programmieren lernen, das auch bestimmt nicht verkehrt ist, wenn die so anfangen.

01:06:56.940 --> 01:07:00.860
Nee, ich glaube, das ist für sich ganz anders, weil die Leute wissen gar nicht, was sie bauen können.

01:07:01.140 --> 01:07:04.180
Und wenn die nicht lernen, dann, wenn die Tests schreiben, die sind sowas von überfordert.

01:07:04.180 --> 01:07:14.920
Okay, ich formuliere um. Für Leute, die schon programmieren können, aber jetzt, sag ich mal, so ein bisschen mehr in die, also die so, sag ich mal so, das Grundhandwerk verstehen und jetzt anfangen, dann wirklich produktiv arbeiten zu wollen.

01:07:15.200 --> 01:07:20.100
Weil zum Beispiel bei mir, als ich angefangen habe zu programmieren

01:07:20.100 --> 01:07:21.680
und auch Python gelernt habe,

01:07:23.020 --> 01:07:24.640
da war mein Code, den ich geschrieben habe,

01:07:24.680 --> 01:07:26.120
also ich habe damals eh noch keine Unit-Tests geschrieben,

01:07:26.220 --> 01:07:26.960
ich meine, das ist auch schon lange her,

01:07:28.480 --> 01:07:31.840
aber der Code, den ich produziert habe,

01:07:31.840 --> 01:07:34.420
der war nicht gut strukturiert, der war nicht gut testbar.

01:07:35.020 --> 01:07:37.880
Und wenn du halt TDD machst, dann wirst du halt von Anfang an gezwungen,

01:07:38.000 --> 01:07:39.480
dass dein Code die richtige Struktur hat,

01:07:39.520 --> 01:07:41.820
weil du merkst halt sofort, oh, der ist ein Code, den kann ich nicht testen.

01:07:42.240 --> 01:07:44.720
Aber du hast jetzt gerade einen Bias, du hast gesagt, die richtige Struktur.

01:07:45.060 --> 01:07:46.960
Du hast gesagt, dass die Struktur, die man gut testen kann,

01:07:47.040 --> 01:07:47.740
die richtige wäre.

01:07:47.900 --> 01:07:49.240
Eine bessere.

01:07:50.360 --> 01:07:53.340
Aber ich glaube auf jeden Fall, dass Code, der nicht testbar ist,

01:07:53.800 --> 01:07:55.200
nicht so richtig guter Code ist.

01:07:56.540 --> 01:07:58.040
Das würde ich jetzt einfach mal so posten.

01:08:01.100 --> 01:08:02.740
Und das zum Beispiel hat mir,

01:08:02.820 --> 01:08:04.900
als ich dann angefangen habe, mich intensiv mit Unit-Tests zu beschäftigen,

01:08:04.960 --> 01:08:06.200
halt sehr geholfen, auch nochmal

01:08:06.200 --> 01:08:09.080
wirklich beim Codeschreiben auch zu überlegen,

01:08:09.520 --> 01:08:11.740
wo soll das denn alles hin?

01:08:12.120 --> 01:08:14.960
Wenn ich halt weiß, ich möchte das irgendwie isoliert

01:08:14.960 --> 01:08:16.740
und vernünftig, also ich möchte nicht irgendwie nachher drei Stunden

01:08:16.740 --> 01:08:18.760
über Tests nachdenken und irgendwelche wilden Fälle zusammenbauen,

01:08:18.860 --> 01:08:20.820
sondern ich möchte es ja einfach, es funktioniert, ich mache ein oder

01:08:20.820 --> 01:08:23.100
zwei Sachen, genau das möchte ich abchecken, ob das nachher rauskommt

01:08:23.100 --> 01:08:24.920
und fertig. Und wenn man halt

01:08:24.920 --> 01:08:26.820
das nur baut, dass es funktioniert und

01:08:26.820 --> 01:08:28.280
gar nicht über diese Tests nachdenkt,

01:08:28.940 --> 01:08:30.940
ja,

01:08:31.160 --> 01:08:32.740
das ist halt, glaube ich, ein Unterschied. Von daher glaube ich,

01:08:32.740 --> 01:08:34.760
kann das, also ich glaube, für Leute, die schon

01:08:34.760 --> 01:08:36.780
relativ gut wissen, was sie tun, kann das

01:08:36.780 --> 01:08:37.940
natürlich eine Verbesserung sein.

01:08:39.220 --> 01:08:40.560
Wir hatten mal vor vielen,

01:08:40.860 --> 01:08:42.120
vor zwei Jahren einen,

01:08:42.620 --> 01:08:44.740
ich sag mal einen Python-Guru bei uns in der Firma, der mal

01:08:44.740 --> 01:08:46.780
so einen Tag lang über TDD

01:08:46.780 --> 01:08:48.600
erzählt hat und im Endeffekt querbeet alles

01:08:48.600 --> 01:08:49.380
Mögliche und

01:08:49.380 --> 01:08:52.020
war das auch mein erster

01:08:52.020 --> 01:08:54.420
intensiverer Kontakt mit TDD

01:08:54.420 --> 01:08:56.140
und ich habe ihn im Nachgang auch gefragt,

01:08:56.240 --> 01:08:58.520
hey, guck mal, ich arbeite so und so, was sagst du dazu?

01:08:58.680 --> 01:08:59.500
Ich meine, du hast die hier.

01:09:00.760 --> 01:09:02.760
Und er meinte dann, er meinte im Endeffekt

01:09:02.760 --> 01:09:04.640
ist es halt so, es gibt halt

01:09:04.640 --> 01:09:06.360
viele Wege, die nach oben führen. Er selbst findet das gut,

01:09:06.420 --> 01:09:08.220
er macht das auch so, er hat auch irgendwann mal umgelernt,

01:09:08.800 --> 01:09:10.640
aber für ihn zum Beispiel

01:09:10.640 --> 01:09:12.360
ist halt wichtig, dass testbarer Code rauskommt.

01:09:12.360 --> 01:09:14.400
Und wenn man halt selbst durch die Art,

01:09:14.460 --> 01:09:15.460
wie auch immer man da hinkommt,

01:09:15.680 --> 01:09:17.340
wenn ein Testparachoder am Ende rauskommt,

01:09:17.680 --> 01:09:19.300
dann ist halt ein großer Vorteil von TDD,

01:09:19.420 --> 01:09:20.400
hat man halt anders erreicht.

01:09:20.960 --> 01:09:21.320
So what?

01:09:22.800 --> 01:09:24.780
Eine Sache, die ich auch ganz interessant fand,

01:09:24.920 --> 01:09:26.600
ist, bei TDD fängst du an und schreibst einen Test,

01:09:26.660 --> 01:09:27.680
der per se failen muss,

01:09:27.740 --> 01:09:30.020
weil es gibt ja noch nichts, was funktionieren kann,

01:09:30.080 --> 01:09:31.140
weil du ja mit dem Test anfängst.

01:09:31.600 --> 01:09:32.580
Und das fand ich ganz spannend.

01:09:32.680 --> 01:09:34.780
Er meinte, er findet das,

01:09:34.920 --> 01:09:36.920
das ist für ihn so die Routine,

01:09:37.080 --> 01:09:38.900
er fängt irgendwas an zu programmieren

01:09:38.900 --> 01:09:40.880
und sieht erst mal, der Test schlägt fehl.

01:09:42.380 --> 01:09:44.260
Und wenn man andersrum arbeitet,

01:09:44.420 --> 01:09:46.300
dann baut man die Tests ja so, dass sie funktionieren.

01:09:46.520 --> 01:09:48.380
Also du baust ja nicht absichtlich einen Test und baust einen Fehler ein,

01:09:48.420 --> 01:09:50.020
um den Test rot zu haben.

01:09:50.600 --> 01:09:52.680
Und er meinte, das ist halt ganz angenehm, dass du am Anfang siehst,

01:09:52.800 --> 01:09:54.960
okay, ich habe jetzt acht Tests gebaut, die schlagen alle acht fehl

01:09:54.960 --> 01:09:56.540
und nachher mache ich, dass sie gehen.

01:09:57.040 --> 01:10:00.480
Weil es kann halt leicht passieren, dass wenn man halt das andersrum macht,

01:10:00.920 --> 01:10:02.520
dass man halt die Tests baut und dann hat man einen Fehler drin,

01:10:02.520 --> 01:10:04.980
und der Test ist versehentlich grün, also voll positiv.

01:10:05.820 --> 01:10:08.780
Und tatsächlich ist mir das auch mal passiert in einem Projekt,

01:10:09.000 --> 01:10:11.540
da hatte ich ein Rechnungsmodul gebaut,

01:10:11.680 --> 01:10:13.820
also auch zahlungsrelevant und ziemlich heikel.

01:10:14.340 --> 01:10:17.900
Und irgendwie ist dann irgendwann mal, das sah auch alles immer super aus und grün und so weiter.

01:10:18.000 --> 01:10:21.920
Und dann irgendwann ist halt mal die InitPy weggekommen aus dem Testordner, wie auch immer.

01:10:22.920 --> 01:10:24.860
Und naja, dann sind die halt plötzlich mal ausgeführt.

01:10:24.980 --> 01:10:29.080
Der Projektor der damals, glaube ich, 800 Tests, die 50 Tests für die Rechnungslegung,

01:10:29.160 --> 01:10:30.740
ist dann halt nicht aufgefallen, dass die nicht mehr drin sind.

01:10:31.540 --> 01:10:34.040
Ja, und irgendwann waren dann da halt Fehler in der Rechnung und ich dann so,

01:10:34.140 --> 01:10:36.740
hm, irgendwie kann das nicht sein, ich habe das doch getestet.

01:10:37.140 --> 01:10:38.100
Und dann war das so, ups.

01:10:38.480 --> 01:10:41.660
Ich meine, das trifft jetzt nicht so 100% deckungsgleich mit dem, was ich jetzt gerade meinte.

01:10:41.660 --> 01:10:56.220
Aber solche Sachen, es gibt halt schon echt Beispiele, wo man das haben kann. Ich finde diese Idee echt ganz nett, dass man wirklich mal guckt, so hey, funktioniert das denn wirklich? Weil es kann ja wirklich sein, dass man testet einfach, dass der versehentlich funktioniert. Zu viel gemockt oder so, man weiß es nicht und ja.

01:10:58.420 --> 01:10:59.840
Ja, nee, absolut.

01:11:02.280 --> 01:11:10.240
Spannendes Thema. Ich würde jetzt gerne noch ein paar Getränke hier testen. Was haben wir denn noch auf unserer Liste? Ich glaube, die Liste sind wir ganz gut, oder?

01:11:10.240 --> 01:11:11.320
durch? Wir sind durch?

01:11:12.140 --> 01:11:14.400
Nein. Wir sind voll vorbereitet, wir haben eine Liste.

01:11:16.260 --> 01:11:17.780
Die hast du selber geschrieben, ich kann gar nichts lesen.

01:11:18.200 --> 01:11:20.200
Du kannst ja schon mal die Liste lesen. Ich kann ja vielleicht noch mal

01:11:20.200 --> 01:11:22.120
gerade, also ich bin immer noch ganz begeistert

01:11:22.120 --> 01:11:24.120
von dem Sweet Up Your Django Tests

01:11:24.120 --> 01:11:24.700
Buch und

01:11:24.700 --> 01:11:27.800
genau, was man nämlich auch noch alles machen kann,

01:11:28.020 --> 01:11:30.060
an tollen Sachen ist, man kann halt auch noch die Datenbank

01:11:30.060 --> 01:11:31.760
auf ein

01:11:31.760 --> 01:11:33.980
In-Memory-Filesystem legen. Es gibt

01:11:33.980 --> 01:11:36.160
zum Beispiel mit Docker, Docker Compose geht das sehr einfach.

01:11:36.260 --> 01:11:37.980
Das ist eine gute Idee. Ja, und das macht

01:11:37.980 --> 01:11:40.020
die auch nochmal gleich deutlich schneller, weil

01:11:40.020 --> 01:11:42.360
normalerweise kannst du das halt nur machen mit SQLite

01:11:42.360 --> 01:11:43.920
und SQLite will man vielleicht nicht verwenden, weil

01:11:43.920 --> 01:11:46.320
es ist halt anders als Postgres oder was auch immer.

01:11:46.540 --> 01:11:48.220
Ich wollte gerade sagen, kann man damit denn so Postgres

01:11:48.220 --> 01:11:50.160
Testen, wenn ich jetzt zum Beispiel

01:11:50.160 --> 01:11:52.280
in Postgres habe ich jetzt sowas wie Indexes bauen

01:11:52.280 --> 01:11:54.340
oder sowas? Ja, ja, ja, das funktioniert alles.

01:11:55.100 --> 01:11:56.380
Das ist halt das drunterliegende Fallsystem,

01:11:56.500 --> 01:11:58.040
was dann halt nur noch im Hauptspeicher ist.

01:11:59.400 --> 01:12:00.260
Ich muss ja

01:12:00.260 --> 01:12:02.140
gestehen, ich hatte ja, wir hatten ja

01:12:02.140 --> 01:12:04.100
erst geplant, das bei dir daheim zu machen und ich hatte

01:12:04.100 --> 01:12:05.940
gehofft, dass da zu viel das Buch herumliegt, nicht

01:12:05.940 --> 01:12:07.960
in meinen Blick reinwerfen kann. Achso, nee, ich hab's nur elektronisch,

01:12:08.000 --> 01:12:09.960
ich hab's nicht, genau, aber

01:12:09.960 --> 01:12:13.660
Aber ja, lässt sich sicher sonst auch machen.

01:12:13.920 --> 01:12:14.300
Irgendwie muss man gucken.

01:12:15.440 --> 01:12:16.460
Ja, nee, stimmt.

01:12:17.340 --> 01:12:19.680
Ja, ich bin inzwischen fast komplett umgestiegen

01:12:19.680 --> 01:12:23.820
auf elektronische Bücher, weil ja, praktischer Platz.

01:12:24.300 --> 01:12:24.940
Und ich habe sie immer dabei.

01:12:25.500 --> 01:12:27.480
Der einzige Grund ist, du hast keinen Platz mehr im Regal.

01:12:28.180 --> 01:12:28.380
Ja.

01:12:30.160 --> 01:12:32.040
Alles voll, fällt schon alles raus.

01:12:32.620 --> 01:12:34.020
Doppelt, dreifach, kennst du das auch?

01:12:34.440 --> 01:12:36.820
Mehrere Stapel an Bücherlagen im Regal.

01:12:36.820 --> 01:12:38.400
Ja, ja, bei den meisten Bücherregalen

01:12:38.400 --> 01:12:39.920
ist bei uns mindestens eine Lage noch dahinter.

01:12:39.960 --> 01:13:01.360
Ja, genau. Lass mal überlegen, was war denn da? Gab es sonst noch irgendwie interessante Dinge, die im Buch drin standen? Ja, es gibt dann auch irgendwie auch so grundsätzliche Dinge. Genau, Tests parallelisieren bringt sehr viel. Migrationen bringen auch viel, wenn man die squasht.

01:13:01.980 --> 01:13:02.460
Oh ja.

01:13:02.800 --> 01:13:05.300
Das ist halt auch sowas, das sollte man vielleicht ab und zu mal machen.

01:13:05.940 --> 01:13:07.820
Vor allem auch, wenn man so lustige

01:13:07.820 --> 01:13:09.720
Sachen hat wie RunPython, also dass man wirklich

01:13:09.720 --> 01:13:11.800
noch Code ausführt, das kann

01:13:11.800 --> 01:13:13.800
ja, je nachdem,

01:13:13.800 --> 01:13:15.760
ich meine, man hat ja meist eine Testdatenbank, wo nicht so

01:13:15.760 --> 01:13:17.660
viele Datensätze drin sind, aber das je nachdem,

01:13:17.700 --> 01:13:19.960
was man da für abgefahrene Dinge tut, kann das auch schon

01:13:19.960 --> 01:13:23.060
ein Downer sein.

01:13:24.760 --> 01:13:24.920
Ja.

01:13:26.640 --> 01:13:28.120
Ja, aber ansonsten glaube ich,

01:13:28.680 --> 01:13:29.880
ja, nee, muss man selber mal

01:13:29.880 --> 01:13:31.840
gucken. Ich meine, wenn man sich das Blog

01:13:31.840 --> 01:13:33.580
von Adam Johnson anguckt, da sind auch die meisten,

01:13:33.700 --> 01:13:35.840
also ich meine, das Buch ist, viele von den

01:13:35.840 --> 01:13:37.860
Sachen, die darin stehen, hat er auch schon mal irgendwie als

01:13:37.860 --> 01:13:39.380
Blogartikel irgendwie da an seinem Blog gehabt.

01:13:39.860 --> 01:13:42.000
Der hat einfach gewagt, an seinem Blogartikel schon ein Buch

01:13:42.000 --> 01:13:43.200
zu verwurzeln. Wahnsinn.

01:13:43.960 --> 01:13:44.840
Könnte man von lernen.

01:13:45.780 --> 01:13:47.980
Ja, genau.

01:13:49.060 --> 01:13:49.460
Ansonsten,

01:13:50.260 --> 01:13:51.620
ich weiß es nicht, gibt es noch irgendwelche Dinge,

01:13:51.880 --> 01:13:53.760
wir haben jetzt viel über Django geredet, gibt es irgendwie

01:13:53.760 --> 01:13:56.000
Testgeschichten, die auch

01:13:56.000 --> 01:13:57.940
relevant wären, die jetzt nicht so sehr

01:13:57.940 --> 01:13:59.800
Django oder Webentwicklung betreffen?

01:13:59.980 --> 01:14:00.940
Lass mal überlegen, habe ich irgendwas mit

01:14:00.940 --> 01:14:03.980
Data Science? Also da

01:14:03.980 --> 01:14:05.920
ist es auch so, da macht man auch viel Tests.

01:14:08.040 --> 01:14:09.740
Aber das ist auch alles sehr ähnlich.

01:14:10.560 --> 01:14:11.540
Fast alles Unit-Tests,

01:14:11.700 --> 01:14:13.060
die einzelnen Test-Cases.

01:14:16.060 --> 01:14:18.040
Eine Sache, die ich noch ganz interessant

01:14:18.040 --> 01:14:18.400
finde,

01:14:19.440 --> 01:14:21.920
das geht wieder so ein bisschen Richtung

01:14:21.920 --> 01:14:23.140
100% Test-Coverage.

01:14:23.780 --> 01:14:25.420
Ich habe mich auch mal mit jemandem unterhalten und

01:14:25.420 --> 01:14:27.760
da meinte er, er ist gar nicht so ein Fan

01:14:27.760 --> 01:14:29.220
von Unit-Tests. Ich finde, natürlich braucht man die.

01:14:29.540 --> 01:14:33.020
Die gehören einfach zum Team.

01:14:33.240 --> 01:14:36.420
Er meinte, da hat er es so ein bisschen mit den drei Musketieren verglichen.

01:14:36.560 --> 01:14:39.500
Also Arthos, der ist so ein bisschen langweilig, aber der ist halt der Chef.

01:14:39.700 --> 01:14:41.460
Die brauchst du halt einfach, kannst nicht ohne.

01:14:42.120 --> 01:14:45.120
Und was er halt viel cooler findet, sind halt eher Functional Tests.

01:14:45.260 --> 01:14:47.220
Also sprich Tests, die halt die Business-Logik testen.

01:14:47.300 --> 01:14:49.220
Also dass man halt so ein bisschen mehr High-Level-Sachen testet,

01:14:49.600 --> 01:14:52.620
um einfach sicherzustellen, dass, keine Ahnung, wenn man halt irgendeine Logik hat,

01:14:52.620 --> 01:14:55.400
die irgendwas macht, also eine Rechnung erstellen oder irgendwas berechnen

01:14:55.400 --> 01:14:58.960
oder irgendeine Daten aggregieren oder sowas,

01:14:59.020 --> 01:15:01.240
dass die halt das tut, was man von ihr möchte.

01:15:02.620 --> 01:15:21.760
Und das fand ich ganz lustig, weil meistens, wenn halt über das Testing gesprochen wird, dann werden halt Unit-Tests rauf und runter exerziert. Und dann wird auch immer wieder gesagt, so ja, dann gibt es natürlich die End-to-End-Tests, wo man natürlich das Frontend drin hat, wo man dann wieder in einer ganz Django-fernen Welt, oder was heißt Django-fern, das ist halt dann, tangiert Django nicht direkt, sage ich mal.

01:15:21.760 --> 01:15:38.100
Das wird natürlich dann irgendwie aufgerufen und genutzt, aber das ist dann ja auch bei Cypress dann JavaScript-Code und sowas. Und dass man diese Functional-Tests, die kann man halt auch problemlos im, also selbst wenn man Django Headless verwendet, also ohne das Django Forms, Views, Templates etc., kann man diese Functional-Tests halt problemlos bauen.

01:15:38.200 --> 01:16:05.580
Das ist natürlich meistens ein bisschen mehr Setup, weil man halt nicht ein bisschen mehr Cases zusammenbauen muss, aber ich mache das eigentlich für alles, was ein bisschen aufwendiger oder größer und netter ist, mache ich das eigentlich immer, dass ich noch zwei, drei so Functional Tests hinterher schiebe und wirklich einfach sage, ich baue mir so ein Case auf und gucke einfach so, hey, angenommen, ich habe jemand, der, keine Ahnung, ich habe eine Rechnung, enthält die dies und jenes, dass man wirklich, klar, die Teile sind natürlich, die Unitests sind natürlich da, das braucht man natürlich, weil sonst findest du ja nie einen Fehler oder kannst nicht sicher sein, wenn du was kaputt gemacht hast.

01:16:05.720 --> 01:16:13.700
Aber diese High-Level-Tests, oder Higher-Level-Tests, sage ich mal, die sind ja nicht richtig high, das finde ich schon ganz nett.

01:16:14.260 --> 01:16:19.700
Und das wird, finde ich, manchmal so ein bisschen übersehen, dass das halt auch geht und dass das auch einen sehr großen Mehrwert bringen kann.

01:16:20.200 --> 01:16:27.880
Naja, durchaus. Ich weiß gar nicht, ob es da irgendwie so tolle Definitionen von was ist ein Unit-Test, was ist ein Functional-Test, was ist ein Integration-Test, keine Ahnung, aber weiß ich auch nicht.

01:16:28.560 --> 01:16:32.560
Du hast gerade von den drei Musketieren gesprochen und erst ein einziges Musketier erwähnt.

01:16:33.420 --> 01:16:40.780
Genau, also die Functional Test ist Porthos, der Coole, der Pirat und die Integration Test ist dann Aramis, glaube ich, heißt der letzte.

01:16:41.780 --> 01:16:44.140
Die anderen beiden waren? Ja, stimmt, du hast es ja schon.

01:16:44.320 --> 01:16:50.140
Also Arthos, Porthos, Aramis und dann D'Artagnan gehört ja nicht so richtig dazu.

01:16:53.880 --> 01:17:00.240
Nicht, dass der, der das Beispiel gebracht hat, mich jetzt hautweiß durcheinander bringe, aber Arthos ist auf jeden Fall der langweilige Unit Test.

01:17:00.240 --> 01:17:02.100
dann Porthos, glaube ich, war

01:17:02.100 --> 01:17:04.320
das coole. Vielleicht waren das auch

01:17:04.320 --> 01:17:05.800
die End-to-End-Tests, das weiß ich nicht mehr genau.

01:17:06.260 --> 01:17:08.060
Also da sind ja auch noch Porthos, weil die sind beide so

01:17:08.060 --> 01:17:10.360
und genau

01:17:10.360 --> 01:17:12.160
Aramis ist dann Integration-Test, wo man

01:17:12.160 --> 01:17:14.300
so externe APIs und sowas mit anspricht und so

01:17:14.300 --> 01:17:16.300
und das ist dann halt immer so ein bisschen

01:17:16.300 --> 01:17:18.060
das ist zwar total cool

01:17:18.060 --> 01:17:20.100
und jeder mag den Charakter auch, aber der ist halt so ein bisschen

01:17:20.100 --> 01:17:21.960
schwierig. Der ist dann irgendwie ständig verliebt und irgendwie

01:17:21.960 --> 01:17:23.880
Seelenkrise und so und das ist dann auch so mit den externen APIs.

01:17:23.980 --> 01:17:26.140
Es ist total cool, das zu haben, aber man hat halt auch

01:17:26.140 --> 01:17:27.360
irgendwie ziemlich viel Scherrein damit

01:17:27.360 --> 01:17:29.880
und ja.

01:17:30.240 --> 01:17:31.920
Der Wind kommt, der wird die Tests gerade machen.

01:17:31.940 --> 01:17:34.340
Ich glaube, das war

01:17:34.340 --> 01:17:35.460
Porthos,

01:17:35.800 --> 01:17:38.360
ist die End-to-End-Test, weil die halt

01:17:38.360 --> 01:17:40.220
ziemlich cool sind, weil du halt damit wirklich den kompletten Flow

01:17:40.220 --> 01:17:42.020
durchtesten kannst. Und diese Functional-Tests sind

01:17:42.020 --> 01:17:44.400
d'Artagnan, der gehört zum Team

01:17:44.400 --> 01:17:45.860
und der wird aber oft übersehen.

01:17:46.180 --> 01:17:47.780
Weil das heißt immer nur die drei Musketiere und nicht die vier.

01:17:48.300 --> 01:17:48.540
Ja.

01:17:51.620 --> 01:17:52.260
Ja, ja.

01:17:53.320 --> 01:17:54.600
Königin der Kunde oder sowas.

01:17:54.800 --> 01:17:56.220
Die entscheidet dann tatsächlich, wie es mit dem

01:17:56.220 --> 01:17:58.300
weiterläuft. Mit den dreieinhalb,

01:17:58.300 --> 01:17:58.580
vier.

01:18:00.240 --> 01:18:02.700
Ja, fällt euch noch was

01:18:02.700 --> 01:18:04.640
ein zu testen?

01:18:06.280 --> 01:18:07.000
Ich teste glaube ich

01:18:07.000 --> 01:18:08.460
noch Weltenwein. Ja, genau.

01:18:09.040 --> 01:18:10.480
Ich meine, ich glaube, wir sind eigentlich

01:18:10.480 --> 01:18:12.000
so halbwegs durchgekommen und so.

01:18:12.880 --> 01:18:14.960
Die erste Folge draußen war gar nicht so verkehrt.

01:18:14.960 --> 01:18:16.320
Also ich hoffe, es ist nicht

01:18:16.320 --> 01:18:19.240
zu schrecklich. Ich bin mal gespannt, was

01:18:19.240 --> 01:18:20.140
auch Vanek draus macht.

01:18:20.580 --> 01:18:22.540
Ja, genau. Ja, alles klar.

01:18:22.960 --> 01:18:24.600
Ja, vielen Dank auf jeden Fall für die Einladung.

01:18:24.760 --> 01:18:26.500
Also fand ich cool. Ja, schön, dass du da warst.

01:18:27.160 --> 01:18:28.680
Mein erster Podcast

01:18:28.680 --> 01:18:31.200
und ja, war echt cool, hat Spaß gemacht.

01:18:31.500 --> 01:18:32.580
Ja, schön, dass ihr da reingeschaltet habt.

01:18:33.060 --> 01:18:34.220
Vielen Dank, dass ihr da wart.

01:18:34.560 --> 01:18:36.720
Schreibt uns auf hallo.peisenpodcast.de und bleibt uns gewogen.

01:18:37.180 --> 01:18:37.740
Bis zum nächsten Mal.

01:18:38.360 --> 01:18:38.600
Tschüss.

01:18:38.620 --> 01:18:39.120
Tschüss, ciao.