Sociable Tests

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:

• Jan Lesner ist ein leidenschaftlicher Softwareentwickler und hat eine eigene Meinung zum Thema Unit Tests
• Wir diskutieren über isolierte und sociable Unit Tests und deren Bedeutung
• Jan teilt seine Erfahrungen mit Testing Frameworks und dem Umgang mit Testdaten
• Die Bedeutung von Feature-Tests und wie man sie effektiv implementieren kann, wird hervorgehoben
• Jan spricht sich gegen das extensive Mocking aus und bevorzugt Tests mit echten Datenbanken
• Die Rolle der Architektur und Design-Entscheidungen bei der Testbarkeit von Software wird betont
• Jan gibt praktische Tipps, wie man mit existierender Software, die nicht für Tests entworfen wurde, umgehen kann
• Die Bedeutung von Testdaten-Generatoren und wie sie die Erstellung von Tests vereinfachen können, wird besprochen

Isolierte vs. Sociable Unit Tests: Frischer Wind im Softwaretesting

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.

Was Testen wirklich bedeutet

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.

Isolierte vs. Sociable Unit Tests: Eine entscheidende Unterscheidung

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.

Die Rolle des Entwicklers im Testing-Prozess

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.

Praktische Tipps zum effektiveren Testen

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.

Mocking: Freund oder Feind?

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.