WEBVTT

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

00:00:05.380 --> 00:00:08.440
Heute geht es bei uns um Tests und wir haben wieder einen Gast, der Ronny ist da.

00:00:08.920 --> 00:00:09.720
Hi, Ronny, hallo.

00:00:10.420 --> 00:00:11.260
Und der Jochen natürlich auch.

00:00:11.420 --> 00:00:12.780
Ja, ich bin auch da.

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

00:00:16.000 --> 00:00:19.660
Und Ronny, erzähl doch mal von was sind die? Möchte ich einmal kurz vorstellen.

00:00:20.360 --> 00:00:23.460
Ja, ich heiße Ronny Vidrilia, ich arbeite in Köln bei AIM Innovation.

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

00:00:30.000 --> 00:00:31.920
und habe jetzt meine acht Jahre, die ich da bin,

00:00:32.080 --> 00:00:34.140
auch Großteils mit Backend-Arbeiten

00:00:34.140 --> 00:00:36.320
und Django verbracht,

00:00:36.820 --> 00:00:38.060
habe in Köln

00:00:38.060 --> 00:00:39.960
Wirtschaftsinformatik studiert, also eigentlich

00:00:39.960 --> 00:00:41.860
eher so ein Beraterstudiengang, aber ich hatte immer mehr

00:00:41.860 --> 00:00:44.160
Spaß eigentlich am entwickelnden

00:00:44.160 --> 00:00:45.500
Beraten, beziehungsweise

00:00:45.500 --> 00:00:47.820
Beratung mit Entwicklung zusammen.

00:00:47.860 --> 00:00:48.560
Kann ich ja gar nicht verstehen.

00:00:51.080 --> 00:00:51.400
Und

00:00:51.400 --> 00:00:53.100
genau,

00:00:53.860 --> 00:00:54.520
habe dann,

00:00:55.600 --> 00:00:57.520
wir haben uns eigentlich kennengelernt, du warst Pai Cologne

00:00:57.520 --> 00:00:59.080
oder Düsseldorfer?

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

00:01:03.280 --> 00:01:04.320
Kannten wir uns nicht vorher schon?

00:01:05.240 --> 00:01:06.360
Ja, wir haben uns auf irgendeinem der

00:01:06.360 --> 00:01:07.880
Pycolons mal gefragt.

00:01:07.880 --> 00:01:10.120
Pycolon bestimmt, haben wir uns bestimmt schon mal gesehen.

00:01:10.520 --> 00:01:12.200
Genau, und wie Dominik

00:01:12.200 --> 00:01:13.000
gerade schon gesagt hat,

00:01:13.960 --> 00:01:15.880
seit, ja, jetzt glaube ich

00:01:15.880 --> 00:01:16.620
im knappen Jahr

00:01:16.620 --> 00:01:20.220
richten wir bei uns im Büro, bei Ambient

00:01:20.220 --> 00:01:22.100
das Django-Meetup Köln aus

00:01:22.100 --> 00:01:23.760
und

00:01:23.760 --> 00:01:25.340
genau,

00:01:26.220 --> 00:01:27.360
da sind die beiden auch immer

00:01:27.360 --> 00:01:28.580
regelmäßige Gäste

00:01:28.580 --> 00:01:33.900
Ja, also bis Corona all das verunmöglicht hat sozusagen.

00:01:34.140 --> 00:01:38.120
Also na gut, es gibt halt das virtuelle Meetup und ja, genau.

00:01:38.340 --> 00:01:40.360
Das ist ganz das Gleiche. Ich fand es auch immer schön, die Leute live zu sehen.

00:01:40.740 --> 00:01:45.300
Apropos live sehen, wir haben heute tatsächlich eine Testvorhörer, die einen Test macht.

00:01:45.700 --> 00:01:51.700
Und zwar sind wir zum ersten Mal nicht im Wintergarten, sondern diesmal draußen und sitzen in einem Restaurantgarten.

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

00:01:54.420 --> 00:01:57.460
Ja, genau. Und das ist jetzt quasi das erste Mal live vor Ort draußen.

00:01:57.460 --> 00:02:01.260
also entschuldige mir so ein bisschen die Hintergrundgeräusche das ist ein bisschen urbanes Leben

00:02:01.260 --> 00:02:02.260
genau

00:02:02.260 --> 00:02:03.760
schreibt da gerne mal Feedback zu

00:02:03.760 --> 00:02:07.140
klingt das ganz schrecklich furchtbar oder kann man damit halbwegs leben

00:02:07.140 --> 00:02:09.180
ich meine das ist natürlich angenehm, also gerade wenn es warm ist

00:02:09.180 --> 00:02:10.460
irgendwie eher draußen zu sitzen

00:02:10.460 --> 00:02:12.880
ein bisschen was kühleres zu trinken

00:02:12.880 --> 00:02:14.680
das ist natürlich schon sehr viel angenehmer als jetzt

00:02:14.680 --> 00:02:15.720
Dankeschön

00:02:15.720 --> 00:02:18.580
naja

00:02:18.580 --> 00:02:20.620
die Werte sind zu voll

00:02:20.620 --> 00:02:23.020
ja aber

00:02:23.020 --> 00:02:24.360
eben wenn man in so einem kleinen Raum sitzt

00:02:24.360 --> 00:02:26.900
das ist ja immer das Problem mit der Akustik, man braucht entweder einen kleinen Raum

00:02:26.900 --> 00:02:56.880
und Jochen unterhalten sich über die Programmiersprache Python

00:02:56.900 --> 00:02:59.100
Ja, aber du kannst gerne noch mal ein bisschen

00:02:59.100 --> 00:03:00.920
über die Gerätschaften erzählen, du machst ja schon letztes Mal

00:03:00.920 --> 00:03:03.100
irgendwie... Naja, das ist jetzt einfach

00:03:03.100 --> 00:03:05.400
so ein Zoom H6, das ist halt so ein

00:03:05.400 --> 00:03:06.860
ja, Field Recorder,

00:03:07.080 --> 00:03:08.780
das wird es beworben, das hat halt auch

00:03:08.780 --> 00:03:10.600
so XLR-Eingänge für Mikrofone, macht

00:03:10.600 --> 00:03:12.320
Phantomspeisung und

00:03:12.320 --> 00:03:15.200
dann ist da noch so ein

00:03:15.200 --> 00:03:17.100
Kopfhörerverstärker dran,

00:03:17.200 --> 00:03:19.020
wo dann halt die Ausgänge, die alle das gleiche

00:03:19.020 --> 00:03:20.580
Line-Out-Signal von dem H6 kriegen,

00:03:21.080 --> 00:03:23.140
nochmal dranhängen, damit man sich auch selber und die anderen hören kann.

00:03:23.960 --> 00:03:24.920
Und genau, also

00:03:24.920 --> 00:03:44.380
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.380 --> 00:03:47.380
Ja, muss nicht löten.

00:03:47.600 --> 00:03:54.200
Und braucht keinen Adapter oder so und die Dinger funktionieren einfach an dem Ding direkt, was halt bei den meisten professionellen Audiointerfaces nicht geht.

00:03:54.920 --> 00:04:24.900
und Jochen unterhalten sich über die Programmiersprache Python

00:04:54.920 --> 00:04:57.040
Ja, weil der erste Artikel war von ihm.

00:04:57.100 --> 00:04:57.840
Ich habe es auch gesehen.

00:04:59.720 --> 00:05:04.120
Ich hatte ja schon intern vorher mitbekommen, dass du einen Artikel geschrieben hast.

00:05:04.720 --> 00:05:05.260
Nicht schlecht.

00:05:06.360 --> 00:05:06.840
Ja, was mich...

00:05:06.840 --> 00:05:09.860
Also tatsächlich hat das...

00:05:09.860 --> 00:05:11.940
Jochen will gerade von einer Wespe bearbeiten.

00:05:12.040 --> 00:05:13.140
Die kriegt gerade über seinen Brillenglas.

00:05:14.180 --> 00:05:17.280
Jochen mag Insekten sehr gerne, wie ich schon mitbekommen durfte.

00:05:18.020 --> 00:05:19.540
Aber er bleibt relativ entspannt.

00:05:19.860 --> 00:05:23.320
Also ehrlich gesagt, die Insekten mögen mich mehr als sie, finde ich.

00:05:53.320 --> 00:05:54.420
die Ohren gehauen, das ist unglaublich.

00:05:54.500 --> 00:05:57.400
Er meinte, das geht gar nicht und hat dann 15 oder 16 Seiten

00:05:57.400 --> 00:05:59.120
drangehängt, wie man es richtig macht.

00:05:59.360 --> 00:06:00.000
Danke, Jochen.

00:06:00.560 --> 00:06:02.600
Ja, aber ich wollte das eigentlich alles gar nicht.

00:06:02.880 --> 00:06:04.120
Aber manchmal braucht man halt auch

00:06:04.120 --> 00:06:06.420
einen Anstoß, um das dann zu machen und

00:06:06.420 --> 00:06:08.920
Handwände damit und ja gut, jetzt ist es draußen

00:06:08.920 --> 00:06:11.200
und gut. Also insofern,

00:06:11.420 --> 00:06:12.760
ja, also viel Arbeit und irgendwas

00:06:12.760 --> 00:06:14.780
stecken hilft, wenn das

00:06:14.780 --> 00:06:15.540
irgendwie mal weiterhilft.

00:06:18.540 --> 00:06:20.000
Ja, genau.

00:06:20.400 --> 00:06:21.380
Ach, es gab noch eine neue

00:06:21.380 --> 00:06:23.820
ein Release-Kandidat

00:06:23.820 --> 00:06:25.160
für Python 3.9.

00:06:25.560 --> 00:06:27.020
Den ersten gibt es jetzt.

00:06:27.820 --> 00:06:28.980
Und Leute, die das

00:06:28.980 --> 00:06:30.580
verwenden, haben schon gesagt,

00:06:30.680 --> 00:06:32.320
das funktioniert eigentlich alles ganz fluffig.

00:06:32.880 --> 00:06:34.040
Was sind denn die Neueren von Python 3.9?

00:06:34.420 --> 00:06:38.880
Wir haben das bestimmt schon mal besprochen.

00:06:39.420 --> 00:06:39.480
Wir haben das bestimmt schon mal besprochen.

00:06:39.480 --> 00:06:40.480
Wir haben jetzt auch kein Recht an den...

00:06:40.480 --> 00:06:42.500
Wir können das nicht einfach

00:06:42.500 --> 00:06:43.700
online

00:06:43.700 --> 00:06:46.300
recherchieren.

00:06:46.500 --> 00:06:47.580
Das geht gerade eben nicht.

00:06:48.060 --> 00:06:50.220
Aber ansonsten, weiß nicht, sonst irgendwelche Neuigkeiten?

00:06:50.220 --> 00:06:52.840
Ist dir was eingefallen?

00:06:53.540 --> 00:06:55.120
Nein, außer Django 3.1

00:06:55.120 --> 00:06:57.240
was ich jetzt auch schon nutze

00:06:57.240 --> 00:06:59.320
funktioniert gut, Jason's Feeds sind super

00:06:59.320 --> 00:07:00.480
Mir fällt noch was ein und zwar ist

00:07:00.480 --> 00:07:02.560
von Daniel Roy Fieldroy das Buch

00:07:02.560 --> 00:07:05.000
Two Scopes of Django in der Version 3

00:07:05.000 --> 00:07:07.120
hat er gestern Abend sein Twitch-Kanal

00:07:07.120 --> 00:07:09.020
hochgefahren, weil es jetzt offiziell

00:07:09.020 --> 00:07:11.120
Release-Zone ist. Ah, okay, ich hatte es schon

00:07:11.120 --> 00:07:13.260
gekauft, aber immer die Updates nur gesehen

00:07:13.260 --> 00:07:15.100
nur die dann nie, weil ich dachte, ach ich warte auf die

00:07:15.100 --> 00:07:16.880
fertige Release, wenn ich jetzt weiß, dass es Release ist, super

00:07:16.880 --> 00:07:19.220
dann hole ich mir mal den. Ganz genau, das war

00:07:19.220 --> 00:07:20.320
gestern Abend.

00:07:21.220 --> 00:07:21.740
Ah, sehr schön.

00:07:23.220 --> 00:07:25.340
Ja, nö, ansonsten, genau,

00:07:25.580 --> 00:07:27.020
können wir dann vielleicht direkt mit dem echten

00:07:27.020 --> 00:07:28.320
Thema einsteigen.

00:07:28.740 --> 00:07:31.120
Ja, wollen wir vielleicht einen kurzen Überblick geben? Also ich glaube, wir reden einfach

00:07:31.120 --> 00:07:32.860
los, wie immer, über Tests und so ein bisschen

00:07:32.860 --> 00:07:35.020
mehr Tests und Tests und Tests und Tests

00:07:35.020 --> 00:07:36.480
und der Test funktioniert mit den Tests.

00:07:37.200 --> 00:07:37.740
Mögt ihr Tests?

00:07:39.400 --> 00:07:39.700
Jochen?

00:07:40.980 --> 00:07:43.120
Ja, also ich habe lange

00:07:43.120 --> 00:07:45.020
Zeit, ich habe früher

00:07:45.020 --> 00:07:47.340
die Leute, die so anfingen mit TDD oder so.

00:07:47.420 --> 00:07:48.840
Ich finde Tests total furchtbar.

00:07:49.220 --> 00:07:54.880
Das hat dann irgendwie, als ich noch keinen Test geschrieben habe, oder noch nicht so viele,

00:07:55.360 --> 00:07:56.940
da habe ich so ein bisschen über diese Leute immer gelächelt.

00:07:57.060 --> 00:08:01.500
Ah ja, die mit ihrem komischen statischen Dings da, Java und so, und Testschreiben, höhö.

00:08:01.940 --> 00:08:03.960
Das mache ich alles einfach mal so eben aus der Hand.

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

00:08:06.200 --> 00:08:07.740
Einfach keine Fehler machen, sei es das.

00:08:07.980 --> 00:08:09.980
Genau, das ist alles kein Problem.

00:08:10.500 --> 00:08:15.020
Und dann irgendwann dachte ich so, okay, ich bin vielleicht einfach nicht so der Typ für längere Programme.

00:08:15.020 --> 00:08:21.340
Ich schreibe gerne so kurze Sachen, die so auf eine Bildschirmseite gehen oder vielleicht ein bisschen länger sind,

00:08:21.560 --> 00:08:23.580
aber habe das nie so reflektiert, woran das eigentlich liegt.

00:08:23.740 --> 00:08:27.340
Und dann, als ich irgendwann angefangen habe, Tests zu schreiben, weil das halt in irgendeinem Projekt dann erforderlich wurde,

00:08:28.120 --> 00:08:31.920
merkte ich so, oh, ach, ich kann ja vielleicht doch leckere Programme schreiben.

00:08:32.240 --> 00:08:33.500
Mit Tests geht das plötzlich.

00:08:34.400 --> 00:08:37.840
Das ist halt, man kann sich quasi ausruhen.

00:08:37.940 --> 00:08:42.100
Entweder man hält halt den kompletten State im Kopf und weiß dann halt, dass man wahrscheinlich keine Fehler gemacht haben wird,

00:08:42.160 --> 00:08:44.120
weil man das halt weiß, wie jeder einzelne Teil funktioniert.

00:08:44.120 --> 00:08:48.000
und miteinander interagiert oder wenn man das halt nicht mehr wissen kann, weil es einfach zu viel wird,

00:08:48.600 --> 00:08:50.540
dann braucht man halt Tests, ansonsten passieren schreckliche Dinge.

00:08:50.720 --> 00:08:51.460
Das ist halt einfach so.

00:08:51.620 --> 00:08:52.860
Oder halt auch für Refactoring.

00:08:53.020 --> 00:08:54.860
Das ist halt auch immer ein Riesenargument für Tests.

00:08:55.540 --> 00:08:55.680
Okay.

00:08:55.920 --> 00:08:56.660
Magst du Tests, Jonny?

00:08:57.800 --> 00:08:58.160
Ja.

00:08:58.820 --> 00:09:03.100
Ich muss gestehen, wenn ich unter Zeitdruck viel entwickeln muss,

00:09:03.320 --> 00:09:07.760
dann ärgere ich mich manchmal nachher, dass da noch so viele Tests übrig bleiben,

00:09:07.760 --> 00:09:08.840
die man schreiben muss.

00:09:10.220 --> 00:09:11.760
Aber generell finde ich es eine super Sache.

00:09:11.760 --> 00:09:15.940
und wie gesagt, allein schon wegen Refactoring. Ich arbeite an mehreren

00:09:15.940 --> 00:09:19.580
Django-Projekten, die jetzt schon Jahre laufen und ich weiß,

00:09:19.720 --> 00:09:22.900
wie mühsam das früher war, als wir noch keine Tests da drin hatten

00:09:22.900 --> 00:09:26.380
und wie unmöglich es war, irgendwelche Sachen anzufassen,

00:09:26.920 --> 00:09:31.760
ohne dass man nachher Stunden, am besten tagelang...

00:09:32.820 --> 00:09:35.660
Genau, vor allem dann so zerbrechliche Sachen, wie

00:09:35.660 --> 00:09:39.480
man hat dann zum Beispiel eine Überstundenerfassung oder sowas gebaut und da dann

00:09:39.480 --> 00:10:09.460
und Jochen unterhalten sich über die Programmiersprache Python

00:10:09.480 --> 00:10:39.460
und die Programmiersprache Python.

00:10:39.480 --> 00:10:57.200
Also ich meine, es gibt ja das berühmte Pareto-Prinzip, 80-20-Regel 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, einfach riskieren kann, dass gewisse Dinge vielleicht einfach mal in die Hose gehen dürfen.

00:10:57.200 --> 00:11:18.760
Es wird auch so starr, also wenn du halt ganz, ganz, ganz viel testest, dann kannst du eigentlich ja nichts mehr ändern, ohne dass irgendein Test fehlschlägt. Ich meine, du merkst dann zwar, was dann fehlgeschlagen ist vielleicht, aber das macht einen doch sehr unbeweglich und du hast halt tatsächlich auch, wenn du refactoren willst, wie du eben sagtest, Ronny, das Problem, dass du ganz, ganz viele Sachen und die Tests anfassen musst, weil vielleicht auch die Tests dann refactored werden müssen.

00:11:18.760 --> 00:11:20.800
an. Ja, also ich würde auch

00:11:20.800 --> 00:11:22.600
denken, es kommt halt auf den Anwendungsfall an, also wenn du halt

00:11:22.600 --> 00:11:24.440
irgendwie eine kleine Webseite hast, die

00:11:24.440 --> 00:11:26.740
irgendwas, keine Ahnung, für dich

00:11:26.740 --> 00:11:28.080
und ein paar Freunde irgendwie macht,

00:11:28.580 --> 00:11:30.520
dann braucht man vielleicht keine Tests, weil wenn irgendwas schief geht, dann

00:11:30.520 --> 00:11:32.780
fixt man das halt und es hat ja keinen gestört,

00:11:32.840 --> 00:11:33.740
dass es irgendwie schief gegangen ist.

00:11:34.900 --> 00:11:35.820
Steuerprogramm vom AKW,

00:11:35.920 --> 00:11:37.400
bräuchte vielleicht ein paar mehr Tests. Genau,

00:11:37.620 --> 00:11:39.220
da würde man sich dann vielleicht freuen, wenn die

00:11:39.220 --> 00:11:41.760
bemerken, dass etwas schief läuft, bevor es irgendwie

00:11:41.760 --> 00:11:43.580
die ganze Region mit in den Abgrund reißt,

00:11:43.680 --> 00:11:45.560
aber genau, und da braucht man halt

00:11:45.560 --> 00:11:46.840
vielleicht viele und gute Tests und

00:11:46.840 --> 00:11:48.120
und ja, also

00:11:48.120 --> 00:11:50.480
ich meine, nur ein paar

00:11:50.480 --> 00:11:52.620
Integrationstests zu haben, ist ja auch schon mal

00:11:52.620 --> 00:11:54.480
auf jeden Fall besser als keine Tests zu haben, auch die fangen

00:11:54.480 --> 00:11:56.600
natürlich dann schon Sachen, auf der anderen Seite

00:11:56.600 --> 00:11:58.580
ja, es ist schwierig, das mit den Metriken

