Bringt uns denn ein isolierter kleiner Unit-Test wirklich was? Es gibt vielfältige Möglichkeiten des automatisierten Testens, und manchmal muss man von der Theorie abweichen, um die Qualität zu halten. Tools wie Cypress, Selenium, usw. können für Entwickler herausfordernd sein. Da bietet der Ansatz GBT (Guided By Tests) Vorteile. Jan denkt konsequent in die Richtung: Was ist der Job des Entwicklers und provoziert mit seiner Aussage “Schmeiß Mocking weg!” – aus gutem Grund.
“Martin Fowler (…) spricht davon, dass die Entwickler ja zuständig sind für das, was wir Unit-Tests nennen. Und dass wir dort eine Unterscheidung haben, und zwar einmal in das, was er ‘Isolierte Unit-Tests’ nennt und das andere nennt er ‘Sociable Unit-Test’” – Jan Leßner
Jan Leßner ist Software-Entwickler, Architekt und System-Analyst bei S&N Invent. Er ist Buchautor und Java-Programmierer der ersten Stunde und engagiert sich in verschiedenen Open-Source-Frameworks. Seit über 10 Jahren ist er in Enterprise-Projekten mit den Schwerpunkten Bilanzanalyse, Loyalty-Programme und Telekommunikation tätig. Dort beschäftigt er sich nicht nur mit der eigentlichen Entwicklung, sondern auch mit dem Aufbau eines eleganten Software-Engineerings.
Highlights in dieser Episode:
In dieser Folge spreche ich mit Jan Leßner über die Bedeutung von Tests in der Softwareentwicklung, insbesondere den Unterschied zwischen isolierten und sociable Unit Tests, sowie die Herausforderungen und Strategien zur Verbesserung der Testbarkeit in Projekten.
In dieser Podcast-Episode hatte ich das Vergnügen, mit Jan Leßner, einem leidenschaftlichen Softwareentwickler und Experten im Bereich Testing, zu sprechen. Jans Ansichten sind durchaus provokativ und bieten einen frischen Blick auf das, was Testing wirklich bedeutet, und wie es den Entwicklungsprozess bereichern kann.
Vielleicht fragen Sie sich jetzt: Was genau unterscheidet isolierte von sociable Unit Tests? Laut Jan ist diese Unterscheidung grundlegend für das Verständnis moderner Teststrategien. Isolierte Tests konzentrieren sich auf einzelne Komponenten ohne Berücksichtigung deren Interaktionen, während sociable Tests größere Einheiten betrachten – insbesondere Use Cases oder Features. Diese Perspektive fordert einen Paradigmenwechsel: Weg von der reinen Fokussierung auf kleinste Einheiten hin zur Betrachtung dessen, wie diese Einheiten zusammenarbeiten, um ein funktionierendes Ganzes zu erschaffen.
Ein weiteres zentrales Thema unseres Gesprächs war die Rolle des Entwicklers im Testing-Prozess. Entwickler sind nicht nur für den Code selbst verantwortlich, sondern müssen auch dafür sorgen, dass die Anwendung als Ganzes funktioniert. Dies beinhaltet die Entwicklung von sociable Unit Tests, die sicherstellen, dass alle Komponenten korrekt miteinander interagieren. Das erfordert oft einen mutigen Schritt weg von traditionellen Methoden hin zu innovativen Ansätzen, die den gesamten Entwicklungsprozess beschleunigen können.
Jan teilte einige wertvolle Einblicke darüber, wie man den Testing-Prozess effizienter gestalten kann. Ein Schlüsselaspekt ist der Einsatz von Headless End-to-End-Tests. Diese Methode eliminiert die Notwendigkeit für komplexe UI-Tests und ermöglicht es Entwicklern, Features umfassend zu testen – von der Benutzeroberfläche bis hin zur Datenbank. Darüber hinaus sprachen wir über die Bedeutung einer guten Projektarchitektur und Designentscheidungen, die Testbarkeit vom Start weg berücksichtigen.
Eine besonders interessante Diskussion drehte sich um das Thema Mocking. Während Mocking oft als nützliches Werkzeug angesehen wird, argumentiert Jan dafür, es so weit wie möglich zu vermeiden. Stattdessen sollte man sich auf realistische Testumgebungen konzentrieren und externe Systeme nur dort mocken, wo es absolut notwendig ist. Dies führt zu aussagekräftigeren Tests und reduziert gleichzeitig den Aufwand für die Erstellung und Wartung von Mocks.