Manuel Rauber Thinktecture AG

Alle Arten von Tests haben eines gemeinsam: Sie sollen die Qualität, Pflege und Wartbarkeit von Code verbessern. Fehler sollen frühzeitig gefunden und behoben werden können, sodass sie nicht an den Kunden ausgeliefert werden.

Wer hin und wieder mal einen Blick in die Patchnotes von Software wirft, kennt sicherlich den generischen Eintrag „Bugfix“. Manchmal ist er auch genauer spezifiziert. Ärgerlich wird es, wenn in der folgenden Version der gleiche Bug wieder auftritt. Das stimmt den Benutzer nicht positiv und ist auch für den Entwickler ärgerlich, da er das gleiche Problem abermals lösen muss. Wie das passieren kann, ist ziemlich klar: Es existieren keine automatisierten Softwaretests, ansonsten wäre der Fehler bereits aufgefallen.

Was uns Softwareentwicklern wohl am meisten Spaß macht, ist das Entwickeln von Software „auf der grünen Wiese“ – keine Vorgaben, alles neu. Wir können Dinge ausprobieren, neue Technologien kennen lernen, und der erste Prototyp wird entwickelt. Ihm werden mehr und mehr Features hinzugefügt, und die Codebasis wird durch Refactoring immer besser. Bugs werden beseitigt, die Software läuft stabiler. Jeder spricht nach wie vor von einem Prototyp, bis man sich plötzlich dazu entscheidet, diesen Prototyp in ein Produkt zu packen und auszuliefern.

Eine Sache wurde beim Entwickeln des Prototyps allerdings nicht umgesetzt – schließlich sollte dieser ja nie in Produktion gehen: das Erstellen von automatisierten Softwaretests. Sicherlich wurde während der Entwicklung immer mal wieder manuell getestet und ausprobiert. Oftmals aber nur die neuen Features oder Bugfixes, die man soeben gemacht hat. Niemand möchte manuell immer wieder die gleichen Tests machen. Es gibt allerdings jemanden, der Aufgaben gerne schnell und wiederkehrend erledigt: unser Computer.

Artikelserie

Teil 1: JavaScript als alternative Möglichkeit der Backend-Entwicklung
Teil 2: Moderne Web-APIs mit Node.js
Teil 3: Datenbanken mit Node.js
Teil 4: Unit- und Integrationstests mit Node.js

Wenn wir unserem schnellen Rechenkollegen einmal beigebracht haben, wie unsere Software getestet werden soll, wird er liebend gerne dafür sorgen, dass die Tests ausgeführt werden. Um ihm das Testen beizubringen, sollten wir uns erst einmal darauf verständigen, welche Arten zu testen es gibt. Denn Softwaretests haben viele Namen und existieren in vielen Ausprägungen:

  1. Unit-Test (oder auch Modultest, Komponententest): Es handelt sich hierbei um das isolierte Testen einer einzelnen Komponente (was zumeist exakt einer Klasse entspricht). Abhängigkeiten (z. B. der Zugriff auf die Festplatte oder das Absetzen von HTTP-Anfragen) innerhalb dieser Komponente werden durch so genannte Mocks ersetzt. Bei Unit-Tests kann man vergleichsweise einfach positive und negative Fälle betrachten und testen.
  2. Integrationstest: Ein Integrationstest testet das Zusammenspiel mehrerer Komponenten. Was zuvor im Unit-Test als Mock abstrahiert wurde, kann nun wieder durch eine echte Komponente ersetzt werden (z. B. werden nun echte HTTP-Anfragen ausgeführt). Das Mocken von Komponenten ist bei Integrationstests dennoch erlaubt und erwünscht (oftmals verzichtet man hier beispielsweise auf das Testen des User Interface oder der Datenbankanbindung).
  3. Systemtest (oder auch Akzeptanztest, Acceptance-Test, End-to-End-Test): Durch den Verzicht auf Mocks wird das System in seiner Gesamtheit getestet. In diesem Fall werden oftmals nur Erwartungshaltungen getestet (also der positive Fall), da Fehlerfälle bereits intensiv durch Unit- und Integrationstests abgedeckt wurden.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Windows Developer 9.16 - "Test first, build better"

Alle Infos zum Heft
255482Automatische Softwaretests mit Node.js
X
- Gib Deinen Standort ein -
- or -