00:11:58.580 --> 00:12:00.480
ist immer so eine Sache, ich meine, es ist

00:12:00.480 --> 00:12:02.860
auf jeden Fall immer auch besser, irgendwas zu messen als nichts zu messen

00:12:02.860 --> 00:12:04.700
und dass man irgendwas hat, worauf man optimieren

00:12:04.700 --> 00:12:06.540
kann, aber gerade wenn man jetzt so

00:12:06.540 --> 00:12:08.260
schlechte Tests schreibt, dann

00:12:08.260 --> 00:12:10.520
kriegt man mit denen oft eine gute Testabdeckung

00:12:10.520 --> 00:12:12.220
hin und hoch, weil man macht

00:12:12.220 --> 00:12:14.500
so viele Integrationstests, die ganz viel

00:12:15.500 --> 00:12:16.260
Code aufrufen

00:12:16.260 --> 00:12:18.240
und, aber eigentlich

00:12:18.240 --> 00:12:20.320
sind die halt eher nicht so toll, weil

00:12:20.320 --> 00:12:21.980
die sind halt langsam und

00:12:21.980 --> 00:12:24.280
dann, die

00:12:24.280 --> 00:12:26.180
sind auch schwer zu ändern, wenn man

00:12:26.180 --> 00:12:27.840
dann Code ändert und

00:12:27.840 --> 00:12:30.320
was heißt das eigentlich 100% Test

00:12:30.320 --> 00:12:32.240
Coverage, ich meine die Brand Coverage ist

00:12:32.240 --> 00:12:34.160
ja auch nochmal vielleicht so eine Geschichte, das geht jetzt übrigens mit der

00:12:34.160 --> 00:12:35.680
neuesten,

00:12:35.820 --> 00:12:38.180
Version 5 von Coverage, geht das

00:12:38.180 --> 00:12:40.080
auch, dass man halt dem sagen kann,

00:12:40.800 --> 00:12:42.180
sag mir doch mal, wie viel von den

00:12:42.180 --> 00:12:44.280
If-Verzweigungen, also es reicht

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

00:12:45.720 --> 00:12:47.440
um auch ob die

00:12:47.440 --> 00:12:49.300
tatsächlich beide Pfade genommen haben

00:12:49.300 --> 00:12:51.820
ob irgendein Test getestet hat, ob beide Pfade genommen werden

00:12:51.820 --> 00:12:53.740
und dann

00:12:53.740 --> 00:12:55.680
sieht es halt schon anders aus und ich weiß

00:12:55.680 --> 00:12:57.140
dass es Leute gibt, die dann sowas sagen wie

00:12:57.140 --> 00:12:59.700
naja, das geht auch mit CubbyTree das auch

00:12:59.700 --> 00:13:01.840
dass man sagt, man kann auch zu jedem

00:13:01.840 --> 00:13:03.660
Pfeil angeben, welches

00:13:03.660 --> 00:13:05.760
andere Pfeil für die Abdeckung

00:13:05.760 --> 00:13:07.440
verantwortlich sein soll, also wenn man jetzt zum Beispiel

00:13:07.440 --> 00:13:09.900
im Django-Projekt Models

00:13:09.900 --> 00:13:11.740
py-Pfeil hat, dann

00:13:11.740 --> 00:13:13.740
sagt man, okay, da

00:13:13.740 --> 00:13:15.400
soll die Abdeckung

00:13:15.400 --> 00:13:17.440
gewährleistet werden von Testmodels

00:13:17.440 --> 00:13:19.200
QI und die

00:13:19.200 --> 00:13:21.380
Abdeckung, die daher kommt, dass das aus irgendwelchen

00:13:21.380 --> 00:13:22.800
anderen Integrationstests

00:13:22.800 --> 00:13:24.780
heraus auch aufgerufen wird,

00:13:25.280 --> 00:13:27.480
das zählt nicht. Weil ansonsten

00:13:27.480 --> 00:13:29.260
kannst du halt mit fetten Integrationstests deine

00:13:29.260 --> 00:13:31.360
Coverage hochbringen, aber

00:13:31.360 --> 00:13:33.360
eigentlich ist das überhaupt nicht das, was du haben willst, sondern was du

00:13:33.360 --> 00:13:35.420
eigentlich haben willst, ist, dass du sicher sein kannst, wenn du

00:13:35.420 --> 00:13:37.140
jetzt was änderst, dass du

00:13:37.140 --> 00:13:39.420
tatsächlich nichts damit kaputt gemacht hast

00:13:39.420 --> 00:13:41.260
und das kriegst du gerade bei diesen

00:13:41.260 --> 00:13:42.980
dicken Tests ja gar nicht so richtig mit.

00:13:43.480 --> 00:13:45.140
Also außer du hast das wirklich gravierendes kaputt gemacht.

00:13:45.400 --> 00:13:51.100
Ja, okay, wir sind durch mit Tests.

00:13:51.100 --> 00:13:53.620
Nee, nee.

00:13:54.720 --> 00:13:58.740
Ja, keine Ahnung, aber wie ist das denn praktisch?

00:13:58.920 --> 00:14:00.520
Wann habt ihr denn mit Testen angefangen?

00:14:00.620 --> 00:14:05.440
Ich glaube, ihr macht ja bei euch ganz viel Django schon lange.

00:14:05.840 --> 00:14:06.140
Genau.

00:14:06.440 --> 00:14:08.040
Und habt ihr von Anfang an Tests verwendet?

00:14:08.780 --> 00:14:09.640
Tatsächlich nein.

00:14:10.860 --> 00:14:14.000
Ich meine, die Sinnhaftigkeit von Tests war uns natürlich schon klar,

00:14:14.000 --> 00:14:43.980
und Jochen unterhalten sich über die Programmiersprache Python

00:14:44.000 --> 00:14:45.980
genau das Gegenteil von TDD, also sprich

00:14:45.980 --> 00:14:48.100
du schreibst das bei deinem Code und danach schreibst du die Tests

00:14:48.100 --> 00:14:49.980
und das ist ja quasi ein Mehrwert für den Kunden, weil die

00:14:49.980 --> 00:14:51.640
Software dann besser funktioniert

00:14:51.640 --> 00:14:54.080
und haben dann halt sehr idealistisch versucht dem Kunden das

00:14:54.080 --> 00:14:54.680
zu verkaufen

00:14:54.680 --> 00:14:58.080
und selbst bei technisch

00:14:58.080 --> 00:14:59.840
affineren Kunden war dann halt

00:14:59.840 --> 00:15:01.880
relativ schnell immer die Aussage, naja

00:15:01.880 --> 00:15:04.200
es soll ja funktionieren und wenn es kaputt

00:15:04.200 --> 00:15:06.160
geht ohne Tests, dann müsste es ja trotzdem

00:15:06.160 --> 00:15:08.020
ganz machen und sparen wir Geld, weil wir die Tests nicht

00:15:08.020 --> 00:15:09.540
bezahlen und

00:15:09.540 --> 00:15:11.420
das war dann bei uns so ein

00:15:11.420 --> 00:15:13.740
gewisses Learning, bis wir dann einfach

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

00:15:16.860 --> 00:15:18.360
Weil der Kunde auf die Nase fällt

00:15:18.360 --> 00:15:20.360
und du kannst ihm das vorher erzählen und er bezahlt es halt nicht.

00:15:20.700 --> 00:15:21.600
Dann fällt es halt auf die Nase.

00:15:22.160 --> 00:15:23.600
Man steht halt da ein bisschen blöd da.

00:15:23.900 --> 00:15:24.560
Das ist schon richtig.

00:15:25.440 --> 00:15:27.000
Viele, die ich so mitbekommen habe,

00:15:27.580 --> 00:15:29.340
an kleineren Kunden vor allen Dingen,

00:15:29.780 --> 00:15:31.000
die dann sagten, jetzt können wir es nicht leisten,

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

00:15:33.000 --> 00:15:34.780
Die kamen dann irgendwann reumütig zurück.

00:15:34.880 --> 00:15:35.900
Ja, wir haben jetzt ein Software gebaut,

00:15:36.000 --> 00:15:38.340
es wurde kein Test geschrieben, es funktioniert alles nicht mehr.

00:15:39.080 --> 00:15:40.480
Vielleicht haben die selber irgendwas angefasst.

00:15:40.480 --> 00:15:42.580
Da konnte irgendjemand von den Menschen aus der Firma

00:15:42.580 --> 00:15:44.660
so ein bisschen Dango und hat dann irgendwas umgebaut

00:15:44.660 --> 00:15:46.640
und irgendwas kaputt gemacht oder irgendwas anderes,

00:15:46.760 --> 00:15:47.900
was ihm jetzt später aufgefallen ist.

00:15:49.360 --> 00:15:50.640
Ich muss sagen, also dafür,

00:15:50.800 --> 00:15:52.820
dass wir die ersten

00:15:52.820 --> 00:15:54.700
Jahre, als wir noch ganz klein waren,

00:15:55.300 --> 00:15:56.560
tatsächlich keinen Test geschrieben haben,

00:15:56.560 --> 00:15:58.400
haben die Sachen trotzdem überraschend gut funktioniert.

00:15:58.620 --> 00:15:59.800
Also es wundert mich rückblickend auch.

00:16:00.160 --> 00:16:00.860
Ihr seid alle so gut.

00:16:03.600 --> 00:16:04.680
Aber es ist echt überraschend.

00:16:04.880 --> 00:16:06.520
Also wenn ich heutzutage, wo ich das mit den

00:16:06.520 --> 00:16:08.580
Tests weiß, dann werde ich so schnell nervös, wenn ich

00:16:08.580 --> 00:16:10.380
für irgendwas Kritisches keinen Test schreibe.

00:16:10.380 --> 00:16:19.100
Naja, auf jeden Fall, wir haben dann halt irgendwann einfach gesagt, komm, das ist einfach Teil der Programmierarbeit, das steht nicht zur Debatte

00:16:19.100 --> 00:16:27.700
und seitdem machen wir das und ja, ich glaube, der...

00:16:27.700 --> 00:16:29.080
Habt ihr richtig so eine Struktur da drin?

00:16:31.400 --> 00:16:36.360
Also wir haben jetzt keinen Coding-Guide in der Firma, also ich meine, jeder kann es im Endeffekt machen, wie er möchte.

00:16:36.360 --> 00:16:40.400
Ich meine, natürlich haben wir halt diese typischen QA-Schritte wie Code Review, Content Review und sowas.

00:16:41.320 --> 00:16:45.280
Das ist natürlich ganz klar, dass wenn dann jemand irgendwie der Meinung ist, dass irgendwie Tests so und so geschrieben gehören

00:16:45.280 --> 00:16:48.580
und dass irgendeine wichtige Funktion nicht hinreichend getestet ist, dann kriegt man natürlich den Ball nochmal zurück.

00:16:49.160 --> 00:16:54.600
Aber im Endeffekt gibt es da jetzt keine offizielle Guideline oder sowas, weil ich meine, wie es bei Python so schön heißt,

00:16:54.680 --> 00:17:00.820
we are all adults here, also jeder weiß ja, was er macht und die Akzeptanz ist auch da.

00:17:00.820 --> 00:17:30.800
und Python-Programmierung.

00:17:30.820 --> 00:17:32.540
sodass man dann auch einfach

00:17:32.540 --> 00:17:35.100
unterm Strich halt sehr viel Geld sparen kann, wenn Code

00:17:35.100 --> 00:17:37.120
einfach maintained ist und vielleicht dann auch

00:17:37.120 --> 00:17:39.120
getestet. Wir verkaufen das im Internen

00:17:39.120 --> 00:17:40.780
mittlerweile als Security relevant.

00:17:42.260 --> 00:17:43.320
Also wenn es keine Tests gibt,

00:17:43.400 --> 00:17:45.040
dann ist ganz viel Sicherheitsdrucken da und muss da sicher

00:17:45.040 --> 00:17:46.580
sein, dass das nicht...

00:17:46.580 --> 00:17:48.800
Also ich bin mir nicht sicher, ob es da nicht inzwischen,

00:17:48.920 --> 00:17:50.820
also wir hatten das Thema auch schon mal in der

00:17:50.820 --> 00:17:52.920
Projektmanagement-Episode, aber ob da nicht tatsächlich

00:17:52.920 --> 00:17:55.300
ein echter Interessenskonflikt

00:17:55.300 --> 00:17:56.940
ist, weil es kann sein,

00:17:57.080 --> 00:17:59.000
dass ich aus einer Wirtschaftssicht vielleicht

00:17:59.000 --> 00:18:00.600
tatsächlich sage, okay,

00:18:00.820 --> 00:18:08.900
für die Qualität bin ich nicht bereit zu bezahlen, weil ich hätte gerne lieber mehr Geschwindigkeit.

00:18:09.420 --> 00:18:12.140
Die Musik hat sich übrigens gerade eben geändert, ich hoffe, ihr hört das nicht alle.

00:18:12.820 --> 00:18:15.000
Es war eben so schön entspannt und jetzt haben sie ein bisschen mehr Beat reingebracht.

00:18:15.460 --> 00:18:18.940
Ja, vielleicht treibt es das ja so ein bisschen durch die Nacht.

00:18:19.840 --> 00:18:24.480
Ja, also es kann ja sein, dass ich aus einer wirtschaftlichen Sicht sage,

00:18:25.080 --> 00:18:28.040
das, was die mir an Qualität liefern, das ist mir ehrlich gesagt zu hoch.

00:18:28.460 --> 00:18:30.560
Ich hätte gerne lieber weniger Qualität und dafür schneller.

00:18:30.820 --> 00:18:32.900
und das hat

00:18:32.900 --> 00:18:34.720
den zusätzlichen Vorteil, dass wenn es dann schief geht,

00:18:34.860 --> 00:18:37.020
dann kann ich zu ihnen hingehen und mit ihnen schimpfen und sagen hier so

00:18:37.020 --> 00:18:39.300
das hat nicht richtig funktioniert,

00:18:39.480 --> 00:18:40.240
jetzt macht man noch schneller.

00:18:40.980 --> 00:18:42.860
Voll gut, ja, ich muss ja nur ein bisschen besser sein

00:18:42.860 --> 00:18:44.800
als meine Konkurrenz und ein bisschen weniger zahlen

00:18:44.800 --> 00:18:46.940
für die Produktivität, die ich da irgendwie rausquetsche

00:18:46.940 --> 00:18:48.320
und dann schon

00:18:48.320 --> 00:18:50.660
läuft es bei mir besser als bei anderen.

00:18:50.700 --> 00:18:52.860
Und dann wäre das Problem bei der Entwicklerseite,

00:18:52.980 --> 00:18:55.000
weil dann kein Entwickler dürfte sich darauf einlassen, weil

00:18:55.000 --> 00:18:55.560
das ist ihnen sehr schlecht.

00:18:55.560 --> 00:18:58.760
Ja, ich glaube, Leute tun das dann trotzdem und geraten dadurch

00:18:58.760 --> 00:19:00.560
auch in blöde Situationen und das ist mir auch schon

00:19:00.560 --> 00:19:02.720
selber passiert und man muss eigentlich als Entwickler

00:19:02.720 --> 00:19:04.500
und dann halt vielleicht auch als Agentur, die

00:19:04.500 --> 00:19:06.100
das dann komplett anbietet,

00:19:06.700 --> 00:19:08.380
eigentlich sagen, okay, nee, das ist das, was ich

00:19:08.380 --> 00:19:10.500
also sozusagen, das ist eigentlich meine einzige

00:19:10.500 --> 00:19:12.540
Verantwortung, ist zu sagen, ich übe meine Profession

00:19:12.540 --> 00:19:14.560
kompetent aus und wie ich das

00:19:14.560 --> 00:19:16.400
mache, ist eigentlich meine Sache und

00:19:16.400 --> 00:19:18.260
du kannst halt das nehmen oder nicht, aber

00:19:18.260 --> 00:19:20.500
ich werde keine

00:19:20.500 --> 00:19:22.620
Einschnitte bei der Qualität

00:19:22.620 --> 00:19:24.540
machen, weil hinterher bin ich eh

00:19:24.540 --> 00:19:26.080
der Blöde, wenn es schief geht, bin ich der Blöde

00:19:26.080 --> 00:19:27.980
und ich bin sowieso der Blöde, weil

00:19:27.980 --> 00:19:44.900
weil ich irgendwie damit ja sozusagen auch mich selbst sabotieren ich meine man wird dann ja auch schlechter wenn man irgendwie man lernt das ein Jahr dass man halt rumschlampt und so Das ist eigentlich alles das will man einfach alles gar nicht sondern man m eigentlich

00:19:44.900 --> 00:19:47.040
mit weniger Zeit mehr hinbekommen.

00:19:47.380 --> 00:19:49.380
Wie die Rumschlammschule. Man lernt rumzuschlammen.

00:19:49.540 --> 00:19:49.900
Das finde ich auch.

00:19:50.660 --> 00:19:51.880
Und Tests lösen das.

00:19:53.720 --> 00:19:54.960
Ja, ich meine, die Frage ist halt auch,

00:19:55.000 --> 00:19:56.440
was man für einen Anspruch hat oder was

00:19:56.440 --> 00:19:58.780
der Lebenszyklus der Software ist. Also als wir

00:19:58.780 --> 00:20:00.900
noch ganz klein waren, da haben wir dann

00:20:00.900 --> 00:20:02.700
öfters mal so Marketing-One-Pager gemacht.

00:20:02.700 --> 00:20:04.900
keine Ahnung, Kaugummi-Werbung und sowas.

00:20:05.100 --> 00:20:06.880
Das ist so ein Ding, da ist ein Gewinnspiel

00:20:06.880 --> 00:20:08.700
drin, das läuft genau für einen Monat und

00:20:08.700 --> 00:20:10.740
danach wird das Ding eingestampft und es braucht kein Mensch

00:20:10.740 --> 00:20:11.920
mehr. Ja gut, klar.

00:20:12.540 --> 00:20:14.100
Das sollte natürlich trotzdem funktionieren.

00:20:15.440 --> 00:20:16.780
Das merkt man ja beim Angucken schon

00:20:16.780 --> 00:20:18.020
fast, wenn man einfach

00:20:18.020 --> 00:20:19.100
Localhosts aufmacht.

00:20:20.160 --> 00:20:22.440
Aber wenn man halt sagt, hey, das ist irgendwie jetzt

00:20:22.440 --> 00:20:24.640
vielleicht was, was firmenstrategisch relevant ist,

00:20:26.540 --> 00:20:26.700
da

00:20:26.700 --> 00:20:28.460
committet sich die Firma auch ein bisschen

00:20:28.460 --> 00:20:30.360
drauf, dass jetzt vielleicht auch über Jahre,

00:20:30.360 --> 00:20:31.860
dass sie da halt irgendwie investiert hat und

00:20:31.860 --> 00:20:33.120
das muss gut laufen

00:20:33.120 --> 00:20:36.080
also ich meine bei den Projekten

00:20:36.080 --> 00:20:38.020
die wir jetzt lange betreuen und die wir

00:20:38.020 --> 00:20:40.040
damals auch in den Tests angefangen haben, ziehen wir die jetzt auch

00:20:40.040 --> 00:20:42.020
einfach nach, weil ich meine das ist halt

00:20:42.020 --> 00:20:43.380
einfach sinnvoll und

00:20:43.380 --> 00:20:45.880
man kann inzwischen

00:20:45.880 --> 00:20:47.880
Macht ihr das dann auf eigene Kosten oder sagt dann der Kunde

00:20:47.880 --> 00:20:49.720
ja okay, das ist jetzt hier in unserem Supportaufwand

00:20:49.720 --> 00:20:52.020
Wir machen das

00:20:52.020 --> 00:20:54.060
eigentlich so, dass wir jetzt halt sagen, die Tests

00:20:54.060 --> 00:20:56.040
sind ein elementarer Teil der Programmierung

00:20:56.040 --> 00:20:58.060
Also das ist halt so, als ob man sagt

00:20:58.060 --> 00:20:59.580
10 Minuten aus einer Stunde

00:20:59.580 --> 00:21:01.060
nur für Tests oder so

00:21:01.060 --> 00:21:03.040
Ja, ich würde sagen, wie gesagt,

00:21:03.160 --> 00:21:04.520
also ich bin jetzt auch keiner, der sagt,

