The What, the When and the How: Unterschiede zwischen Unit Tests, TDD und BDD
Kommentare

Das Testen von Code spielt bei der Entwicklung eine wichtige Rolle. Doch gerade Einsteiger in der Welt des automatisierten JavaScript-Testings stehen vor der Frage, welcher Ansatz der Beste ist und ob man auch mehrere Prozesse gemeinsam verwenden kann.

Jani Hartikainen erklärt die Unterschiede zwischen Unit Tests, Test-Driven-Development und Behavior-Driven-Development und bringt so ein wenig Licht in die typischen falschen Annahmen rund um automatisiertes JavaScript-Testing.

Nicht jeder automatisierte Test ist ein Unit Test

Beschäftigt man sich mit automatisiertem Testing im JavaScript-Umfeld, fallen vor allem die drei Schlagwörter Unit Tests, Test-Driven-Development und Behavior-Driven-Development schnell ins Auge. Allerdings scheint es, zumindest laut Jani Hartikainen, als sorge genau das gerade bei Einsteigern für einige Verwirrung. Dabei gibt es deutliche Unterschiede zwischen Unit-Tests, TDD und BDD.

Bei Unit Tests liegt der Fokus auf einer einzigen Code-Einheit, etwa einer Funktion in einem Objekt oder einem Modul. Dadurch sind Unit Tests normalerweise besonders einfach sowie schnell zu schreiben und auszuführen, wodurch eine größere Menge an Tests durchgeführt und am Ende mehr Bugs behoben werden können. Dabei sollten die Tests losgelöst von Dependencies durchgeführt werden, die mithilfe von verschiedenen Tools durch Fakes ersetzt werden können.

Eine häufige falsche Annahme ist, dass es sich bei jedem automatisierten Test um einen Unit Test handelt. Tatsächlich gibt es aber verschiedene automatisierte Testtypen, die jeweils einen eigenen Zweck haben. Dazu gehören Unit Tests, aber auch Integration Tests und Functional Tests, wobei die letzteren deutlich komplexer zu schreiben und zu maintainen sind.

Test-Driven-Development für möglichst hohe Testabdeckung

Im Gegensatz zu Unit Tests, wo tatsächliche Tests geschrieben werden, handelt es sich bei Test-Driven-Development, kurz TDD, um den Prozess zum Schreiben und Ausführen der Tests. Folgt man dem Prozess, der aus sechs verschiedenen Stufen besteht, sorgt das für eine möglichst hohe Testabdeckung, sprich je höher die Testabdeckung, desto mehr Code wird automatisch getestet.

Dadurch wird nicht nur die Wahrscheinlichkeit für Bugs reduziert; Projekte mit einer hohen Testabdeckung sind auch deutlich leichter zu maintainen und ermöglichen eine einfachere Implementierung von neuen Features. Test-Driven-Development lässt sich sowohl mit Unit Tests, als auch mit anderen Testmethoden anwenden und ist zudem nicht auf den Einsatz eines bestimmten Tools oder einer bestimmten Syntax angewiesen.

Best Practices im Behavior-Driven-Development

Im Bereich des automatisierten Testings sorgt Behavior-Driven-Development (BDD) wohl für die größte Verwirrung. Dabei handelt es sich bei BDD um Best Practices für das Schreiben von Tests, die idealerweise gemeinsam mit TDD und Unit Tests zum Einsatz kommen. Im Prinzip zeigt Behavior-Driven-Development, wie man richtig testet – nämlich nicht die Implementierung, sondern das Verhalten des Codes. Dazu sagt Jani Hartikainen:

BDD suggests to test behaviors, so instead of thinking of how the code is implemented, we spend a moment thinking of what the scenario is.

Betrachtet man also das Szenario im Gesamten, führt das zum Design von besseren Tests. Zwar lassen sich alle drei genannten Methoden einzeln verwenden, die besten Testergebnisse werden allerdings meist erst durch die Kombination von Unit Tests mit TDD und BDD erreicht. Zusammengefasst drückt Hartikainen die Unterschiede zwischen den drei Testmethoden so aus:

Unit Testing gives you the what. Test-Driven-Development gives you the when. Behavior Driven-Development gives you the how.

Aufmacherbild: Wooden blocks spell out TEST on a blue bubble or scantron sheet with a number two yellow pencil. von Shutterstock / Urheberrecht: Keith Bell

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -