2 Min. Lesezeit

Sociable Tests

Sociable Tests

Podcast Episode: 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.

apple spotify youtube

Highlights der Episode

  • Welche Möglichkeiten gibts fürs automatisiertes Testen
  • Wo man von der Theorie abweichen muss, um Qualität zu halten
  • Warum Selenium, Cypress, usw. für Entwickler herausfordernd sein können
  • Vorteile von GBT / Die Wichtigkeit des richtigen Frameworks VOR dem Testen
  • Design vor Test
  • "Schmeiß Mocking weg!"
  • Tipps für den Start mit Sociable Tests

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.

Neuauflage Agile Testing

Neuauflage Agile Testing

Podcast Episode: Neuauflage Agile Testing ‘So, wir brauchen jetzt keine Tester mehr, denn wir arbeiten jetzt agil!’ Das war der Impuls, vor mehr als...

Weiterlesen
Testbeschreibung für KI-Fähigkeiten

Testbeschreibung für KI-Fähigkeiten

Die Regulierung von Künstlicher Intelligenz (KI) gewinnt zunehmend an Bedeutung, insbesondere im Hinblick auf die Entwicklung von Normen und...

Weiterlesen
Cypress

Cypress

Podcast Episode: Cypress Dehla arbeitet schon viele Jahre mit Automatisierungstools. Cypress hat sie überzeugt. Das Open Source Tool hat viele...

Weiterlesen