00:21:04.840 --> 00:21:06.880
coverage 100%, weil wie gesagt, ich glaube einfach

00:21:06.880 --> 00:21:09.240
80-20-Regel, ich glaube in 80% der Zeit,

00:21:09.940 --> 00:21:11.280
also 80% des

00:21:11.280 --> 00:21:13.040
Notwendigen kriegt man 20% der Zeit hin.

00:21:14.100 --> 00:21:15.060
Und keine Ahnung, wenn ich

00:21:15.060 --> 00:21:16.960
irgendwelche Django-Views oder sowas habe, die mehr

00:21:16.960 --> 00:21:19.440
oder weniger einfach getestete Django-Funktionalität

00:21:19.440 --> 00:21:21.000
ausführen, ich schreibe ich keinen Test dafür.

00:21:21.200 --> 00:21:22.880
Wenn ich irgendwelche Permissions drin habe,

00:21:22.940 --> 00:21:24.920
an denen ich selber rumgebastelt habe, okay,

00:21:25.000 --> 00:21:27.220
das ist was anderes, weil das kann echt mal schnell in die Hose gehen.

00:21:27.840 --> 00:21:29.080
Aber so Standard-Funktionalität

00:21:29.080 --> 00:21:31.500
testlich jetzt auch nicht unbedingt.

00:21:31.680 --> 00:21:33.440
Also umso mehr es Richtung Zahlen

00:21:33.440 --> 00:21:35.240
und Details und Services geht, also

00:21:35.240 --> 00:21:37.380
weiter weg von dem Django-Standard.

00:21:37.460 --> 00:21:39.040
Was ist das? Übrigens interessant,

00:21:39.220 --> 00:21:40.780
wir reden gerade die ganze Zeit nur von Django,

00:21:41.000 --> 00:21:42.920
also Testing kann man ja auch außer von Django tun.

00:21:42.940 --> 00:21:44.680
Das stimmt. Aber wir machen halt einfach viel Django,

00:21:44.780 --> 00:21:46.720
deswegen reden wir jetzt erstmal weiter über Django-Tests.

00:21:47.320 --> 00:21:48.660
Aber ich meine, die meisten Sachen sind ja

00:21:48.660 --> 00:21:49.400
universal.

00:21:51.180 --> 00:21:53.260
Also es ist ja jetzt nichts Django-spezifisches,

00:21:53.400 --> 00:21:54.620
also selbst bei Flask gibt es Views.

00:21:57.140 --> 00:21:58.760
Ja, und eigentlich hat man bei jedem Projekt,

00:21:58.760 --> 00:22:00.620
also es sei denn, man macht halt irgendwas, was halt

00:22:00.620 --> 00:22:02.540
tatsächlich nicht so einen

00:22:02.540 --> 00:22:04.580
wichtigen Anwendungsfall hat, aber eigentlich hat man immer

00:22:04.580 --> 00:22:06.580
Tests mit dabei. Und auch bei Django

00:22:06.580 --> 00:22:08.440
ist genau das, was man halt sonst verwendet, irgendwie

00:22:08.440 --> 00:22:10.260
üblich, nämlich entweder das eingebaute

00:22:10.260 --> 00:22:12.580
Unit-Tests-Modul aus der

00:22:12.580 --> 00:22:14.080
Standardbibliothek oder halt eben

00:22:14.080 --> 00:22:15.420
PyTest, wobei

00:22:15.420 --> 00:22:18.540
ich sagen würde so, wenn

00:22:18.540 --> 00:22:19.940
ich mich so umgucke bei den Projekten,

00:22:20.760 --> 00:22:22.560
in denen ich irgendwie beteiligt bin, ist die

00:22:22.560 --> 00:22:24.200
Mehrheit inzwischen auf PyTest und

00:22:24.200 --> 00:22:26.420
Unit-Test fühlt sich so ein bisschen an, als das sind

00:22:26.420 --> 00:22:28.200
immer so die etwas älteren Sachen und die etwas

00:22:28.200 --> 00:22:29.280
nicht so ganz gut gepflegt.

00:22:29.960 --> 00:22:32.300
Und ich meine, natürlich hat das irgendwie gewissen Charme,

00:22:32.560 --> 00:22:34.160
dass das... Erklär mir doch mal kurz, was denn

00:22:34.160 --> 00:22:36.020
überhaupt der Unterschied ist zwischen Unit-Testers und was PyTester

00:22:36.020 --> 00:22:38.180
Neuerung bringt. Und es gibt auch Nose-Tester oder sowas.

00:22:39.520 --> 00:22:40.400
Ja, Nose

00:22:40.400 --> 00:22:42.600
war früher ein Test-Runner.

00:22:42.680 --> 00:22:44.320
Ich glaube, das ist inzwischen gar nicht

00:22:44.320 --> 00:22:45.240
mehr wirklich Main-Tent.

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

00:22:47.960 --> 00:22:50.380
Okay. Vielleicht benutzt er auch Unit-Test, ich weiß es nicht.

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

00:22:54.260 --> 00:22:54.620
Ja,

00:22:54.760 --> 00:22:56.320
keine Ahnung. Also Nose kenne ich auch noch,

00:22:56.380 --> 00:22:57.440
aber das ist schon echt lange her.

00:22:58.200 --> 00:23:00.180
aus meiner Perspektive ist es

00:23:00.180 --> 00:23:02.340
also Unit Test

00:23:02.340 --> 00:23:03.980
ist irgendwie eine Portierung von JUnit

00:23:03.980 --> 00:23:05.880
und hat halt viele

00:23:05.880 --> 00:23:08.180
der Konzepte dort mitgebracht, die ja auch jetzt

00:23:08.180 --> 00:23:10.280
vielleicht gar nicht so schlecht sind, aber das passt halt

00:23:10.280 --> 00:23:12.300
in vielen Fällen nicht so richtig auf das

00:23:12.300 --> 00:23:13.880
wie man in Python normalerweise programmiert

00:23:13.880 --> 00:23:16.020
Was heißt das denn? Also was

00:23:16.020 --> 00:23:18.520
macht JUnit und warum ist das so anders als das?

00:23:18.660 --> 00:23:20.120
Ja, zum Beispiel einfach allein, dass

00:23:20.120 --> 00:23:21.580
die Methoden Namen CamelCase sind

00:23:21.580 --> 00:23:24.340
dann, dass du halt

00:23:24.340 --> 00:23:26.180
Assert

00:23:26.180 --> 00:23:28.140
Methoden hast auf dem Test, dass jeder Test

00:23:28.140 --> 00:23:28.860
eine Klasse sein muss.

00:23:29.840 --> 00:23:32.260
Das ist halt...

00:23:32.260 --> 00:23:34.180
Wie testet man überhaupt? Also man macht

00:23:34.180 --> 00:23:36.140
eine Testklasse und da setzt man

00:23:36.140 --> 00:23:38.280
quasi die Umgebung auf und dann

00:23:38.280 --> 00:23:40.280
prüft man, ob bestimmte Bedingungen erfüllt sind

00:23:40.280 --> 00:23:41.540
und dann baut man alles wieder auseinander.

00:23:43.380 --> 00:23:43.820
Ja,

00:23:45.160 --> 00:23:46.160
also wenn man jetzt

00:23:46.160 --> 00:23:47.660
zu wie Schreib- und Tests kommt,

00:23:47.660 --> 00:23:48.420
da ist es halt,

00:23:48.520 --> 00:23:51.120
wie heißt es, Range

00:23:51.120 --> 00:23:54.920
oder sowas

00:23:54.920 --> 00:23:55.320
und

00:23:55.320 --> 00:23:57.880
Assert oder was, das weiß ich nicht.

00:23:58.140 --> 00:24:22.540
Man arrangiert die Dinge, die man halt, die Welt sozusagen so hin, dass man testen kann, dann ruft man halt die Funktion, die man testet auf oder halt was auch immer man da testen möchte und dann guckt man hinterher, ist jetzt alles in sozusagen gefälliger Weise wieder drüber zerfallen und es ist so passiert, wie es hätte, wie ist der sozusagen Schornstein in die richtige Richtung, der Baum in die richtige Richtung umgefallen sozusagen.

00:24:22.540 --> 00:24:23.540
nach dem...

00:24:23.540 --> 00:24:26.360
Und das macht man halt

00:24:26.360 --> 00:24:28.340
bei Unit-Tests in der Klasse.

00:24:29.760 --> 00:24:30.560
Und...

00:24:30.560 --> 00:24:32.420
Die TastX-Testcase, ich glaube, Django-Testcase ist auch

00:24:32.420 --> 00:24:34.140
erbarten in Unit-Testcase, oder?

00:24:34.620 --> 00:24:36.200
Ja. Also es gibt bei Django

00:24:36.200 --> 00:24:38.640
vier Testcase-Klassen,

00:24:38.960 --> 00:24:40.460
aber ich glaube,

00:24:40.460 --> 00:24:42.400
die erben alle von

00:24:42.400 --> 00:24:43.160
Testcase, ja.

00:24:45.260 --> 00:24:46.440
Genau, bei PyTest ist es so,

00:24:46.520 --> 00:24:48.440
da können auch Tests einfach Funktionen sein

00:24:48.440 --> 00:24:50.640
und das ist halt nicht Camel-Case,

00:24:50.740 --> 00:24:52.480
sondern Snake-Case oder keine Ahnung,

00:24:52.540 --> 00:24:53.400
mit Underscores halt.

00:24:54.340 --> 00:24:55.740
Und man verwendet halt nicht

00:24:55.740 --> 00:24:58.400
Methoden auf dem Test, um zu testen,

00:24:58.460 --> 00:24:59.880
um zu asserten, sondern

00:24:59.880 --> 00:25:02.740
man benutzt einfach das Assert-Statement.

00:25:03.780 --> 00:25:05.000
Das macht PyTest ja jetzt auch dann.

00:25:05.240 --> 00:25:05.960
Das macht PyTest.

00:25:06.280 --> 00:25:07.100
Unitest macht das nicht.

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

00:25:10.520 --> 00:25:11.160
Ja, genau, genau.

00:25:11.640 --> 00:25:13.720
Super Beispiel, genau.

00:25:14.040 --> 00:25:15.800
Wisst ihr, was die richtige Methode ist?

00:25:15.860 --> 00:25:17.080
Assert-Equals oder Assert-Equal?

00:25:17.640 --> 00:25:18.460
Ich glaube ohne S, oder?

00:25:19.820 --> 00:25:21.260
Ja siehste, weiß ich jetzt auch gar nicht.

00:25:21.260 --> 00:25:23.420
EQUAL. Eins von beiden ist richtig, das andere

00:25:23.420 --> 00:25:25.280
ist nicht gut. Python zeigt mir immer an,

00:25:25.340 --> 00:25:27.320
dass, glaube ich, das mit S, das ist immer durchgestrichen

00:25:27.320 --> 00:25:28.480
wegen Deprecation. Ja.

00:25:29.820 --> 00:25:31.340
Assert EQUAL. Eins von beiden

00:25:31.340 --> 00:25:32.100
ist Deprecated, genau.

00:25:32.940 --> 00:25:35.340
Aber das ist halt so, das ist halt das Problem, das man bekommt, wenn man

00:25:35.340 --> 00:25:36.680
halt so Spezialkram macht.

00:25:37.080 --> 00:25:39.120
Ja, das versteht man auch nicht. Also warum kann man nicht einfach die Python

00:25:39.120 --> 00:25:40.760
implementierte Funktion Assert nehmen

00:25:40.760 --> 00:25:43.340
und dann die zwei Dinge direkt vergleichen, anstatt Assert EQUAL hinzuschreiben

00:25:43.340 --> 00:25:45.240
und zwei Dinge in diesen Funktionsaufbau zu gehen.

00:25:45.560 --> 00:25:47.400
Da passieren irgendwelche magischen Dinge im Hintergrund, wo ich gar nicht

00:25:47.400 --> 00:25:49.160
weiß, ob das so stimmt. Ja gut, wenn

00:25:49.160 --> 00:25:51.080
eben, wenn du

00:25:51.080 --> 00:25:53.280
sozusagen bestimmte Sachen mit einem gefällten Test machen willst

00:25:53.280 --> 00:25:54.920
oder so, dann kannst du das ja quasi

00:25:54.920 --> 00:25:57.120
gar nicht so richtig gut anders machen,

00:25:57.180 --> 00:25:59.220
oder? Ich weiß es nicht, vielleicht ist es auch einfach

00:25:59.220 --> 00:26:00.020
nur Geschmacksgeschichte.

00:26:00.720 --> 00:26:03.120
Wie ist das denn mit zum Beispiel mit den anderen

00:26:03.120 --> 00:26:04.660
Asserts, zum Beispiel Assert Raises?

00:26:06.480 --> 00:26:07.100
Kannst du das auch

00:26:07.100 --> 00:26:08.980
über das Assert Statement abbilden bei PyTest?

00:26:10.580 --> 00:26:10.940
Ja,

00:26:12.120 --> 00:26:12.980
aber es kann sein, dass man

00:26:12.980 --> 00:26:15.260
Also wenn man jetzt Test 2, except Asserts und Adder Raises

00:26:15.260 --> 00:26:17.320
Nein, nein, aber es kann sein,

00:26:17.320 --> 00:26:18.940
also das ist ja auch ein

00:26:18.940 --> 00:26:21.000
Context Manager, es ist irgendwie with irgendwas

00:26:21.000 --> 00:26:23.260
raises, aber ich glaube man importiert

00:26:23.260 --> 00:26:24.260
da irgendwas dann aus PyTest

00:26:24.260 --> 00:26:27.200
Also Hintergrund ist ja einfach nur, dass falls jemand

00:26:27.200 --> 00:26:29.320
falls eine Funktion Fehler werfen soll

00:26:29.320 --> 00:26:30.880
und man genau diesen Case testen möchte

00:26:30.880 --> 00:26:33.200
Ja, also das gibt es

00:26:33.200 --> 00:26:33.580
auf jeden Fall

00:26:33.580 --> 00:26:37.180
Ich muss gestehen, ich nutze auch das, was

00:26:37.180 --> 00:26:38.820
Django von Haus aus mitbringt

00:26:38.820 --> 00:26:40.380
Ich habe

00:26:40.380 --> 00:26:42.920
einen Kollegen, der sehr auf PyTest schwertet

00:26:42.920 --> 00:26:44.260
meint, dass ja alles viel besser und schneller

00:26:44.260 --> 00:26:47.040
Ich habe das auch auf meiner Liste, dass ich mir das nochmal anschaue

00:26:47.040 --> 00:26:53.220
und es ist halt sehr convenient, wenn du halt in der Django eigenen Welt bleibst,

00:26:53.420 --> 00:26:56.380
dann muss man halt wenig nachdenken.

00:26:56.580 --> 00:26:58.980
Von Jochen jetzt PyTest irgendwie gelernt,

00:26:59.540 --> 00:27:02.100
Modus hast du mal 4 und da gibt es halt diese Features,

00:27:02.360 --> 00:27:06.580
gibt es die auch so bei Google Tests ohne PyTest?

00:27:06.740 --> 00:27:08.600
Also ich dachte, das wäre so ein PyTest-exklusives Feature.

00:27:08.820 --> 00:27:10.420
Also in Django kannst du es laden.

00:27:10.660 --> 00:27:12.960
Also in Django gibt es in dieser Django-Testcase-Klasse

00:27:42.960 --> 00:27:45.180
Das hat vielleicht auch viele Vorteile, weil ich halt genau auf die Attribute

00:27:45.180 --> 00:27:46.920
und so weiter alles zugreifen kann und ich dann halt Factories

00:27:46.920 --> 00:27:49.180
nutzen kann, um die zu erzeugen und halt eben nicht nur

00:27:49.180 --> 00:27:50.360
irgendwie Fixtures.

00:27:50.580 --> 00:27:52.860
Das macht man in Unitests auch, also so

00:27:52.860 --> 00:27:54.660
Factory Boy oder Factories

00:27:54.660 --> 00:27:56.260
und halt, aber

00:27:56.260 --> 00:27:58.480
ja, aber diese Art, wie man

00:27:58.480 --> 00:28:00.700
in PyTest halt, dass man das quasi einfach

00:28:00.700 --> 00:28:02.700
magisch, dass man das halt in den Test

00:28:02.700 --> 00:28:04.740
Aufruf mit reinschreibt,

00:28:04.860 --> 00:28:06.600
halt, dass man das haben möchte und es ist dann halt einfach da,

00:28:06.700 --> 00:28:08.500
das ist auch so ein bisschen magisch,

00:28:08.780 --> 00:28:09.880
das gibt es in Unitests nicht.

00:28:09.880 --> 00:28:11.260
und das ist was explizit noch.

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

00:28:13.700 --> 00:28:15.720
gefällt mir. Ich kann einfach meine Features definieren pro

00:28:15.720 --> 00:28:17.720
App, die ich dann irgendwie entwickelt habe

00:28:17.720 --> 00:28:19.620
und dann kann ich die importieren in anderen Apps

00:28:19.620 --> 00:28:22.080
als Confess und habe dann alle Funktionalitäten

00:28:22.080 --> 00:28:23.780
die ich da brauche irgendwie. Ich löse das halt über

00:28:23.780 --> 00:28:25.720
Vererbung. Also ich habe halt dann einen Basetest,

00:28:25.840 --> 00:28:27.840
der dann halt für mein Projekt halt irgendwie die Rollen

00:28:27.840 --> 00:28:28.600
der User

00:28:28.600 --> 00:28:31.820
vielleicht irgendwie ein wichtiges Projekt oder irgendwas

00:28:31.820 --> 00:28:33.840
erstellt und dann halt

00:28:33.840 --> 00:28:35.920
pro App, dass ich dann halt

00:28:35.920 --> 00:28:37.500
wenn ich das brauche, dann nochmal

00:28:37.500 --> 00:28:39.560
eine Ebene dazwischen ziehe und dass

00:28:39.560 --> 00:28:43.040
jeder von den richtigen Tests, also die Endtests,

00:28:43.640 --> 00:28:45.860
dass die halt dann von dieser Klasse erben

00:28:45.860 --> 00:28:48.940
und da ist dann das dementsprechende Setup im Setup drin.

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

00:28:55.020 --> 00:28:56.200
Ja, genau.

00:28:56.380 --> 00:28:59.300
Ich habe auch viel im Projekt mit Unitests,

00:28:59.720 --> 00:29:02.380
dass ich dann halt so viele Test-Mix-Ins importiere

00:29:02.380 --> 00:29:03.820
oder das habe ich halt früher immer gemacht dann,

00:29:04.240 --> 00:29:07.040
die dann halt bestimmte Funktionalität bieten.

00:29:07.040 --> 00:29:08.440
und was ich jetzt aber

00:29:08.440 --> 00:29:10.720
inzwischen so mache, ist

00:29:10.720 --> 00:29:11.440
ich

00:29:11.440 --> 00:29:14.740
erbe von Testcase oder halt

00:29:14.740 --> 00:29:16.900
Transaction Testcase oder was auch immer

00:29:16.900 --> 00:29:18.960
also einem der Grundtesttypen

00:29:18.960 --> 00:29:20.640
von Django und

00:29:20.640 --> 00:29:23.120
mixe die Sachen dann da schon mal

00:29:23.120 --> 00:29:25.140
rein und verwende dann nur noch meine eigenen Testcases

00:29:25.140 --> 00:29:26.980
und sozusagen

00:29:26.980 --> 00:29:28.880
hab dann die ganzen Importe nicht mehr in den Test stehen,

00:29:29.000 --> 00:29:30.600
sondern ich sag dann halt irgendwie, keine Ahnung,

00:29:30.600 --> 00:29:32.940
ich nehme halt den App-Testcase von irgendeiner App

00:29:32.940 --> 00:29:34.820
und da sind die ganzen Mixins

00:29:34.820 --> 00:29:36.040
dann halt drin und

00:29:36.040 --> 00:29:39.020
und dann ist es halt deutlich weniger Schreibarbeit.

00:29:39.420 --> 00:29:40.560
Ja, das sieht auch hübscher aus, glaube ich.

00:29:40.640 --> 00:29:42.460
Also ich habe, glaube ich, eine Sache gemacht, ich weiß nicht, ob man die so macht.

00:29:42.540 --> 00:29:44.080
Ich habe dynamische Importe gemacht,

