Die Weltmeere sind voller Plastik, der Russe hat den Finger am roten Knopf, die Bahn arbeitet noch mit Windows 3.11 und die Sparkasse verschickt ihre AGBs als USB Stick, um Papier zu sparen. DevCouch deckt auf! Zusätzlich: Neues von der .NET 9 Roadmap, Sudo für Windows und gefrorene Auflistungen. Wahnsinn.
Links:
Jetbrains-Ecosystem Survey:
https://www.jetbrains.com/lp/devecosystem-2023/
Conventional Commit:
https://www.conventionalcommits.org/en/v1.0.0/
Google Gemini 1.5
https://blog.google/technology/ai/google-gemini-next-generation-model-february-2024/
Frozen Collections:
https://steven-giesel.com/blogPost/34e0fd95-0b3f-40f2-ba2a-36d1d4eb5601
Job bei der Bahn – ICE 1 und 2 Software:
https://www.heise.de/news/Deutsche-Bahn-sucht-Admin-fuer-Windows-3-11-for-Workgroups-9611543.html
Sparkasse AGBs:
http-Toolkit:
.NET 9 Roadmap
https://devblogs.microsoft.com/dotnet/our-vision-for-dotnet-9/
Sudo für Windows
https://devblogs.microsoft.com/commandline/introducing-sudo-for-windows/
Visual Studio 17.9
https://devblogs.microsoft.com/visualstudio/visual-studio-2022-17-9-now-available/
DevCouch erscheint circa alle 14 Tage und ist ein kostenloser Unterhaltungspodcast von 3 freiberuflichen Softwareentwicklern – Manuel Wenk, Thomas Krause und Oliver Vogel.
Instagram:
https://www.instagram.com/devcouch_podcast/
iTunes:
https://podcasts.apple.com/de/podcast/devcouch/id1249563765
Für Feedback kontaktiert uns auf www.devcouch.de oder sendet uns eine Email an info@devcouch.de . Über eine positive Bewertung bei iTunes freuen wir uns!
Musik:
Reaching Out Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0 License
http://creativecommons.org/licenses/by/3.0/
Music promoted by https://www.chosic.com/free-music/all/
Circus Theme (Entry of the Gladiators) – Strings Version by Alexander Nakarada | https://www.serpentsoundstudios.com
Music promoted on https://www.chosic.com/free-music/all/
Creative Commons Attribution 4.0 International (CC BY 4.0)
https://creativecommons.org/licenses/by/4.0/
Kazzo-Sound-Effect:
1 Kommentar
Steve · 18. März 2024 um 09:44
Hi zusammen,
ich habe eure Folge gehört und wurde wieder mal hellhörig bei euren Unit Test Aussagen. 🙂
Erstmal bin ich vollkommen dabei, dass Test-Code auf „oberster Ebene“ fachlich abbilden soll, wofür er da ist. Gerade Unit Tests neigen eben dazu, allzu technisch zu sein und das Warum dahinter nicht auszudrücken. Das fängt bei der Benamung eines Tests an. Je weiter man nach außen kommt (Integration oder ganzer Systemtest) wird es einfacher, die dahinter liegende Fachlichkeit zu benennen. Das muss sich durch Abstraktion herleiten können, so wie Oliver es gut beschrieben hat. Damit ist Testcode genauso zu behandeln, wie Produktivcode, anders gelingt das nicht.
Schön, wenn man eine Ausgangsbasis im Produktivcode hat, die das überhaupt möglich macht. 😀
Da wir uns ja schon mal über SpecFlow und Cucumber, Gherkin, etc. unterhalten haben. Das Tooling/Framework nimmt einem nicht die Arbeit ab, die fachliche Ausarbeitung hinzubekommen. Darüber hinaus ist das kein Tool, das man über alle Tests hinweg benutzen will. Aber, im Gegensatz zu einem handelsüblichen Unit-Test erzwingt es direkt eine Abstraktion, die Unit Tests idR sonst fehlt. Am genialsten ist es natürlich, wenn man diese Gherkin-Syntax (da wo hilfreich, nämlich Teil einer Kommunikation mit dem Fachbereich) unter der Haube mit einer lesbaren API unterfüttert (wie Oliver ausführte die FluentAPI wäre ein Weg). Und erst darunter geschieht dann der technische Part, der das gemeinsam implementiert. Hoffentlich ist aber auch die Technik dazu fachlich orientiert geschrieben, sodass das kein Widerspruch alles ist (denke dabei an Anemic vs. Rich Domain Model).
LG,
Steve