00:29:44.120 --> 00:29:46.740
von diesen Factories, die ich dann halt haben wollte,

00:29:47.400 --> 00:29:49.160
in der Core-App, weil ich halt nicht genau weiß,

00:29:49.200 --> 00:29:50.820
wie viele Apps gibt es denn noch um die Core-App herum.

00:29:52.420 --> 00:29:53.540
Ich weiß nicht, ob das so eine gute Idee ist,

00:29:53.620 --> 00:29:54.900
aber das funktioniert bisher.

00:29:56.300 --> 00:29:58.640
Dynamische Importe klingt ein bisschen...

00:29:58.640 --> 00:29:59.580
Ja, naja.

00:30:00.160 --> 00:30:01.300
Manchmal muss man auch Sachen ausprobieren,

00:30:01.360 --> 00:30:02.060
manchmal sind sie super,

00:30:02.200 --> 00:30:03.420
manchmal steht man irgendwann fest,

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

00:30:06.040 --> 00:30:12.840
was ja fast schon ein Stichwort wäre

00:30:12.840 --> 00:30:16.100
zum Sachen ausprobieren

00:30:16.100 --> 00:30:18.980
ich hatte vor einiger Zeit

00:30:18.980 --> 00:30:22.120
habe ich eine Django Software gebaut

00:30:22.120 --> 00:30:25.760
da ging es um Projektstundenerfassung und Zeiterfassung

00:30:25.760 --> 00:30:28.040
und alles was irgendwie mit

00:30:28.040 --> 00:30:32.280
Daten, also Datums, also mit Zeit zu tun hat

00:30:32.280 --> 00:30:33.480
ist ja schon relativ kompliziert

00:30:33.480 --> 00:30:38.300
und da ging es dann darum, dass halt eine Zeiterfassung abgebildet werden soll.

00:30:38.360 --> 00:30:41.780
Die Mitarbeiter können sich an- und auschecken und dann gibt es natürlich so Späße wie jemand ist krank,

00:30:42.140 --> 00:30:45.320
jemand ist im Urlaub, es gibt einen Feiertag, es gibt halbe Feiertage,

00:30:46.200 --> 00:30:49.220
zum Beispiel Weihnachten und Silvester, also Heiligabend und Silvester sind halbe Feiertage,

00:30:49.220 --> 00:30:54.700
das heißt man hat, also wird je nach Firma anders ausgelegt, aber in dem Fall war das dann vier Stunden,

00:30:54.700 --> 00:30:56.400
das normale Arbeitszeit wäre.

00:30:58.320 --> 00:30:58.800
Und

00:30:58.800 --> 00:31:00.700
die ganze Logik lief

00:31:00.700 --> 00:31:01.780
und hat auch

00:31:01.780 --> 00:31:04.780
gut funktioniert. Dann habe ich immer gemerkt,

00:31:04.840 --> 00:31:06.720
wenn ich irgendwas refactoren möchte, ich hatte jedes Mal die Hosen

00:31:06.720 --> 00:31:08.660
voll und habe mich halt wirklich nicht dran getraut, weil das

00:31:08.660 --> 00:31:10.240
halt einfach so unmöglich zu testen ist.

00:31:10.900 --> 00:31:12.760
Und habe dann halt erstmal angefangen

00:31:12.760 --> 00:31:14.660
ganz normal zu Fuß

00:31:14.660 --> 00:31:16.080
Tests zu schreiben, also einfach zu schauen.

00:31:16.280 --> 00:31:18.680
Ich setze den und den Case auf, also keine Ahnung,

00:31:18.760 --> 00:31:20.700
Mitarbeiter arbeitet normal fünf Tage

00:31:20.700 --> 00:31:22.660
die Woche, also diese ganzen Datenbankobjekte

00:31:22.660 --> 00:31:40.280
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, ist 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.280 --> 00:32:02.780
Genau. Und dann habe ich angefangen, eine abstrakte Testklasse zu schreiben, die im Endeffekt alle Testmethoden implementiert und diese Zeitenberechnung habe ich im Endeffekt nochmal abgespeckt nachprogrammiert in dieser abstrakten Testklasse.

00:32:02.780 --> 00:32:07.220
und diese abstrakte Klasse wird befüttert durch ein Dictionary von Objekten.

00:32:07.300 --> 00:32:15.560
Und diese Objekte, die sind zum Beispiel, der eine Mitarbeiter arbeitet ganz normal acht Stunden und macht so lange Pause.

00:32:16.380 --> 00:32:17.980
So, das ist ein Objekt, das da reingehen kann.

00:32:18.440 --> 00:32:22.580
Der andere ist zum Beispiel ein anderer Mitarbeiter, der ist nur halbtags da und der arbeitet seine halbtags,

00:32:22.620 --> 00:32:24.240
also seine vier Stunden arbeitet der auch voll.

00:32:24.600 --> 00:32:26.340
Oder es ist ein Wochenendtag.

00:32:26.340 --> 00:32:34.540
und ich konnte dann, wenn ich dann einen aktuellen, also einen tatsächlichen Test schreiben möchte, leite ich davon ab,

00:32:35.440 --> 00:32:42.780
da sind gar keine Testmethoden in dieser Kindklasse drin, sondern ich befülle nur dieses Dictionary, diese Klassenvariable

00:32:42.780 --> 00:32:45.420
und gebe da eine Liste von Objekten rein.

00:32:45.420 --> 00:32:53.060
Ich sage zum Beispiel, okay, ich weiß, der 1.1.2017, 2017 habe ich es gemacht, das war jetzt ein Sonntag,

00:32:53.060 --> 00:33:08.020
Das heißt, da gebe ich das Objekt rein, das ist ein 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. Das macht dann aber die abstrakte Klasse.

00:33:08.020 --> 00:33:12.360
und das heißt, für jeden Testfall, den es gibt, also alle komischen Kombinationen,

00:33:12.640 --> 00:33:15.660
kann ich einfach diese Objekte befüllen und wenn ich jetzt einen neuen Testfall habe,

00:33:15.760 --> 00:33:20.620
muss ich entweder nur diese Liste neu zusammenstellen oder halt ein neues Objekt bauen,

00:33:20.620 --> 00:33:23.340
das halt die Sachen so einstellt, dass es funktioniert.

00:33:24.460 --> 00:33:27.060
War ziemlich abgefahren, ich habe auch ziemlich lange dafür gebraucht.

00:33:27.360 --> 00:33:30.300
Im Endeffekt war es ziemlich cool, weil jedes Mal, wenn ich einen Bug gefunden habe,

00:33:30.380 --> 00:33:32.600
konnte ich halt in drei Minuten, also literally drei Minuten,

00:33:32.700 --> 00:33:35.000
halt einfach diesen Fall nachstellen mit meinen ganzen Objekten

00:33:35.000 --> 00:33:37.620
und konnte sicherstellen, dass es beim nächsten Mal nicht mehr kaputt geht.

00:33:38.020 --> 00:33:39.820
und die größte Herausforderung

00:33:39.820 --> 00:33:41.340
dabei, und das ist auch so ein bisschen

00:33:41.340 --> 00:33:43.540
das große Fragezeichen dahinter ist halt,

00:33:44.060 --> 00:33:45.440
wer kontrolliert den Kontrolleur?

00:33:45.500 --> 00:33:47.500
Weil ich habe ja den Code nochmal teilweise nachgebaut.

00:33:47.620 --> 00:33:49.560
Also ich habe ihn jetzt explizit nicht kopiert, sondern ich habe ihn neu geschrieben

00:33:49.560 --> 00:33:51.540
und auch ein bisschen abgespeckt. Aber was ist,

00:33:51.620 --> 00:33:52.300
wenn man jetzt einen Bug

00:33:52.300 --> 00:33:55.380
im Testcase hat? Und tatsächlich glaube ich,

00:33:55.680 --> 00:33:57.600
80% der fehlgeschlagenen Tests

00:33:57.600 --> 00:33:59.680
waren, dass ich in der Nachimplementierung

00:33:59.680 --> 00:34:01.540
einen Bug hatte. Ich glaube, ich hatte eine richtige Implementierung,

00:34:01.580 --> 00:34:03.400
die ich damals noch vor vielen, vielen Jahren

00:34:03.400 --> 00:34:05.440
ohne Tests geschrieben habe. Da war tatsächlich

00:34:05.440 --> 00:34:07.300
auch kein Fehler mehr drin, weil es halt schon so lange lief

00:34:07.300 --> 00:34:08.440
und die alle ausgemerzt waren.

00:34:09.920 --> 00:34:11.280
Ich war mir sehr

00:34:11.280 --> 00:34:13.200
unsicher, ob das überhaupt eine gute Idee ist, das so

00:34:13.200 --> 00:34:15.160
zu machen, wegen der offensichtlichen Nachteile,

00:34:15.240 --> 00:34:17.080
die es halt gibt. Also dauert lang und wer

00:34:17.080 --> 00:34:19.040
kontrolliert das nachher oder wie kontrolliert man das?

00:34:19.780 --> 00:34:20.860
Und habe dann auf dem

00:34:20.860 --> 00:34:23.160
PyCologne Meetup, zufällig war da jemand,

00:34:23.420 --> 00:34:23.640
der

00:34:23.640 --> 00:34:27.200
mehr oder weniger in einer großen Firma genau

00:34:27.200 --> 00:34:28.960
sowas macht für sehr komplizierte Fälle.

00:34:29.080 --> 00:34:30.260
Ich glaube, das war medizinischer Bereich,

00:34:30.960 --> 00:34:32.920
wo es halt wirklich stimmen muss und der meinte,

00:34:33.020 --> 00:34:34.640
wenn es wirklich, wirklich kompliziert ist,

00:34:35.100 --> 00:34:37.280
dann geht es nicht anders. Also die meinte, es gibt sogar

00:34:37.300 --> 00:34:41.780
Software, die so kritisch ist, dass die einfach den Auftrag, das gleiche

00:34:41.780 --> 00:34:44.720
Pflichtenheft an zwei verschiedene Teams geben, die sich nicht kennen.

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

00:34:49.020 --> 00:34:50.400
Also es ist schon absurd.

00:34:51.020 --> 00:34:57.940
Das ist ja auch immer die Frage, wie aufwendig

00:34:57.940 --> 00:34:59.100
ist es halt irgendwas zu ändern.

00:34:59.920 --> 00:35:03.100
Die Prozessorhersteller machen das ja auch, dass sie halt

00:35:03.100 --> 00:35:06.540
wahnsinnig viele Tests machen, dann Stresstests,

00:35:06.540 --> 00:35:12.840
irgendwie für neue Designs von ihren Chips und so und versuchen das letzte bisschen, was überhaupt testbar ist,

00:35:12.880 --> 00:35:18.840
da rauszukitzeln, einfach deswegen, weil wenn die Maschinen erstmal eingestellt sind und die Wafer irgendwie belichtet,

00:35:18.980 --> 00:35:21.200
dann ist halt schlecht, wenn das irgendwie schiefgegangen ist.

00:35:21.680 --> 00:35:24.560
Man kann auch nicht mehr ändern, kann man halt hinterher nicht mehr fixen,

00:35:25.060 --> 00:35:30.960
während, naja, Code kann man halt noch ändern, das heißt, so furchtbar intensiv muss man es vielleicht auch nicht testen.

00:35:30.960 --> 00:35:34.920
Aber natürlich ist es halt immer noch blöd, wenn Sachen schief gehen

00:35:34.920 --> 00:35:37.040
Daher, ja, irgendwo ist da ein Sweet Spot

00:35:37.040 --> 00:35:38.520
Aber das ist halt nicht so ganz klar

00:35:38.520 --> 00:35:40.860
Ja, Testen ist schon ein bisschen

00:35:40.860 --> 00:35:42.040
dunkle Magie auch

00:35:42.040 --> 00:35:44.960
Ich habe einen Test geschrieben

00:35:44.960 --> 00:35:47.260
Dann habe ich die Tests ausgeführt

00:35:47.260 --> 00:35:49.240
Dann war kein Problem

00:35:49.240 --> 00:35:50.860
Dann habe ich sie nochmal ausgeführt

00:35:50.860 --> 00:35:51.780
Einfach ohne irgendwas zu ändern

00:35:51.780 --> 00:35:52.900
Dann trug der Test viel

00:35:52.900 --> 00:35:55.540
Dann stand ich da natürlich und dachte, was ist denn das jetzt

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

00:35:57.780 --> 00:35:59.220
Dann habe ich nochmal ausgeführt, dann ging es wieder

00:35:59.220 --> 00:36:00.580
Dann habe ich nochmal ausgeführt, dann trug es wieder viel

00:36:00.580 --> 00:36:03.960
und hat mir jemand erklärt, ich habe einen non-deterministischen Test geschrieben,

00:36:04.140 --> 00:36:05.440
also einen Test, der in Ausgang ungewiss ist.

00:36:05.880 --> 00:36:08.700
Und ich habe überhaupt nicht verstanden, von welchen Zeiteffekten,

00:36:08.780 --> 00:36:11.680
von welchen Begebenheiten das hätte kommen können.

00:36:12.020 --> 00:36:13.780
Das fand ich total schwierig zu begreifen,

00:36:14.140 --> 00:36:18.080
warum der gleiche Test in mehrfacher Ausführung mal B-Check, mal nicht.

00:36:18.080 --> 00:36:26.300
Ja, das Ganze gibt es dann natürlich auch irgendwie in sozusagen Reihenfolgenabhängigkeiten.

00:36:26.440 --> 00:36:29.960
Das ist wahrscheinlich somit das Häufigste, dass man quasi zwei Tests hatte

00:36:29.960 --> 00:36:33.180
und da, ohne dass man das jetzt beim Schreiben vielleicht so

00:36:33.180 --> 00:36:35.020
gedacht hätte,

00:36:35.080 --> 00:36:37.140
aber man macht es halt einfach so, weil das dann halt logisch hinterher

00:36:37.140 --> 00:36:39.180
passiert oder so, man macht zuerst das, dann testet man das nächste

00:36:39.180 --> 00:36:41.220
und verändert aber den State

00:36:41.220 --> 00:36:42.620
jetzt bei einem Django-Modell irgendwie so,

00:36:43.080 --> 00:36:45.080
dass der zweite Test halt funktioniert. Und wenn man jetzt

00:36:45.080 --> 00:36:47.060
die Tests in umgekehrter Reihenfolge ausführt, dann funktioniert

00:36:47.060 --> 00:36:49.060
das nicht mehr. Und das ist halt auch

00:36:49.060 --> 00:36:51.200
so ein Ding, man muss halt eigentlich sicherstellen, dass die ganzen Tests

00:36:51.200 --> 00:36:52.880
isoliert funktionieren, weil ansonsten

00:36:52.880 --> 00:36:54.760
kann man nämlich...

00:36:54.760 --> 00:36:57.320
Da gibt es ein sehr schönes Beispiel, das ist auch ganz brandaktuell

00:36:57.320 --> 00:36:59.100
zu Django 3.1, die haben da jetzt nämlich

00:36:59.100 --> 00:37:04.140
einen Bug gefixt, der schon, glaube ich, seit 2012 drin war, mit dem Order By beim Aggregate.

00:37:04.220 --> 00:37:06.100
Ich weiß nicht, ob euch das mal über den Weg gelaufen ist.

00:37:06.740 --> 00:37:09.240
Ist mir am Anfang, als ich neu mit Django war, immer wieder mal passiert,

00:37:10.340 --> 00:37:15.800
dass ich bin mir nicht mehr so 100% sicher, ich habe es länger nicht mehr selber erlebt,

00:37:15.800 --> 00:37:19.940
aber wenn man eine Aggregierung oder ein Annotate macht und dann Order By,

00:37:21.780 --> 00:37:26.060
beziehungsweise wenn das Model selbst in der Meta-Option, in Order By,

00:37:26.060 --> 00:37:28.380
eine standardmäßige Notierung

00:37:28.380 --> 00:37:30.380
ergiefert, dann gab es Bugs.

00:37:30.520 --> 00:37:32.200
Dann hat das ORM

00:37:32.200 --> 00:37:34.300
teilweise komische oder falsche Sachen zurückgegeben.

00:37:35.140 --> 00:37:36.260
Der Bug, das Ticket

00:37:36.260 --> 00:37:37.560
ist 3000 Jahre alt

00:37:37.560 --> 00:37:39.880
und die haben das jetzt tatsächlich repariert

00:37:39.880 --> 00:37:42.540
und das führt dazu,

00:37:43.040 --> 00:37:44.260
dass die Lösung war einfach,

00:37:44.380 --> 00:37:46.520
das ist halt aus Gründen

00:37:46.520 --> 00:37:48.240
funktioniert es nicht und das heißt, wenn du

00:37:48.240 --> 00:37:49.560
aggregierst oder annotierst,

00:37:50.120 --> 00:37:51.860
dann wird dieses ORDER BY

00:37:51.860 --> 00:37:53.640
im Model Meter ignoriert.

00:37:54.440 --> 00:37:55.040
Das heißt,

00:37:55.040 --> 00:37:57.940
bei meinen Cases, wo ich das gemacht hatte,

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

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

00:38:01.420 --> 00:38:04.060
meine Projektliste oder meine Mitarbeiterliste,

00:38:04.120 --> 00:38:06.100
die wird ja

00:38:06.100 --> 00:38:07.640
übers Model sortiert. Hatte ich natürlich

00:38:07.640 --> 00:38:08.740
kein X-Wise oder bei gemacht.

00:38:09.700 --> 00:38:12.040
Plötzlich schlagen irgendwelche Tests für, nachdem ich auf Django 3.1

00:38:12.040 --> 00:38:13.740
hochgegangen bin, weil da die Reihenfolge anders ist.

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

00:38:15.700 --> 00:38:17.100
Reihenfolge, die die Datenbank zurückgibt.

00:38:18.760 --> 00:38:19.620
Okay, ja, das ist

00:38:19.620 --> 00:38:21.500
auch gefallen, ja. Ziemlich abgefahren.

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

00:38:22.940 --> 00:38:25.460
also ich hab doch nur, ich hab Django hochgezogen, was ist denn da los?

00:38:25.860 --> 00:38:26.420
Bis mir dann

00:38:26.420 --> 00:38:29.040
ein lieber Kollege sagte, schau mal

00:38:29.040 --> 00:38:30.980
such mal nach Otterbye in den

00:38:30.980 --> 00:38:32.800
Also Otterbye ist ja echt rausgeflogen?

00:38:33.380 --> 00:38:35.140
Ne, das ist nur für diesen Sonderfall.

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

00:38:38.180 --> 00:38:39.500
Also den haben die gefixt und die Lösung

00:38:39.500 --> 00:38:41.060
dafür ist, dass es halt nicht mehr genommen wird.

00:38:41.740 --> 00:38:43.220
Du kannst es manuell dahinter schreiben,

00:38:43.280 --> 00:38:44.860
dann funktioniert es, aber du musst es halt manuell machen.

00:38:44.960 --> 00:38:45.940
Aber in der Mittagklasse geht es nicht mehr?

00:38:47.520 --> 00:38:48.700
Immer, außer du machst

00:38:48.700 --> 00:38:49.580
Irritate to Aggregate.

00:38:49.580 --> 00:38:50.080
Ah, okay.

00:38:50.080 --> 00:38:52.680
Da gibt es auch einen eigenen Eintrag dazu

00:38:52.680 --> 00:38:54.560
und das ist auch irgendwo im Ticket nochmal festgehalten und verlinkt

00:38:54.560 --> 00:38:55.100
etc. etc.

00:38:56.260 --> 00:38:58.680
Ich bin da jetzt auch nicht 100% in Details drin, ich bin halt

00:38:58.680 --> 00:39:00.740
nur drüber gestolpert, weil das war auch genau das mit der

00:39:00.740 --> 00:39:02.640
Reihenfolge. Plötzlich war mein Element, dass ich an Stelle 1

00:39:02.640 --> 00:39:03.960
erwarte, an Stelle 2 und umgekehrt.

00:39:04.520 --> 00:39:06.640
Und wenn dann halt die Tests so

00:39:06.640 --> 00:39:08.740
gebaut sind, dass der halt die Reihenfolge explizit

00:39:08.740 --> 00:39:09.840
erwartet, weil ich ja wusste,

00:39:10.040 --> 00:39:12.240
damals noch sortiert war, dann

00:39:12.240 --> 00:39:13.660
steht man da plötzlich.

00:39:15.040 --> 00:39:15.300
Ja Und das mit der Reihenfolge von Tests ist halt und ist halt auch deswegen so wichtig weil n ein F

00:39:44.800 --> 00:39:48.400
auf jeden Fall, und ich weiß auch nicht, das ist bei PyTest und bei Unitest anders, aber man kann halt

00:39:48.400 --> 00:39:52.580
mit einer bestimmten Option sagen, so, führ die Tests mal in umgekehrter Reihenfolge aus. Wenn das schief geht,

00:39:52.640 --> 00:39:56.520
dann weiß man schon, dass man ein Problem hat. Oder führ die mal in zufälliger Reihenfolge aus, dann muss man es halt wahrscheinlich

00:39:56.520 --> 00:40:00.340
ein paar Mal ausführen und wenn es dann funktioniert hat, hat man vielleicht Glück gehabt und

00:40:00.340 --> 00:40:04.440
man kann es parallelisieren. Aber genau, wenn die Tests isoliert voneinander

00:40:04.440 --> 00:40:08.460
funktionieren, dann kann man halt die halt auch parallel ausführen

00:40:08.460 --> 00:40:12.220
und dann halt es halt quasi um den Faktor,

00:40:12.220 --> 00:40:42.220


00:40:42.220 --> 00:40:45.480
das mit dem Parallelisieren eigentlich fast vergessen, weil das kriegst du halt nicht so einfach umgestellt.

00:40:46.480 --> 00:40:50.200
Ja, genau.

00:40:51.580 --> 00:40:55.120
Wie ist das? Habt ihr da häufig Probleme mit langlaufenden Tests?

00:40:56.780 --> 00:41:00.480
Wie viele Tests habt ihr denn überhaupt? Bei großen Projekten muss das ja in die Zehntausende gehen.

00:41:00.480 --> 00:41:10.740
Ja, tatsächlich. Also bei unseren langlaufendsten Projekten bin ich nicht mehr aktiv dabei.

00:41:10.740 --> 00:41:10.740


00:41:10.740 --> 00:41:13.420
also bin ich nicht im Dev-Team, das heißt

00:41:13.420 --> 00:41:15.660
ich habe da jetzt keine Zahlen, aber ich weiß

00:41:15.660 --> 00:41:17.000
dass die Pipelines

00:41:17.000 --> 00:41:19.100
da teilweise auch Stunden brauchen

00:41:19.100 --> 00:41:20.900
also einfach weil

00:41:20.900 --> 00:41:23.580
die haben da inzwischen noch Optimierung gemacht

00:41:23.580 --> 00:41:25.220
das ist halt mehr gar nicht nach jedem Feature-Release

00:41:25.220 --> 00:41:26.780
wenn man da irgendwie Agile irgendwie dran sitzt

00:41:26.780 --> 00:41:29.520
tatsächlich haben wir da jetzt auch

00:41:29.520 --> 00:41:31.400
Lösungen irgendwie gebaut, dass halt manche

00:41:31.400 --> 00:41:33.640
Tests laufen dann irgendwie nicht mehr

00:41:33.640 --> 00:41:34.500
pro Commit

00:41:34.500 --> 00:41:37.520
oder irgendwie Sachen werden lokal getestet, weil es lokal

00:41:37.520 --> 00:41:40.020
doch manchmal ein bisschen schneller geht oder es mehr ist eine Parallelisierung

00:41:40.020 --> 00:42:10.000
und die Technik.

00:42:10.020 --> 00:42:40.000
und Jochen unterhalten sich über die Programmiersprache Python

00:42:40.020 --> 00:42:42.520
eine magische Funktion, das sind die SetupTestData

00:42:42.520 --> 00:42:43.500
und

00:42:43.500 --> 00:42:45.160
da wird es

00:42:45.160 --> 00:42:48.000
in eine Transaction gerappt,

00:42:48.240 --> 00:42:50.180
das heißt, die Daten

00:42:50.180 --> 00:42:52.400
werden nur einmal ausgeführt, es ist auch eine ClassMethod,

00:42:52.500 --> 00:42:54.140
also es ist nur einmal pro Klasse, aber die

00:42:54.140 --> 00:42:56.380
kann man quasi recyceln, also bei jedem

00:42:56.380 --> 00:42:58.200
Testaufbau, das heißt,

00:42:58.240 --> 00:42:59.860
man hat so ein bisschen das Beste von beiden Welten.

00:43:00.440 --> 00:43:01.980
Ich habe das dann gelesen, fand das cool und dachte,

00:43:02.060 --> 00:43:03.620
ach, mal gucken, was das bringt, habe gedacht, ah,

00:43:03.700 --> 00:43:06.100
1000 Tests, das dauert bestimmt ewig, aber tatsächlich

00:43:06.100 --> 00:43:08.140
ging es relativ fix, nach 2-3 Stunden war ich fertig

00:43:08.140 --> 00:43:09.220
und

00:43:09.220 --> 00:43:10.860
ja, hab die Python von

00:43:10.860 --> 00:43:13.540
25 Minuten auf 5 Minuten gedrückt

00:43:13.540 --> 00:43:15.720
für die Tests und das hat mich halt

00:43:15.720 --> 00:43:17.700
echt richtig, richtig, richtig überrascht, dass das

00:43:17.700 --> 00:43:19.640
so viel bringt tatsächlich. Ich meine, klar,

00:43:19.720 --> 00:43:21.640
wenn man überlegt, dass jede Testklasse

00:43:21.640 --> 00:43:22.940
vielleicht 20 Tests hat, dann

00:43:22.940 --> 00:43:24.440
ja,

00:43:25.280 --> 00:43:27.300
5 Tests schneller. Da gab es doch jetzt auch genau

00:43:27.300 --> 00:43:29.540
dieses Buch dazu, wie man Django-Tests

00:43:29.540 --> 00:43:31.620
Ja, von Adam Johnson, jetzt irgendwann im Mai

00:43:31.620 --> 00:43:33.660
rausgekommen, Speed Up Your

00:43:33.660 --> 00:43:35.520
Django-Tests heißt das irgendwie.

00:43:36.240 --> 00:43:37.040
Genau und

00:44:37.040 --> 00:44:38.780
ist PyTest schon normalerweise ein Stück schneller

00:44:38.780 --> 00:44:41.080
und bei der reporteten Zeit ist es

00:44:41.080 --> 00:44:43.080
relativ ähnlich, aber das liegt halt daran, dass PyTest einfach

00:44:43.080 --> 00:44:44.760
mehr Sachen dazu zählt, zudem

00:44:44.760 --> 00:44:46.420
das hat jetzt, so lange hat der Test gedauert.

00:44:47.940 --> 00:44:48.140
Und

00:44:48.140 --> 00:44:50.980
ja, also was er empfiehlt, was man

00:44:50.980 --> 00:44:52.980
halt am Anfang machen kann, ist, also man

00:44:52.980 --> 00:44:55.080
sollte erstmal gucken, erstmal messen,

00:44:55.140 --> 00:44:56.360
also halt zum Beispiel

00:44:56.360 --> 00:44:59.080
sich anschauen, was sind denn eigentlich so die langsamsten

00:44:59.080 --> 00:45:01.120
Tests, die man so hat, weil normalerweise

00:45:01.120 --> 00:45:03.200
hat man da auch so eine Pareto-Verteilung,

00:45:03.400 --> 00:45:04.800
dass halt 20% der

00:45:04.800 --> 00:45:07.080
der Tests machen halt 80% der Zeit aus

00:45:07.080 --> 00:45:08.100
und

00:45:08.100 --> 00:45:10.460
mit PyTest geht das einfach so

00:45:10.460 --> 00:45:12.740
minus minus Durations und dann

00:45:12.740 --> 00:45:14.220
eine Zahl und dann kriegt man halt die

00:45:14.220 --> 00:45:16.740
Zahl langsamsten Tests

00:45:16.740 --> 00:45:18.260
einfach am Schluss ausgegeben

00:45:18.260 --> 00:45:20.820
und bei Unit-Tests muss man halt irgendwie Jungle-Slow-Tests

00:45:20.820 --> 00:45:21.740
installieren oder so

00:45:21.740 --> 00:45:24.680
aber damit geht das in der Art auch und dann den Test-Runner

00:45:24.680 --> 00:45:26.680
ersetzen und dann kriegt man die halt auch ausgegeben

00:45:26.680 --> 00:45:28.780
und dann kann man halt bei den

00:45:28.780 --> 00:45:30.580
Tests halt dann mit einem Profiler nachgucken

00:45:30.580 --> 00:45:32.800
was macht die eigentlich so langsam und dann findet man

00:45:32.800 --> 00:45:34.640
wahrscheinlich schon Dinge, die man halt verbessern kann

00:45:34.640 --> 00:45:35.700
und

00:45:35.700 --> 00:45:38.780
ja, da gibt es dann auch so Dinge

00:45:38.780 --> 00:45:40.100
wie, ja man kann halt

00:45:40.100 --> 00:45:42.200
es gibt da diverse Tools mit denen man sich

00:45:42.200 --> 00:45:44.700
man kann ein C-Profile, kann man Ausgaben

00:45:44.700 --> 00:45:45.900
an Zeugen, die man sich dann gucken kann

00:45:45.900 --> 00:45:48.420
mit K-Cashbrite oder

00:45:48.420 --> 00:45:49.880
naja gut, muss man sich

00:45:49.880 --> 00:45:51.280
da gibt es eine Menge Zeugs

00:45:51.280 --> 00:45:54.360
dann gab es

00:45:54.360 --> 00:45:56.560
so Easy Wins, so einfache

00:45:56.560 --> 00:45:58.000
Dinge, die man halt mal tun kann

00:45:58.000 --> 00:46:00.440
um halt die Geschwindigkeit von Tests

00:46:00.440 --> 00:46:02.420
zu verbessern und da ist glaube ich

00:46:02.420 --> 00:46:03.860
das erste, was er schreibt, ist halt

00:46:03.860 --> 00:46:05.880
den Passwort-Hasher zu ersetzen.

00:46:06.620 --> 00:46:07.400
Das ist halt auch mal so ein Standard,

00:46:08.040 --> 00:46:09.880
weil man erzeugt halt viele User

00:46:09.880 --> 00:46:11.440
und so und da muss man halt auch...

00:46:11.440 --> 00:46:13.880
Und die echten Passwort-Hash-

00:46:13.880 --> 00:46:15.920
die echten Passwort-Hash-Algorithmen

00:46:15.920 --> 00:46:17.820
sind natürlich extra so designt, dass sie möglichst langsam

00:46:17.820 --> 00:46:19.300
sind, damit man halt nicht

00:46:19.300 --> 00:46:21.760
viele Hashes durchprobieren kann, weil das

00:46:21.760 --> 00:46:23.760
einfach zu teuer wäre. Das will man

00:46:23.760 --> 00:46:25.660
jetzt natürlich, wenn man Sachen beschleunigen möchte, möchte man nicht.

00:46:26.040 --> 00:46:27.280
Möchte man jetzt halt aber eher schnell haben.

00:46:27.660 --> 00:46:29.260
Und wenn man dann den MD5-Hasher nimmt,

00:46:29.380 --> 00:46:30.960
der ist halt nicht sicher, aber...

00:46:30.960 --> 00:46:33.660
Bei Hes ist es halt egal,

00:46:33.660 --> 00:47:03.640
und Jochen unterhalten sich über die Programmiersprache Python

00:47:03.660 --> 00:47:33.640
und Jochen unterhalten sich über die Programmiersprache Python

00:47:33.660 --> 00:47:34.660
für die Testdatenbank

00:47:34.660 --> 00:47:37.760
Serializable.folds

00:47:37.760 --> 00:47:39.620
oder so, auch eine Konfiguration und dann wird das halt nicht

00:47:39.620 --> 00:47:41.520
gemacht. Man braucht das eigentlich fast nie.

00:47:41.620 --> 00:47:43.820
Es gibt ganz selten Testfälle, die sowas benötigen,

00:47:43.940 --> 00:47:45.600
aber eigentlich braucht man das nicht

00:47:45.600 --> 00:47:47.520
und macht auch Sachen schneller.

00:47:50.440 --> 00:47:50.800
Dann

00:47:50.800 --> 00:47:53.040
was war da noch drin?

00:47:53.580 --> 00:47:54.840
Also solche Dinge, wie man kann,

00:47:55.200 --> 00:47:57.580
das kannte ich gar nicht. Das war mir neu.

00:47:58.260 --> 00:47:58.780
Ich habe tatsächlich,

00:47:59.600 --> 00:48:01.520
oder ich weiß nicht, wie du das machst mit Files, wenn du

00:48:01.520 --> 00:48:03.580
halt irgendwelche Bilddaten oder so

00:48:03.580 --> 00:48:03.580


00:48:03.580 --> 00:48:05.520
Testes oder so, hat eigentlich auch viel mit Files zu tun.

00:48:07.620 --> 00:48:09.480
Ich hatte zum Beispiel immer das Problem, dass dann halt viele

00:48:09.480 --> 00:48:11.600
Files einfach noch am Schluss rumgelegen

00:48:11.600 --> 00:48:13.740
sind und dann habe ich halt irgendwelche

00:48:13.740 --> 00:48:15.280
Cleanup-Scripts geschrieben.

00:48:15.300 --> 00:48:17.200
Genau, Dinger geschrieben,

00:48:17.380 --> 00:48:19.260
nicht Cleanup-Scripts, sondern halt schon das

00:48:19.260 --> 00:48:21.540
quasi so mit in die,

00:48:21.680 --> 00:48:23.420
ich habe dann das in Dekoratoren

00:48:23.420 --> 00:48:25.480
reingeschrieben und dann halt die Testplassen dekoriert

00:48:25.480 --> 00:48:27.420
und die haben dann hinterher quasi die

00:48:27.420 --> 00:48:29.300
Media, das Media-Root wieder

00:48:29.300 --> 00:48:30.220
aufgeräumt oder so.

00:48:31.020 --> 00:48:32.300
Ich weiß gar nicht mehr genau, wie ich das

00:48:32.300 --> 00:48:32.300


00:48:32.300 --> 00:48:34.680
auf jeden Fall habe ich da halt irgendwie

00:48:34.680 --> 00:48:36.660
Aufwand reingesteckt und dachte so, oh das war ätzend

00:48:36.660 --> 00:48:37.800
und es gibt

00:48:37.800 --> 00:48:40.840
DJ in Memory Storage heißt das Paket

00:48:40.840 --> 00:48:43.120
glaube ich und da kann man

00:48:43.120 --> 00:48:44.940
das Default Storage

00:48:44.940 --> 00:48:46.540
ersetzen durch halt in Memory

00:48:46.540 --> 00:48:49.100
Storage und dann wird überhaupt nichts gespeichert

00:48:49.100 --> 00:48:50.520
und das ist halt viel schneller, weil es ist halt in Memory

00:48:50.520 --> 00:48:52.720
es funktioniert halt genauso, aber

00:48:52.720 --> 00:48:54.820
es landet hinterher gar nichts auf der Platte und wenn man

00:48:54.820 --> 00:48:56.840
viel mit Files macht, dann

00:48:56.840 --> 00:48:58.660
ist es halt sofort deutlich schneller

00:48:58.660 --> 00:49:01.140
ja, das war auch

00:49:01.140 --> 00:49:02.280
so ein Ding, das fand ich echt gut

00:49:02.280 --> 00:49:04.620
das ist sehr praktisch

00:49:04.620 --> 00:49:05.520
dann

00:49:05.520 --> 00:49:08.040
gab es noch so Salary-Optimierungen

00:49:08.040 --> 00:49:10.320
da kann man auch ein Memory-Backend verwenden

00:49:10.320 --> 00:49:12.380
und

00:49:12.380 --> 00:49:13.880
naja, man muss halt gucken, dass die

00:49:13.880 --> 00:49:16.600
dass man halt Always-Eager auf True setzt

00:49:16.600 --> 00:49:18.360
und auch noch irgendwas anderes

00:49:18.360 --> 00:49:18.960
weiß ich nicht mehr genau

00:49:18.960 --> 00:49:21.620
ja, sowieso diese ganzen

00:49:21.620 --> 00:49:23.600
Async-Task-Dinger

00:49:23.600 --> 00:49:26.520
da gibt es dann halt Jungle-Queue, das will ich mir mal angucken

00:49:26.520 --> 00:49:28.100
Salary, hab ich letztens wieder, ah Salary

00:49:28.100 --> 00:49:28.680
Salary!

00:49:28.680 --> 00:49:29.820
Ja genau, genau

00:49:29.820 --> 00:49:34.100
euch vielleicht auch, mich hat es auf jeden Fall

00:49:34.100 --> 00:49:36.160
vor ein paar Tagen gewissen, mal wieder

00:49:36.160 --> 00:49:38.240
als ich irgendwie dachte

00:49:38.240 --> 00:49:38.900
so irgendwie

00:49:38.900 --> 00:49:41.160
seltsam ruhig hier so alles

00:49:41.160 --> 00:49:44.160
irgendwie passiert da zu wenig

00:49:44.160 --> 00:49:46.020
auf dem Produktionssystem, wie kommt denn das

00:49:46.020 --> 00:49:47.060
und ich hatte gerade irgendwie released

00:49:47.060 --> 00:49:49.460
und guckte dann halt so in die Logfase

00:49:49.460 --> 00:49:51.780
was sind denn die ganzen Satellit-Tasks

00:49:51.780 --> 00:49:53.440
wo sind die

00:49:53.440 --> 00:49:54.920
was

00:49:54.920 --> 00:49:57.800
warum werden da keine Satellit-Tasks mehr aufgeführt

00:49:57.800 --> 00:49:59.620
und dann hab ich so ein bisschen gegoogelt

00:49:59.620 --> 00:50:02.940
und dann ja, jetzt, ich glaube 4.4.7 war das oder so, hat irgendeine Regression,

00:50:03.200 --> 00:50:05.180
eine böse Regression drin gehabt, dass halt die

00:50:05.180 --> 00:50:09.120
Salary Broker URL oder so aus den Settings nicht mehr benutzt wird.

00:50:10.060 --> 00:50:13.760
Und ja, ich weiß nicht, wie viele Produktionssysteme das weltweit gebrochen hat.

00:50:13.980 --> 00:50:14.880
Es dürften viele gewesen sein.

00:50:16.120 --> 00:50:17.240
Ja, ein netter Tag, ja.

00:50:18.000 --> 00:50:21.320
Und dann habe ich wieder downgradet auf 4.4.6 oder so was und dann war es wieder okay.

00:50:21.460 --> 00:50:25.400
Aber so wow, okay, das war schon, naja.

00:50:25.400 --> 00:50:27.020
Ich muss mir mal Jungle Q angucken.

00:50:27.020 --> 00:50:31.720
Eine Sache

00:50:31.720 --> 00:50:34.960
die eigentlich total

00:50:34.960 --> 00:50:36.860
selbstverständlich ist, die ich aber

00:50:36.860 --> 00:50:39.040
für mich persönlich erst relativ spät erkannt habe

00:50:39.040 --> 00:50:40.960
ist, wenn man

00:50:40.960 --> 00:50:42.760
also man hat eine Funktion

00:50:42.760 --> 00:50:44.600
also man hat einen Service, man hat eine

00:50:44.600 --> 00:50:46.780
höher levelige Funktion, die man

00:50:46.780 --> 00:50:48.920
testen möchte und darunter laufen noch andere Sachen

00:50:48.920 --> 00:50:50.620
zum Beispiel, das können jetzt API-Calls sein

00:50:50.620 --> 00:50:53.040
da kam ich jetzt gerade drauf wegen den externen Sachen mit den Files

00:50:53.040 --> 00:50:54.920
aber auch andere Sachen, die tendenziell

00:50:54.920 --> 00:50:56.400
noch länger laufen und

00:50:56.400 --> 00:51:03.020
und wenn man den Aufruf der unterliegenden Funktion einfach mockt,

00:51:03.660 --> 00:51:05.660
dann spart man natürlich einen ganzen Haufen Zeit,

00:51:05.740 --> 00:51:07.760
weil der halt dann nicht versucht eine API anzusprechen,

00:51:07.820 --> 00:51:09.360
weil man irgendwie die API mocken muss oder keine Ahnung was,

00:51:09.440 --> 00:51:11.480
sondern man sagt einfach, das Ding gibt 27 zurück und gut ist.

00:51:12.580 --> 00:51:14.640
Und auf der anderen Seite werden die Tests natürlich auch deutlich besser,

00:51:15.000 --> 00:51:18.060
weil man isoliert nun den Teil testet, den man eigentlich testen möchte.

00:51:18.500 --> 00:51:20.180
Du musst jetzt einfach noch kurz neu antreten.

00:51:20.340 --> 00:51:22.420
Einmal musst du ganz kurz erklären, was überhaupt Services sind,

00:51:22.520 --> 00:51:24.280
vielleicht für alle Menschen, die das noch nicht so benutzt haben.

00:51:24.280 --> 00:51:48.960
Okay, also Django bringt da keinen Pattern mit, wo man Logik hinpackt. Es gibt Manager für Datenbank-Querys, es gibt Models, es gibt Views, oder 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:48.960 --> 00:51:50.080
Utils, Helpers.

00:51:51.100 --> 00:51:52.820
Ne, das ist auch Utils.

00:51:52.980 --> 00:51:54.740
Immer wenn du ein Modul hast, das Utils heißt.

00:51:55.760 --> 00:51:57.440
Schon so ein...

00:51:57.440 --> 00:51:58.620
Tatsächlich auf der

00:51:58.620 --> 00:52:00.580
Kopenhagener DjangoCon

00:52:00.580 --> 00:52:01.500
letztes Jahr.

00:52:01.600 --> 00:52:03.260
Jetzt muss ich meine ganze Applikation

00:52:03.260 --> 00:52:04.400
und das weiß ich nicht.

00:52:05.480 --> 00:52:07.380
Ich weiß, ich habe selber solche,

00:52:07.660 --> 00:52:09.900
aber eigentlich ist es keine gute Idee.

00:52:10.340 --> 00:52:11.280
Weil das Problem ist halt,

00:52:11.520 --> 00:52:14.340
was sagt dir das, wenn du bei irgendjemandem siehst,

00:52:14.400 --> 00:52:16.240
da liegt halt ein Utils-Modul rum.

00:52:16.240 --> 00:52:17.240
Was ist da drin?

00:52:17.240 --> 00:52:19.160
als möglicher Unsinn.

00:52:19.480 --> 00:52:20.160
Ja, weißt du halt nicht.

00:52:20.380 --> 00:52:23.240
Das ist gar nicht so gut, wenn du da verkrummlicht und weißt nicht, was das ist.

00:52:23.780 --> 00:52:24.720
Tatsächlich gab es da auch

00:52:24.720 --> 00:52:27.220
einen Vortrag auf der letzten JungleCon

00:52:27.220 --> 00:52:28.860
in Kopenhagen, wo dann auch ein paar Franzosen

00:52:28.860 --> 00:52:30.900
glaube ich drüber geredet haben, dass sie halt

00:52:30.900 --> 00:52:32.880
das Konzept vermissen, dass das nicht offiziell

00:52:32.880 --> 00:52:34.940
in der Doku drin steht, macht das so, weil

00:52:34.940 --> 00:52:36.980
es halt sehr viele Leute so machen, dass man einfach eine Klasse

00:52:36.980 --> 00:52:39.020
anlegt, die kann man dann einsortieren, die kann man sinnvoll benennen

00:52:39.020 --> 00:52:41.200
und dass man

00:52:41.200 --> 00:52:43.260
da dann halt seinen Code

00:52:43.260 --> 00:52:44.500
irgendwo sinnvoll parken kann

00:52:44.500 --> 00:52:47.060
und dann auch, ich meine,

00:52:47.060 --> 00:52:49.160
das ist halt so eine Art Best Practice, das hat kein offizielles Django-Pattern

00:52:49.160 --> 00:52:51.280
aber ich glaube, das gilt inzwischen als Best Practice

00:52:51.280 --> 00:52:53.560
korrigier mich, wenn du es anders siehst

00:52:53.560 --> 00:52:53.800
aber

00:52:53.800 --> 00:52:56.580
ich weiß, hörst du es nicht

00:52:56.580 --> 00:52:58.640
es ist aber nicht diese Geschichte

00:52:58.640 --> 00:53:01.100
wo irgendwelche Leute versucht haben, den ORM

00:53:01.100 --> 00:53:02.800
so ein bisschen weg zu abstrahieren

00:53:02.800 --> 00:53:05.560
da gab es mal, genau, auch auf Django News

00:53:05.560 --> 00:53:06.620
die haben auch da Werbung gemacht

00:53:06.620 --> 00:53:09.580
die haben das auch irgendwie Services genannt

00:53:09.580 --> 00:53:10.680
aber ich glaube, das war was anderes

00:53:10.680 --> 00:53:12.280
es ging, das war dieses Projekt, irgendwie

00:53:12.280 --> 00:53:14.520
Maintaining a Django Project over 10.000 Commits

00:53:14.520 --> 00:53:15.360
oder sowas hieß das

00:53:45.360 --> 00:54:15.340
und die Programmiersprache Python.

00:54:15.360 --> 00:54:17.100
heute ist, nicht heute, sondern irgendwann anders.

00:54:17.160 --> 00:54:18.640
Montag. Genau.

00:54:21.200 --> 00:54:21.580
Und man kann

00:54:21.580 --> 00:54:22.900
aber auch... Trageproduktiv.

00:54:23.120 --> 00:54:25.360
Man kann aber auch einen Mockblock verwenden,

00:54:25.740 --> 00:54:27.280
das heißt, man kann einfach dann sagen,

00:54:27.700 --> 00:54:29.280
alles, was in diesem Mockblock

00:54:29.280 --> 00:54:31.180
passiert, wenn da eine

00:54:31.180 --> 00:54:33.440
bestimmte Funktion aufgerufen wird, füllt ihr die nicht aus,

00:54:33.580 --> 00:54:35.180
sondern gibt einen

00:54:35.180 --> 00:54:37.180
festen Wert zurück. Zum Beispiel, wenn man eine

00:54:37.180 --> 00:54:39.040
Funktion hat, LoadData vom API

00:54:39.040 --> 00:54:41.060
oder sowas, kann man einfach sagen, das gibt

00:54:41.060 --> 00:54:42.360
ein fixes JSON zurück.

00:54:42.740 --> 00:54:44.120
Ein Mockblock. Schön.

00:54:45.360 --> 00:54:46.320
Ja, sagt man, oder?

00:54:49.500 --> 00:54:50.400
Und wie gesagt,

00:54:50.860 --> 00:54:53.460
wenn man das Mocking einmal gesehen hat,

00:54:53.480 --> 00:54:55.220
ist es eigentlich total offensichtlich, aber ich habe halt

00:54:55.220 --> 00:54:57.500
irgendwie nie so realisiert oder lange nicht realisiert,

00:54:58.060 --> 00:54:59.380
dass es halt einerseits total viel

00:54:59.380 --> 00:55:01.400
Zeit sparen kann und andererseits auch noch

00:55:01.400 --> 00:55:03.280
deinen Testcode verbessert,

00:55:03.360 --> 00:55:05.420
weil dadurch, dass halt die unterliegende Funktion

00:55:05.420 --> 00:55:07.380
einen festen Rückgabewert hat, wenn da jetzt

00:55:07.380 --> 00:55:09.000
ein Fehler drin ist, dann

00:55:09.000 --> 00:55:11.400
tangiert das halt nicht die

00:55:11.400 --> 00:55:13.180
anderen Sachen, sondern die Funktionen, die ja hoffentlich

00:55:13.180 --> 00:55:15.360
auch getestet sind, failen dann isoliert

00:55:15.360 --> 00:55:17.300
und man hat dann nachher nicht irgendwie 50

00:55:17.300 --> 00:55:19.260
gefailte Tests, man muss erstmal anfangen zu suchen,

00:55:19.400 --> 00:55:21.400
sondern im Optimalfall, wenn alles isoliert genug ist,

00:55:21.680 --> 00:55:22.800
fällt genau der Test ja nicht mehr

00:55:22.800 --> 00:55:25.540
das bringt, was er möchte

00:55:25.540 --> 00:55:27.020
und

00:55:27.020 --> 00:55:29.440
diesen Doppelwin, das fand ich

00:55:29.440 --> 00:55:31.440
echt ziemlich neat,

00:55:31.760 --> 00:55:33.640
das

00:55:33.640 --> 00:55:34.560
nochmal so zu realisieren.

00:55:37.860 --> 00:55:39.540
Ja, nee, klingt gut. Also ich

00:55:39.540 --> 00:55:41.260
packe meistens meine Logik irgendwie so

00:55:41.260 --> 00:55:43.620
in den Model-Layer,

00:55:43.840 --> 00:55:44.320
mehr oder weniger.

00:55:45.040 --> 00:55:47.500
Oder beziehungsweise

00:55:47.500 --> 00:55:48.360
dann halt in Mixins,

00:55:48.360 --> 00:55:50.440
die dann halt

00:55:50.440 --> 00:55:51.660
Models aufblähen.

00:55:52.460 --> 00:55:54.560
Ja, ich dann auch oft, wenn es dann zu lang wird,

00:55:54.640 --> 00:55:56.260
stecke ich halt in andere Files und importiere die

00:55:56.260 --> 00:55:57.720
dann aus Models.py dann halt da rein.

00:55:58.620 --> 00:55:59.280
Genau, aber

00:55:59.280 --> 00:56:01.800
ja, ich weiß auch noch nicht so genau.

00:56:01.880 --> 00:56:03.320
Ich muss mal in den Vortrag gucken.

00:56:04.400 --> 00:56:04.760
Genau.

00:56:06.120 --> 00:56:07.340
Es gibt verschiedene Meinungen dazu, glaube ich.

00:56:08.340 --> 00:56:10.200
Definitiv. Das ist vielleicht auch der Grund, warum das noch nicht

00:56:10.200 --> 00:56:11.240
in der Dango-Doku gelandet ist.

00:56:11.420 --> 00:56:13.700
Ja, bei TwoScoops sagt ja auch, dass total katastrophal für Fatmodels,

00:56:13.760 --> 00:56:15.920
aber ich finde das eigentlich auch gar nicht so schlecht, weil ich es bei Jochen gesehen habe,

00:56:16.000 --> 00:56:17.900
natürlich, dass man da viele gute

00:56:17.900 --> 00:56:19.880
Dinge reinpackt, die halt da hingehören irgendwie.

00:56:20.380 --> 00:56:21.860
So vom Gefühl her machen die halt Sachen mit der

00:56:21.860 --> 00:56:22.580
Datenbank oder so.

00:56:24.560 --> 00:56:25.500
Ich mag das auch.

00:56:25.500 --> 00:56:27.480
Also ich würde es nicht sagen, ich mache jetzt

00:56:27.480 --> 00:56:29.520
da ist alles dran, weil wie gesagt, ich finde das Service-Prinzip

00:56:29.520 --> 00:56:31.460
ganz nett und mag das

00:56:31.460 --> 00:56:32.480
auch ganz gern, aber

00:56:32.480 --> 00:56:35.600
die sind auf jeden Fall nicht dünn, die Models, die ich baue.

00:56:37.600 --> 00:56:37.780
Ja.

00:56:37.780 --> 00:56:39.800
Ja, aber wir hatten

00:56:39.800 --> 00:56:41.560
nochmal ganz kurz über das Mocken geredet und ich glaube

00:56:41.560 --> 00:56:43.500
Mocken ist auch was, was noch sehr interessant ist

00:56:43.500 --> 00:56:45.780
weil man kann natürlich alles

00:56:45.780 --> 00:56:47.920
Mocken und so tun, als gäbe es irgendeine Umgebung

00:56:47.920 --> 00:56:49.980
und dann da testen, ob dann das, was man

00:56:49.980 --> 00:56:51.800
so geschrieben hat, für diese isolierte Umgebung

00:56:51.800 --> 00:56:53.800
dann funktioniert. Ja, und dann funktioniert es in der Realität

00:56:53.800 --> 00:56:55.700
nicht mehr, weil der Mock halt anders aussieht als die Realität

00:56:55.700 --> 00:56:58.080
Ja, genau, und vielleicht ist das eines der Probleme

00:56:58.080 --> 00:56:59.980
also ich habe das schon öfter mal mitbekommen, dass gerade

00:56:59.980 --> 00:57:01.660
Menschen, die irgendwie viel Coverage erreichen wollen

00:57:01.660 --> 00:57:03.200
und irgendwie sich dann mit vielen Mocks

00:57:03.200 --> 00:57:05.980
also es gab sogar Menschen, die haben jetzt dann Screenshots

00:57:05.980 --> 00:57:07.360
von den Webseiten irgendwie

00:57:07.360 --> 00:57:07.360


00:57:07.360 --> 00:57:10.320
besorgt und dann geguckt, ob die dann am Ende

00:57:10.320 --> 00:57:12.080
genauso aussieht, weil sie dann irgendwie Templates noch

00:57:12.080 --> 00:57:13.760
versucht haben zu generieren und

00:57:13.760 --> 00:57:16.000
dann die Bilder miteinander verglichen haben

00:57:16.000 --> 00:57:18.260
und solche Sachen, also wirklich abgefahrener

00:57:18.260 --> 00:57:18.400
Quart.

00:57:19.520 --> 00:57:19.840
Ja,

00:57:20.640 --> 00:57:22.180
mockt ihr überhaupt irgendwas oder

00:57:22.180 --> 00:57:23.740
findest du das anstrengend oder

00:57:23.740 --> 00:57:24.980
dann macht man das.

00:57:25.460 --> 00:57:27.240
Ich benutze das

00:57:27.240 --> 00:57:30.280
sehr häufig und ja, muss man

00:57:30.280 --> 00:57:32.200
auch, denke ich, also gerade wenn man irgendwie APIs

00:57:32.200 --> 00:57:34.200
fragt oder so mit externen

00:57:34.200 --> 00:57:36.300
sonstigen Systemen redet, dann geht das ja quasi gar nicht anders.

00:57:36.300 --> 00:57:41.840
Das heißt, du musst extern Antworten von Dingen, die du nicht im Test eigentlich abbilden kannst, die musst du dann tatsächlich emulieren.

00:57:41.880 --> 00:57:43.940
Die muss man immer bocken, das geht gar nicht anders.

00:57:44.080 --> 00:57:47.800
Ja gut, das sind Abfragen von extern ab, hier kann man sich tatsächlich vorstellen, dass das sinnhaft sein kann.

00:57:48.400 --> 00:57:55.640
Ich mache es tatsächlich bei Daten enorm viel, weil das halt einfach, also das ist nicht schlimmer, als wenn du irgendwie am Freitag einen Test ausführst und plötzlich geht er nicht mehr.

00:57:55.680 --> 00:57:56.260
Was sind Daten?

00:57:56.940 --> 00:57:57.560
Also Datums.

00:57:58.220 --> 00:58:00.660
Ja, ja, okay, das ist ein bisschen schwierig im Deutschen.

00:58:00.660 --> 00:58:00.660


00:58:03.220 --> 00:58:04.260
Irgendwelche Zeiten,

00:58:04.800 --> 00:58:06.020
das ist total super.

00:58:06.760 --> 00:58:08.340
Man kann auch mit diesem,

00:58:08.480 --> 00:58:10.680
das heißt Freescan, das Tool, mit dem man das

00:58:10.680 --> 00:58:12.520
machen kann, und da kann man halt auch

00:58:12.520 --> 00:58:14.500
einen Block machen, also sprich alles, was eingerückt

00:58:14.500 --> 00:58:15.940
unter diesem with-Tag ist,

00:58:17.200 --> 00:58:18.580
kriegt dann einen anderen

00:58:18.580 --> 00:58:20.500
Timestamp, was halt sehr praktisch ist. Man kann das als Decorator

00:58:20.500 --> 00:58:23.140
verwenden, zum Beispiel sagen, heute ist der 26.6.

00:58:24.600 --> 00:58:26.620
Obwohl das, also egal, wann der Test läuft.

00:58:26.940 --> 00:58:28.140
Und wenn man jetzt zum Beispiel sagt, ich möchte

00:58:28.140 --> 00:58:30.380
Objekte erstellen mit einem bestimmten Timestamp,

00:58:30.660 --> 00:58:32.920
dann

00:58:32.920 --> 00:58:35.860
kann ich halt das in diesem

00:58:35.860 --> 00:58:37.960
WhistHack machen, obwohl der ganze Test sagt

00:58:37.960 --> 00:58:39.180
ich bin am 26.06.

00:58:40.120 --> 00:58:42.000
kann ich dann trotzdem sagen, dieser Subjekt ist aber schon

00:58:42.000 --> 00:58:43.880
zwei Jahre alt, das ist halt ziemlich praktisch

00:58:43.880 --> 00:58:45.780
wenn man da so zwei, drei Dinge verstanden hat

00:58:45.780 --> 00:58:47.420
dann kann man sich das Leben sehr leicht machen

00:58:47.420 --> 00:58:49.940
ansonsten, das Mocken nutze ich

00:58:49.940 --> 00:58:51.200
viel weniger als

00:58:51.200 --> 00:58:53.340
als man es wahrscheinlich sollte

00:58:53.340 --> 00:59:06.660
ich nutze es halt f APIs also f externe Sachen die ich halt mocken muss auf Unit oder Functional und ansonsten wenn ich halt eine Funktion habe die halt sehr lange l wo ich halt wei ich will die nicht jedes Mal durchjubeln auf allen

00:59:06.660 --> 00:59:08.560
höheren Ebenen, weil mir das einfach

00:59:08.560 --> 00:59:09.200
zu lange dauert.

00:59:10.660 --> 00:59:12.460
Aber wahrscheinlich wäre es sinnvoll, das mehr zu machen, obwohl

00:59:12.460 --> 00:59:13.800
natürlich du auch vollkommen recht hast,

00:59:14.440 --> 00:59:16.320
umso mehr man sich irgendwie da seine

00:59:16.320 --> 00:59:18.420
Fantasiewelt aufbaut, umso weiter weg

00:59:18.420 --> 00:59:19.880
bist du auch irgendwann natürlich von der Realität.

00:59:19.880 --> 00:59:20.340
Mhm.

00:59:20.340 --> 00:59:27.820
Ja, also User-Input oder sowas, das kann man ja auch in Frontend weiterdenken, was man halt irgendwie alles dann mocken kann.

00:59:28.080 --> 00:59:30.220
Habt ihr viel Frontend vorgetestet? Was gibt es da?

00:59:30.780 --> 00:59:32.320
Mocha und...

00:59:32.320 --> 00:59:33.920
Nee, nicht wirklich viel, ja.

00:59:34.780 --> 00:59:40.140
So Unit-Tests im Frontend, das ist ja, glaube ich, hat sich inzwischen so Jest als der Standard etabliert so ein bisschen.

00:59:41.080 --> 00:59:44.700
Reden wir jetzt von JavaScript oder reden wir von normalen Django-Templaten?

00:59:44.860 --> 00:59:45.180
JavaScript.

00:59:46.320 --> 00:59:48.560
Ich bin bei Frontend da direkt immer schon bei JavaScript.

00:59:48.560 --> 00:59:49.880
Ja, ja, eh, aber...

00:59:49.880 --> 00:59:50.920
Ja, leider, leider, ja.

00:59:51.080 --> 00:59:53.820
Aber vielleicht ist das der selbe Thema.

00:59:55.520 --> 00:59:56.500
Ja, meintest du denn

00:59:56.500 --> 00:59:57.420
Django-Templates?

00:59:57.540 --> 00:59:59.060
Nein, ich meine tatsächlich

00:59:59.060 --> 01:00:02.480
JavaScript und Mutter und so, was man da alles so bauen kann.

01:00:02.880 --> 01:00:04.380
Ja, also ich würde sagen,

01:00:04.420 --> 01:00:05.900
da gibt es halt eben den Unterschied zwischen

01:00:05.900 --> 01:00:07.500
End-to-End-Tests, also so was, Hypress,

01:00:07.700 --> 01:00:09.520
oder weiß ich nicht, was Leute da noch verwenden, Selenium...

01:00:09.520 --> 01:00:11.620
Da ist wohl die neue Version heute rausgekommen, habe ich gelesen.

01:00:12.960 --> 01:00:14.240
Ah ja, habe ich gar nicht

01:00:14.240 --> 01:00:15.820
bekommen, ja. Cool.

01:00:17.140 --> 01:00:18.200
Ja, und ich habe

01:00:18.200 --> 01:00:48.180
und Jochen unterhalten sich über die Programmiersprache Python

01:00:48.200 --> 01:00:51.140
Ja, man kann halt auch tatsächlich andersrum anfangen

01:00:51.140 --> 01:00:53.340
und kann sagen, man baut zuerst seine Tests

01:00:53.340 --> 01:00:55.420
Das nennt man dann Test-Driven Development

01:00:55.420 --> 01:00:57.120
und wenn man erst die Tests hat

01:00:57.120 --> 01:00:59.080
die alle verschiefen gehen und dann den Code baut

01:00:59.080 --> 01:01:00.620
Was haltet ihr denn davon?

01:01:00.720 --> 01:01:02.800
Also für mich finde das immer sehr verwirrend

01:01:02.800 --> 01:01:04.140
sowas zu tun, weil

01:01:04.140 --> 01:01:07.040
um das zu tun, also erst Tests zu bauen, dann müsste ich erstmal

01:01:07.040 --> 01:01:08.660
wissen, was meine Anwendung überhaupt machen soll

01:01:08.660 --> 01:01:11.040
oder macht, um dann Tests bauen zu können

01:01:11.040 --> 01:01:13.260
wo die dann diese hypothetische Anwendung bestimmen können

01:01:13.260 --> 01:01:15.380
und das alleine ist schon ziemlich herausfordernd

01:01:15.380 --> 01:01:15.700
finde ich

01:01:15.700 --> 01:01:18.680
Ja

01:01:18.680 --> 01:01:22.720
ehrlich gesagt, ich habe das noch nie so wirklich

01:01:22.720 --> 01:01:24.780
probiert, weil ich immer dachte

01:01:24.780 --> 01:01:27.080
ich muss das vielleicht mal machen

01:01:27.080 --> 01:01:28.720
tatsächlich mal versuchen, wie es ist

01:01:28.720 --> 01:01:30.900
Test Driven zu entwickeln, aber ja

01:01:30.900 --> 01:01:32.760
da ist die Idee ja im Grunde, dass du genau erst

01:01:32.760 --> 01:01:35.020
immer den Test schreibst und dann erst den Code

01:01:35.020 --> 01:01:36.940
und man hört dann halt auf, wenn der Test

01:01:36.940 --> 01:01:39.000
funktioniert, aber

01:01:39.000 --> 01:01:41.000
also gerade auch

01:01:41.000 --> 01:01:42.780
bei Django, ich fange meistens

01:01:42.780 --> 01:01:44.900
wenn ich anfange irgendwas zu

01:01:44.900 --> 01:01:46.580
schreiben, schreibe ich erstmal das in einem

01:01:46.580 --> 01:01:47.260
Jupyter-Notebook.

01:01:48.460 --> 01:01:50.700
Weil, genau, also da gibt es halt

01:01:50.700 --> 01:01:52.520
es gibt ja die Django

01:01:52.520 --> 01:01:54.720
Shell Plus zum Beispiel, den Django Extensions,

01:01:55.200 --> 01:01:56.620
wo man halt die ganzen Modelle schon

01:01:56.620 --> 01:01:58.500
drin hat sozusagen. Das gibt es halt auch

01:01:58.500 --> 01:02:00.280
in der Jupyter

01:02:00.280 --> 01:02:01.420
Frontend.

01:02:02.480 --> 01:02:04.700
Und man hat dann quasi so eine Umgebung wie in der

01:02:04.700 --> 01:02:06.260
Shell Plus, bloß halt mit dem ganzen anderen

01:02:06.260 --> 01:02:08.720
Jupyter-Kram drumherum. Genau, man kann halt die ganzen Teile immer wieder

01:02:08.720 --> 01:02:10.700
ausführen. Genau, dann probiere ich halt

01:02:10.700 --> 01:02:12.640
so lange rum, bis ich weiß, dass es ungefähr

01:02:12.640 --> 01:02:13.820
das tut, was ich gerne hätte.

01:02:14.900 --> 01:02:15.540
und

01:02:15.540 --> 01:02:17.680
weil man so Funktionen machen möchte, die

01:02:17.680 --> 01:02:19.760
die Modell-Sachen machen

01:02:19.760 --> 01:02:21.360
oft Sachen muss man halt irgendwie ausprobieren

01:02:21.360 --> 01:02:23.480
das geht nicht, dann muss man es irgendwie anders machen

01:02:23.480 --> 01:02:25.600
und damit geht das

01:02:25.600 --> 01:02:26.920
eigentlich tatsächlich sehr sehr

01:02:26.920 --> 01:02:29.440
schön, während man halt

01:02:29.440 --> 01:02:31.280
wenn man das jetzt tatsächlich direkt in Code schreiben würde

01:02:31.280 --> 01:02:33.300
müsste man das immer irgendwie ausführen

01:02:33.300 --> 01:02:35.780
man müsste jetzt erstmal an die Stelle kommen, wo das dann ausgeführt wird

01:02:35.780 --> 01:02:37.500
und das ist halt immer ein bisschen

01:02:37.500 --> 01:02:38.900
schwieriger

01:02:38.900 --> 01:02:41.040
und im Notebook hast du das halt

01:02:41.040 --> 01:02:43.140
da änderst du dann mit deinem Code-Fist nochmal die Zelle aus

01:02:43.140 --> 01:02:44.440
und weißt dann, okay, jetzt passt's

01:02:44.440 --> 01:02:46.400
und dann, also meistens, also da

01:02:46.400 --> 01:02:48.480
fange ich an, Sachen zu basteln und wenn das

01:02:48.480 --> 01:02:49.940
dann halt so halbwegs passt,

01:02:50.780 --> 01:02:52.240
dann überführe ich es halt in

01:02:52.240 --> 01:02:54.100
tatsächlich

01:02:54.100 --> 01:02:55.980
Django-App-Code irgendwo

01:02:55.980 --> 01:02:57.900
und dann fange ich meistens dann auch Tests

01:02:57.900 --> 01:03:00.160
zu schreiben. Manchmal stelle ich dann noch was um,

01:03:00.780 --> 01:03:01.800
weil es irgendwie

01:03:01.800 --> 01:03:04.280
dann einfacher ist zu testen oder so, aber oft

01:03:04.280 --> 01:03:06.040
ist es dann auch mehr oder weniger dann schon so fertig.

01:03:06.300 --> 01:03:08.580
Das heißt, das Test-Driven ist quasi gar nicht

01:03:08.580 --> 01:03:10.000
erst Testschreiben

01:03:10.000 --> 01:03:12.460
bei dir, sondern eher so Experimente

01:03:12.460 --> 01:03:14.300
machen in so einem Notebook, die

01:03:14.300 --> 01:03:44.280
und Jochen unterhalten sich über die Programmiersprache Python

01:03:44.300 --> 01:03:45.300
und er weiß, in welche Richtung man möchte.

01:03:47.080 --> 01:03:48.580
Ja, also insofern

01:03:48.580 --> 01:03:49.100
habe ich das,

01:03:49.820 --> 01:03:51.700
wie ich das momentan mache, aber

01:03:51.700 --> 01:03:54.300
wäre vielleicht auch mal ganz interessant, Test-Driven

01:03:54.300 --> 01:03:55.880
Development mal so wirklich auszuprobieren

01:03:55.880 --> 01:03:57.960
oder mal gezeigt zu bekommen von jemandem, der das so wirklich kann.

01:03:58.320 --> 01:04:00.340
Aber ja, daher ist das bei mir

01:04:00.340 --> 01:04:02.160
eigentlich nie. Das ist das, was quasi dann

01:04:02.160 --> 01:04:04.380
im Applikationscode in einer

01:04:04.380 --> 01:04:05.920
General App landet, eigentlich meistens schon

01:04:05.920 --> 01:04:08.260
relativ fertig und die Tests, die dazu

01:04:08.260 --> 01:04:10.260
also meistens weiß ich dann auch schon, welche Tests

01:04:10.260 --> 01:04:11.940
ich dann schreiben muss und dann

01:04:11.940 --> 01:04:13.320
ja,

01:04:13.320 --> 01:04:18.040
Macht ihr Tests, Silvan, die wir da machen sollen?

01:04:18.520 --> 01:04:20.280
Es gibt ein paar Leute bei uns, die das machen

01:04:20.280 --> 01:04:22.300
Ich persönlich mache es nicht

01:04:22.300 --> 01:04:27.160
Ich bin da ähnlich wie Jochen, dass ich denke, ich sollte es eigentlich

01:04:27.160 --> 01:04:30.120
mir nochmal im Detail angeschaut haben und nochmal vernünftig zeigen lassen

01:04:30.120 --> 01:04:35.680
Mein Jupyter Notebook ist halt, dass ich meistens mit aktivem Debugger arbeite

01:04:35.680 --> 01:04:39.020
Also sprich, ich springe mit dem Debugger in den Code, soweit ich bin

01:04:39.020 --> 01:04:41.580
Debugger heißt also, welche Entwicklungs-Mitgeben benutzt du?

01:04:41.580 --> 01:04:43.380
von IntelliJ.

01:04:44.240 --> 01:04:45.740
Und ich habe mir das

01:04:45.740 --> 01:04:48.040
irgendwann mal angefangen

01:04:48.040 --> 01:04:49.820
anzugewöhnen, weil das Schöne ist, du kannst halt

01:04:49.820 --> 01:04:51.640
dann mit diesem Evaluate Expression

01:04:51.640 --> 01:04:53.520
im Debugger, kannst du halt direkt Sachen

01:04:53.520 --> 01:04:56.040
testen und ausprobieren. Also sprich, wenn du dir nicht ganz sicher bist,

01:04:56.100 --> 01:04:57.800
zum Beispiel, ob eine Query das zurückgibt oder

01:04:57.800 --> 01:05:00.020
wenn man jetzt irgendein komplizierteres Aggregate

01:05:00.020 --> 01:05:01.280
macht, geht das, funktioniert das wirklich?

01:05:01.800 --> 01:05:03.520
Und solange man nicht versehentlich auf

01:05:03.520 --> 01:05:05.600
Steuerung ist, also Speichern drückt und die Seite

01:05:05.600 --> 01:05:07.800
neu lädt und dann der Debugger neu startet,

01:05:08.620 --> 01:05:10.100
hat man halt den Debugger,

01:05:10.100 --> 01:05:11.960
auch wenn man da ganz viele Änderungen macht und

01:05:11.960 --> 01:05:14.540
kann sich dann natürlich irgendwelche Zwischenstates in eine neue Variable

01:05:14.540 --> 01:05:15.460
speichern und weitermachen.

01:05:16.920 --> 01:05:18.440
Das ist ein sehr interessanter Ansatz, würde ich gerne

01:05:18.440 --> 01:05:19.860
tatsächlich mal live sehen. Also weil

01:05:19.860 --> 01:05:22.040
ich glaube so ein bisschen macht der Jochen das

01:05:22.040 --> 01:05:24.200
und ich mache das auch ein bisschen mit den Notebooks,

01:05:24.280 --> 01:05:25.820
weil du da halt auch immer diese Iterationen unterhalten hast

01:05:25.820 --> 01:05:28.160
und auch, also ich benutze

01:05:28.160 --> 01:05:29.080
VS Code manchmal,

01:05:29.800 --> 01:05:31.820
da kann man das ja auch machen mit dem Debugger,

01:05:32.040 --> 01:05:34.180
den ich aber selten für sowas benutze, also nur wirklich wenn ich ein Problem

01:05:34.180 --> 01:05:35.540
habe, was ich so nicht so einfach verstehe,

01:05:36.020 --> 01:05:37.960
dann gucke ich da mal rein und Python macht das.

01:05:38.160 --> 01:05:39.660
Für mich persönlich, also

01:05:39.660 --> 01:06:09.660
Mir geht es ein bisschen so, wie das verstanden hat bei euch beiden auch. Ich weiß halt am Anfang meistens nicht so genau, was nachher rauskommt. Die meisten Sachen, die man ja so zu testen hat, sind ja dann bei mir jetzt in Services und ich weiß halt einfach nicht, wie der Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service

01:06:09.660 --> 01:06:25.100
Bound Service, also eine Klasse, packt da einen Process rein und überlegt 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, zieh 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:25.100 --> 01:06:28.520
und ich müsste halt sehr meine Denke umstellen,

01:06:29.120 --> 01:06:32.360
wenn ich halt erst mir überlege, was möchte ich denn eigentlich so genau alles testen,

01:06:32.420 --> 01:06:35.320
also was kommt nachher alles raus, weil teilweise manchmal habe ich auch,

01:06:35.800 --> 01:06:38.380
wenn ich anfange, eine ganz andere Idee von dem, was nachher rauskommt,

01:06:38.420 --> 01:06:40.540
was ich nachher habe, weil ich nachher eine gute Idee habe und merke,

01:06:40.620 --> 01:06:44.580
das könnte man vielleicht alles besser, schneller, effizienter, komplett anders machen.

01:06:46.200 --> 01:06:50.360
Also ich denke, TDD ist auf jeden Fall ein sehr hehres Ziel, das zu machen

01:06:50.360 --> 01:06:53.440
und ich glaube auch, dass Leute, die, sag ich mal, programmieren lernen,

01:06:53.440 --> 01:06:56.840
das auch bestimmt nicht verkehrt ist, wenn die so anfangen?

01:06:56.880 --> 01:06:58.740
Ne, ich glaube, das ist für sich ganz anders.

01:06:58.840 --> 01:07:00.800
Weil die Leute wissen gar nicht, was sie bauen können.

01:07:01.100 --> 01:07:03.000
Und wenn die dann klären, dann wenn die Tests schreiben,

01:07:03.060 --> 01:07:04.080
die sind sowas von überfordert.

01:07:04.100 --> 01:07:06.700
Okay, ich formuliere um. Für Leute, die schon programmieren können,

01:07:06.840 --> 01:07:08.500
aber jetzt sage ich mal so ein bisschen mehr in die, also

01:07:08.500 --> 01:07:10.560
die so, sage ich mal so, dass das Grund

01:07:10.560 --> 01:07:12.600
Handwerk verstehen und jetzt anfangen

01:07:12.600 --> 01:07:14.860
dann wirklich produktiv arbeiten zu wollen.

01:07:15.140 --> 01:07:16.460
Weil zum Beispiel bei mir, als ich früher

01:07:16.460 --> 01:07:18.400
als ich

01:07:18.400 --> 01:07:20.580
angefangen habe zu programmieren und

01:07:20.580 --> 01:07:21.620
auch Python gelernt habe,

01:07:21.620 --> 01:07:21.620


01:07:21.620 --> 01:07:24.560
und da war mein Code, den ich geschrieben habe,

01:07:24.600 --> 01:07:26.060
also ich habe damals eh noch keine Unit-Tests geschrieben,

01:07:26.140 --> 01:07:26.900
ich meine, das ist auch schon lange her,

01:07:28.420 --> 01:07:31.760
aber der Code, den ich produziert habe,

01:07:31.800 --> 01:07:33.360
der war nicht gut strukturiert,

01:07:33.420 --> 01:07:34.380
der war nicht gut testbar.

01:07:34.820 --> 01:07:36.040
Und wenn du halt TDD machst,

01:07:36.100 --> 01:07:37.800
dann wirst du halt von Anfang an gezwungen,

01:07:37.940 --> 01:07:39.420
dass dein Code die richtige Struktur hat,

01:07:39.460 --> 01:07:40.380
weil du merkst halt sofort,

01:07:40.540 --> 01:07:41.740
oh, der Code, den kann ich nicht testen,

01:07:41.820 --> 01:07:42.360
weil du hast...

01:07:42.360 --> 01:07:43.480
Aber du hast jetzt gerade einen Bias drin gehabt,

01:07:43.500 --> 01:07:44.680
du hast gesagt, die richtige Struktur.

01:07:44.960 --> 01:07:46.020
Du hast gesagt, dass die Struktur,

01:07:46.100 --> 01:07:47.660
die man gut testen kann, die richtige wäre.

01:07:47.720 --> 01:07:49.180
Ja, okay, eine bessere.

01:07:49.420 --> 01:07:49.880
Eine bessere.

01:07:49.880 --> 01:07:50.300
Aha.

01:07:50.300 --> 01:07:52.340
aber ich glaube auf jeden Fall, dass Code, der

01:07:52.340 --> 01:07:54.380
nicht testbar ist, nicht so richtig

01:07:54.380 --> 01:07:55.140
guter Code ist.

01:07:56.500 --> 01:07:57.980
Das würde ich jetzt einfach mal so posten.

01:08:01.060 --> 01:08:02.460
Und das zum Beispiel hat

01:08:02.460 --> 01:08:04.340
mir, als ich dann angefangen habe, mich intensiv mit Unit-Tests

01:08:04.340 --> 01:08:06.200
zu beschäftigen, halt sehr geholfen, auch noch mal

01:08:06.200 --> 01:08:08.380
wirklich beim Code-Schreiben

01:08:08.380 --> 01:08:09.020
auch zu überlegen,

01:08:09.440 --> 01:08:11.660
wo soll das denn alles hin?

01:08:12.080 --> 01:08:14.220
Also wenn ich halt weiß, ich möchte das

01:08:14.220 --> 01:08:16.020
irgendwie isoliert und vernünftig, also ich möchte nicht

01:08:16.020 --> 01:08:18.160
nachher drei Stunden über Tests nachdenken und irgendwelche wilden Fälle

01:08:18.160 --> 01:08:19.960
zusammenbauen, sondern ich möchte es ja einfach, es ist ja

01:08:19.960 --> 01:08:22.160
funktioniert, macht ein oder zwei Sachen, genau das möchte ich abchecken,

01:08:22.240 --> 01:08:23.460
ob das nachher rauskommt und fertig.

01:08:24.060 --> 01:08:25.960
Und wenn man halt das nur baut, dass es

01:08:25.960 --> 01:08:28.220
funktioniert und gar nicht über diese Tests nachdenkt,

01:08:28.880 --> 01:08:32.120
ja, das ist halt, glaube ich, ein Unterschied.

01:08:32.240 --> 01:08:33.900
Von daher glaube ich, kann das, also ich glaube,

01:08:33.960 --> 01:08:35.940
für Leute, die schon relativ gut wissen,

01:08:36.020 --> 01:08:37.860
was sie tun, kann das natürlich eine Verbesserung sein.

01:08:39.080 --> 01:08:39.960
Wir hatten mal

01:08:39.960 --> 01:08:42.020
vor vielen, vor zwei Jahren einen,

01:08:42.580 --> 01:08:43.960
ich sag mal, einen Python-Guru bei uns

01:08:43.960 --> 01:08:45.520
in der Firma, der mal so einen Tag lang

01:08:45.520 --> 01:08:47.920
über TDD erzählt hat und im Endeffekt

01:08:47.920 --> 01:08:49.300
querbeet alles Mögliche und

01:08:49.300 --> 01:08:54.360
und war das auch mein erster intensiverer Kontakt mit TDD.

01:08:54.620 --> 01:08:56.060
Und ich habe ihn im Nachgang auch gefragt,

01:08:56.180 --> 01:08:58.460
ich arbeite so und so, was sagst du dazu?

01:09:00.700 --> 01:09:05.440
Und er meinte im Endeffekt, es gibt halt viele Wege, die nach oben führen.

01:09:05.520 --> 01:09:07.000
Er selbst findet das gut, er macht das auch so,

01:09:07.080 --> 01:09:08.140
er hat auch irgendwann mal umgelernt.

01:09:09.360 --> 01:09:11.000
Aber für ihn zum Beispiel ist es halt wichtig,

01:09:11.120 --> 01:09:12.300
dass Testbarer Code rauskommt.

01:09:12.400 --> 01:09:15.400
Und wenn man halt selbst durch die Art, wie auch immer man da hinkommt,

01:09:15.580 --> 01:09:17.260
wenn Testbarer Code am Ende rauskommt,

01:09:17.260 --> 01:09:19.240
dann ist halt ein großer Vorteil von TDD,

01:09:19.300 --> 01:09:21.260
und die hat man halt anders erreicht. So what?

01:09:22.740 --> 01:09:23.280
Eine Sache,

01:09:23.420 --> 01:09:24.960
die ich auch ganz interessant fand, ist,

01:09:25.060 --> 01:09:27.100
bei TDD fängst du an und schreibst einen Test, der per se

01:09:27.100 --> 01:09:28.580
failen muss, weil es gibt ja noch nichts,

01:09:29.120 --> 01:09:31.060
was funktionieren kann, weil du ja mit dem Test anfängst.

01:09:31.540 --> 01:09:32.920
Und das fand ich ganz spannend. Er meinte,

01:09:34.140 --> 01:09:34.720
er findet das,

01:09:34.860 --> 01:09:36.860
das ist für ihn so die Routine,

01:09:37.020 --> 01:09:38.840
er fängt irgendwas an zu programmieren

01:09:38.840 --> 01:09:40.760
und sieht erst mal, der Test schlägt viel.

01:09:42.280 --> 01:09:43.180
Und wenn man

01:09:43.180 --> 01:09:45.240
andersrum arbeitet, dann baut man die Tests ja

01:09:45.240 --> 01:09:47.060
so, dass sie funktionieren. Also du baust ja nicht

01:09:47.060 --> 01:09:49.960
und baut einen Fehler ein, um den Test rot zu haben.

01:09:50.560 --> 01:09:51.660
Und er meinte, das ist halt ganz angenehm,

01:09:51.720 --> 01:09:53.740
dass du am Anfang siehst, okay, ich habe jetzt acht Tests gebaut,

01:09:53.800 --> 01:09:55.920
die schlagen alle acht fehl und nachher mache ich,

01:09:56.020 --> 01:09:57.660
dass sie gehen. Weil es kann halt

01:09:57.660 --> 01:09:59.600
leicht passieren, dass wenn man halt

01:09:59.600 --> 01:10:01.780
das andersrum macht, dass man halt die Tests baut

01:10:01.780 --> 01:10:03.820
und dann hat man einen Fehler drin, der Test ist versehentlich grün.

01:10:03.940 --> 01:10:04.860
Also voll positiv.

01:10:05.740 --> 01:10:07.620
Und tatsächlich ist mir das auch mal

01:10:07.620 --> 01:10:09.600
passiert in einem Projekt, da hatte ich

01:10:09.600 --> 01:10:11.480
ein Rechnungsmodul gebaut,

01:10:11.620 --> 01:10:13.760
also auch zahlungsrelevant und ziemlich heikel

01:10:13.760 --> 01:10:15.860
und irgendwie ist dann irgendwann mal,

01:10:15.860 --> 01:10:17.840
das sah auch alles immer super aus und grün und so weiter

01:10:17.840 --> 01:10:19.700
und dann irgendwann ist halt mal die InitPy

01:10:19.700 --> 01:10:21.880
weggekommen aus dem Testordner, wie auch immer

01:10:21.880 --> 01:10:24.080
und naja, dann sind die halt

01:10:24.080 --> 01:10:26.040
plötzlich mal ausgeführt von das Projekte

01:10:26.040 --> 01:10:27.880
damals glaube ich 800 Tests, die 50

01:10:27.880 --> 01:10:29.860
Tests für die Rechnungslegung, die sind halt nicht aufgefallen

01:10:29.860 --> 01:10:30.700
dass die nicht mehr drin sind

01:10:30.700 --> 01:10:33.460
und irgendwann waren dann da halt Fehler in der Rechnung

01:10:33.460 --> 01:10:35.560
und ich dann so, irgendwie kann das nicht sein

01:10:35.560 --> 01:10:37.780
ich hab das doch getestet und dann war das so

01:10:37.780 --> 01:10:39.940
ups, ich meine das trifft jetzt nicht so 100%

01:10:39.940 --> 01:10:41.580
deckungsgleich mit dem was ich jetzt gerade meinte

01:10:41.580 --> 01:10:43.560
aber solche Sachen, es gibt halt schon echt

01:10:43.560 --> 01:10:45.720
Beispiele wo man das haben kann

01:10:45.720 --> 01:10:47.380
und ich finde diese Idee echt ganz nett, dass man wirklich mal guckt,

01:10:47.520 --> 01:10:48.960
hey, funktioniert das denn wirklich?

01:10:49.100 --> 01:10:50.520
Weil es kann ja wirklich sein, dass man testet einfach,

01:10:51.060 --> 01:10:52.580
dass der versehentlich funktioniert.

01:10:52.820 --> 01:10:54.680
Zu viel gemockt oder so, man weiß es nicht.

01:10:58.320 --> 01:10:59.740
Ja, absolut.

01:11:02.200 --> 01:11:02.680
Spannendes Thema.

01:11:03.000 --> 01:11:04.980
Ich würde jetzt gerne noch ein paar Getränke hier testen.

01:11:06.220 --> 01:11:06.940
Was haben wir denn noch?

01:11:06.980 --> 01:11:07.480
Eine andere Liste?

01:11:08.620 --> 01:11:10.160
Ich glaube, die Liste sind wir ganz gut, oder?

01:11:10.160 --> 01:11:10.520
Wir sind durch.

01:11:12.100 --> 01:11:14.520
Wir sind voll vorbereitet, weil wir eine Liste haben.

01:11:15.720 --> 01:11:19.300
Du kannst ja schon mal die Liste lesen

01:11:19.300 --> 01:11:20.340
Ich kann ja vielleicht nochmal grad

01:11:20.340 --> 01:11:22.720
Also ich bin immer noch ganz begeistert von dem

01:11:22.720 --> 01:11:24.620
SuiteUp für Django Tests Buch und

01:11:24.620 --> 01:11:27.120
genau, was man nämlich auch noch

01:11:27.120 --> 01:11:28.680
alles machen kann an tollen Sachen ist

01:11:28.680 --> 01:11:31.680
Man kann halt auch noch die Datenbank auf ein

01:11:31.680 --> 01:11:33.300
In-Memory-Filesystem legen

01:11:33.300 --> 01:11:34.540
Es geht zum Beispiel mit Docker

01:11:34.540 --> 01:11:36.140
Docker Compose geht das sehr einfach

01:11:36.140 --> 01:11:36.980
Das ist eine gute Idee

01:11:36.980 --> 01:11:39.320
Und das macht die auch nochmal gleich deutlich schneller

01:11:39.320 --> 01:11:42.300
Weil normalerweise kannst du das halt nur machen mit SQLite

01:11:42.300 --> 01:11:43.860
Und SQLite will man vielleicht nicht verwenden, weil

01:11:43.860 --> 01:11:46.260
ist halt anders als Postgres oder was auch immer.

01:11:46.600 --> 01:11:48.700
Ich würde sagen, kann man damit dann Postgres-Fast-Python-Analyse

01:11:48.700 --> 01:11:50.100
testen, wenn ich ja zum Beispiel

01:11:50.100 --> 01:11:52.220
in Postgres habe ich ja sowas wie Index-Bauen

01:11:52.220 --> 01:11:54.260
oder sowas. Ja, ja, ja, das funktioniert alles.

01:11:55.020 --> 01:11:56.320
Ist halt das drunterliegende Fallsystem,

01:11:56.420 --> 01:11:57.980
was dann halt nur noch im Hauptspeicher ist.

01:11:59.320 --> 01:12:00.600
Ich muss ja gestehen,

01:12:00.700 --> 01:12:02.300
wir hatten ja erst

01:12:02.300 --> 01:12:04.500
geplant, das bei dir daheim zu machen und ich hatte gehofft,

01:12:04.540 --> 01:12:06.280
dass da zu viel das Buch herumliegt, nicht an meinen Blick

01:12:06.280 --> 01:12:07.900
rein darf. Achso, ich habe es nur elektronisch.

01:12:08.900 --> 01:12:09.400
Ah, okay.

01:12:09.700 --> 01:12:10.660
Aber ja.

01:12:12.120 --> 01:12:13.600
Lässt sich sicher sonst auch machen.

01:12:13.860 --> 01:12:43.840
und Jochen unterhalten sich über die Programmiersprache Python

01:12:43.860 --> 01:12:45.920
Ja, genau,

01:12:46.400 --> 01:12:47.720
lass mal überlegen, was war denn da?

01:12:48.180 --> 01:12:50.020
Gab es sonst noch irgendwie interessante Dinge,

01:12:50.080 --> 01:12:51.260
die im Buch drin standen?

01:12:52.760 --> 01:12:54.340
Ja, es gibt da noch irgendwie auch so

01:12:54.340 --> 01:12:55.660
grundsätzliche Dinge, genau,

01:12:55.780 --> 01:12:57.320
Testparallelisieren bringt sehr viel,

01:12:57.620 --> 01:13:00.440
Migrationen bringen auch viel,

01:13:00.500 --> 01:13:01.300
wenn man die squasht.

01:13:02.140 --> 01:13:04.420
Das ist auch sowas, das sollte man

01:13:04.420 --> 01:13:05.260
vielleicht ab und zu mal machen.

01:13:05.880 --> 01:13:08.240
Vor allem auch, wenn man so lustige Sachen hat,

01:13:08.320 --> 01:13:10.500
wie RunPython, also dass man wirklich noch Code ausführt,

01:13:11.240 --> 01:13:11.760
das kann,

01:13:11.760 --> 01:13:15.240
Ich meine, man hat ja meist eine Testdatenbank,

01:13:15.360 --> 01:13:16.800
wo nicht so viele Datensätze drin sind, aber

01:13:16.800 --> 01:13:18.920
je nachdem, was man da für abgefahrene Dinge tut,

01:13:19.040 --> 01:13:19.900
kann das auch schon

01:13:19.900 --> 01:13:23.000
ein Downer sein.

01:13:24.700 --> 01:13:24.840
Ja.

01:13:26.560 --> 01:13:28.080
Ja, aber ansonsten glaube ich,

01:13:28.600 --> 01:13:30.240
muss man selber mal gucken.

01:13:30.980 --> 01:13:32.880
Ich meine, wenn man sich das Blog von Adam Johnson anguckt,

01:13:32.880 --> 01:13:34.360
da sind auch die meisten, also ich meine, das Buch ist

01:13:34.360 --> 01:13:36.980
viele von den Sachen, die darin stehen,

01:13:37.060 --> 01:13:38.280
hat er auch schon mal irgendwie als Blogartikel

01:13:38.280 --> 01:13:39.340
an seinem Blog gehabt.

01:13:39.340 --> 01:13:42.360
Der hat einfach gewagt, dann sein Blogartikel zu einem Buch zu verwurschen

01:13:42.360 --> 01:13:43.160
Das ist ja der Wahnsinn

01:13:43.160 --> 01:13:44.820
Könnte man von lernen

01:13:44.820 --> 01:13:48.000
Ja, genau

01:13:48.000 --> 01:13:49.400
Ansonsten

01:13:49.400 --> 01:13:51.600
Ich weiß nicht, gibt es noch irgendwelche Dinge

01:13:51.600 --> 01:13:53.240
Wir haben jetzt viel über Django geredet

01:13:53.240 --> 01:13:54.660
Gibt es irgendwie Testgeschichten

01:13:54.660 --> 01:13:57.860
die auch relevant wären, die jetzt nicht so sehr

01:13:57.860 --> 01:13:59.740
Django oder Webentwicklung betreffen

01:13:59.740 --> 01:14:00.880
Lass mal überlegen, habe ich irgendwas mit

01:14:00.880 --> 01:14:03.140
Data Science

01:14:03.140 --> 01:14:05.880
Also da ist es auch so, da macht man auch viel Tests

01:14:05.880 --> 01:14:09.720
aber das ist auch alles sehr ähnlich

01:14:09.720 --> 01:14:11.480
fast alles Unit-Tests

01:14:11.480 --> 01:14:12.940
die dann irgendwie die einzelnen Test-Cases

01:14:12.940 --> 01:14:13.440
bauen

01:14:13.440 --> 01:14:17.560
eine Sache, die ich noch ganz

01:14:17.560 --> 01:14:18.380
interessant finde

01:14:18.380 --> 01:14:21.160
das geht wieder so ein bisschen

01:14:21.160 --> 01:14:23.100
Richtung 100% Test-Coverage

01:14:23.100 --> 01:14:25.000
mich auch mit jemandem unterhalten

01:14:25.000 --> 01:14:27.700
und da meinte er, er ist gar nicht so ein Fan

01:14:27.700 --> 01:14:29.160
von Unit-Tests, natürlich braucht man die

01:14:29.160 --> 01:14:30.140
das ist halt

01:14:30.140 --> 01:14:32.960
die gehören einfach zum Team

01:14:32.960 --> 01:14:34.560
er meinte, da hat das so ein bisschen mit

01:14:34.560 --> 01:14:36.360
mit den drei Musketieren verglichen.

01:14:36.520 --> 01:14:38.400
Also Athos, der ist so ein bisschen langweilig,

01:14:38.460 --> 01:14:39.420
aber der gehört, das hat der Chef.

01:14:39.620 --> 01:14:41.400
Die brauchst du halt einfach, kannst nicht ohne.

01:14:42.080 --> 01:14:44.220
Und was er halt viel cooler findet, sind halt

01:14:44.220 --> 01:14:46.140
eher Functional Tests, also sprich Tests, die halt

01:14:46.140 --> 01:14:48.120
die Business-Logik testen. Also dass man halt so ein bisschen mehr

01:14:48.120 --> 01:14:50.540
High-Level-Sachen testet, um einfach sicherzustellen,

01:14:50.660 --> 01:14:52.380
dass, keine Ahnung, wenn man halt irgendeine Logik

01:14:52.380 --> 01:14:54.380
hat, die irgendwas macht, also eine Rechnung erstellen

01:14:54.380 --> 01:14:56.060
oder irgendwas berechnen oder

01:14:56.060 --> 01:14:58.500
irgendeine Daten aggregieren

01:14:58.500 --> 01:15:00.280
oder sowas, dass die halt das tut,

01:15:00.360 --> 01:15:01.160
was man von ihr möchte.

01:15:03.400 --> 01:15:03.800
Und

01:15:03.800 --> 01:15:05.720
Fand ich ganz lustig, weil meistens, wenn halt

01:15:05.720 --> 01:15:07.500
über das Testing gesprochen wird, dann werden halt Unit-Tests

01:15:07.500 --> 01:15:09.560
rauf und runter exerziert und

01:15:09.560 --> 01:15:10.340
dann

01:15:10.340 --> 01:15:13.640
wird auch immer wieder gesagt, so ja, dann gibt es natürlich

01:15:13.640 --> 01:15:15.540
die End-to-End-Tests, wo man natürlich das Frontend drin hat,

01:15:15.600 --> 01:15:17.940
wo man dann wieder in einer ganz Django-Fernenwelt

01:15:17.940 --> 01:15:19.360
oder was heißt Django-Fern, das ist halt dann

01:15:19.360 --> 01:15:21.700
tangiert Django nicht direkt, sag ich mal.

01:15:21.780 --> 01:15:23.400
Das wird natürlich dann irgendwie aufgerufen, genutzt, aber

01:15:23.400 --> 01:15:25.520
das ist dann ja auch bei Cypress dann JavaScript-Code

01:15:25.520 --> 01:15:26.960
und sowas und

01:15:26.960 --> 01:15:29.460
das sind diese Functional-Tests, die kann man halt auch

01:15:29.460 --> 01:15:31.520
problemlos im, also selbst wenn man Django

01:15:31.520 --> 01:15:33.060
Headless verwendet, also ohne das

01:16:03.060 --> 01:16:33.040
und Jochen unterhalten sich über die Programmiersprache Python

01:16:33.060 --> 01:16:36.580
Genau, also die Functional Test ist Porthos, der Coole, der Pirat.

01:16:36.800 --> 01:16:36.920
Ja.

01:16:37.160 --> 01:16:40.700
Und die Integration Test ist dann Aramis, glaube ich, heißt der letzte.

01:16:41.700 --> 01:16:42.540
Die anderen beiden waren?

01:16:43.080 --> 01:16:44.080
Ja, stimmt, du hast es ja schon.

01:16:44.240 --> 01:16:50.060
Also Arthos, Porthos, Aramis und dann D'Artagnan gehört ja nicht so richtig dazu.

01:16:52.060 --> 01:16:57.320
Ich muss aber, nicht dass der, der das Beispiel gebracht hat, mich jetzt haut, weil ich es durcheinander bringe,

01:16:57.400 --> 01:17:00.180
aber Arthos ist auf jeden Fall der langweilige Unit Test.

01:17:00.180 --> 01:17:30.180
dann. Portos, glaube ich, war das Coole. Vielleicht waren das auch die End-to-End-Tests, das weiß ich nicht mehr genau. Also Dathanion oder Portos, weil die sind beide so, ja. Und genau, Aramis ist dann Integration-Test, wo man so externe APIs und sowas mit anspricht und so. Und das ist dann halt immer so ein bisschen, das ist zwar total cool und jeder mag den Charakter auch, aber der ist halt so ein bisschen schwierig. Der ist dann irgendwie ständig verliebt und irgendwie Seelenkrise und so und das ist dann auch so mit den externen APIs. Das ist total cool, das zu haben, aber man hat halt auch irgendwie ziemlich viel Scherrein damit. Und ja.

01:17:30.180 --> 01:17:31.860
Der Wind kommt, damit die Tests gerade...

01:17:31.860 --> 01:17:34.280
Ich glaube, das war

01:17:34.280 --> 01:17:35.820
Porthos ist

01:17:35.820 --> 01:17:38.300
die End-to-End-Test, weil die halt

01:17:38.300 --> 01:17:40.160
ziemlich cool sind, weil du halt damit wirklich den kompletten Flow

01:17:40.160 --> 01:17:41.960
durchtesten kannst und diese Functional-Tests sind

01:17:41.960 --> 01:17:44.320
d'Artagnan, der gehört zum Team

01:17:44.320 --> 01:17:46.000
und der wird aber oft übersehen,

01:17:46.080 --> 01:17:47.720
weil das heißt nur die drei Musketeere und nicht die vier.

01:17:48.240 --> 01:17:48.480
Ja.

01:17:51.520 --> 01:17:52.180
Ja, ja.

01:17:53.260 --> 01:17:54.540
Königin der Kunde oder sowas,

01:17:54.720 --> 01:17:56.160
die entscheidet dann tatsächlich, wie es mit dem

01:17:56.160 --> 01:17:58.240
weiterläuft, mit den dreieinhalb,

01:17:58.240 --> 01:17:58.520
vier.

01:18:00.180 --> 01:18:04.560
Ja, fällt euch noch was ein zu testen?

01:18:06.180 --> 01:18:07.040
Ich teste glaube ich noch

01:18:07.040 --> 01:18:07.540
welchen Wein.

01:18:08.000 --> 01:18:10.400
Ja, genau. Ich meine, ich glaube, wir sind eigentlich

01:18:10.400 --> 01:18:11.940
so halbwegs durchgekommen und so.

01:18:12.560 --> 01:18:14.900
Die erste Folge draußen war gar nicht so verkehrt.

01:18:15.060 --> 01:18:17.520
Also ich hoffe, es ist nicht zu schrecklich.

01:18:17.640 --> 01:18:19.160
Ich bin mal gespannt, was

01:18:19.160 --> 01:18:20.080
auch Vanek draus macht.

01:18:20.500 --> 01:18:20.880
Ja, genau.

01:18:22.060 --> 01:18:24.520
Ja, vielen Dank auf jeden Fall für die Einladung.

01:18:24.520 --> 01:18:25.560
Ja, vielen Dank.

01:18:26.700 --> 01:18:28.620
Mein erster Podcast.

01:18:28.620 --> 01:18:31.140
und war echt cool, hat Spaß gemacht.

01:18:31.440 --> 01:18:32.520
Ja, schön, dass ihr rein geschaltet habt.

01:18:33.000 --> 01:18:34.160
Vielen Dank, dass ihr da wart.

01:18:34.460 --> 01:18:36.660
Schreibt uns auf hello.pythonpodcast.de und bleibt uns gewogen.

01:18:37.080 --> 01:18:37.860
Bis zum nächsten Mal.

01:18:38.280 --> 01:18:38.540
Tschüss.

01:18:38.540 --> 01:18:39.060
Tschüss, ciao.