Du betrachtest eine alte Version der Seite. Zur neuesten Version gehen.
Planung von Tests: Unterschied zwischen den Versionen
Romana (Diskussion | Beiträge) (→Keine Zusammenfassung) |
Romana (Diskussion | Beiträge) |
||
| Zeile 1: | Zeile 1: | ||
| + | ==Einleitung== | ||
Tests entwerfen ist eine einfache Sache, solange es sehr wenige Tests sind. Wird der zu testende Code aber umfangreicher, lohnt es sich, sich Gedanken zu machen, wie man die Aufgabe am besten löst. Tests sollten folgende Bedingungen erfüllen: | Tests entwerfen ist eine einfache Sache, solange es sehr wenige Tests sind. Wird der zu testende Code aber umfangreicher, lohnt es sich, sich Gedanken zu machen, wie man die Aufgabe am besten löst. Tests sollten folgende Bedingungen erfüllen: | ||
| Zeile 6: | Zeile 7: | ||
* DRY - Don't Repeat Yourself! Auch bei den Tests sollte natürlich im Hinblick auf die Wartbarkeit und Erweiterbarkeit der Tests mehrfach derselbe Code vermieden werden. Das lässt sich nicht immer machen, gerade bei Akzeptanz-Tests muss gelegentlich derselbe Test mit unterschiedlichen Parametern von außerhalb durchlaufen werden. | * DRY - Don't Repeat Yourself! Auch bei den Tests sollte natürlich im Hinblick auf die Wartbarkeit und Erweiterbarkeit der Tests mehrfach derselbe Code vermieden werden. Das lässt sich nicht immer machen, gerade bei Akzeptanz-Tests muss gelegentlich derselbe Test mit unterschiedlichen Parametern von außerhalb durchlaufen werden. | ||
| − | + | ==Vorgehensweise== | |
| + | Die hier beschriebene Vorgehensweise ist vielleicht nicht das Nonplusultra, aber mir hilft es enorm. | ||
Version vom 18. April 2017, 10:21 Uhr
Einleitung
Tests entwerfen ist eine einfache Sache, solange es sehr wenige Tests sind. Wird der zu testende Code aber umfangreicher, lohnt es sich, sich Gedanken zu machen, wie man die Aufgabe am besten löst. Tests sollten folgende Bedingungen erfüllen:
- Verlässlichkeit: Es sollten alle Fehler erkannt werden, aber false positives vermieden werden
- Vollständigkeit: Es sollte alles getestet werden, was nötig ist. Gerade bei Akzeptanz-Tests ist das eine Herausforderung, denn hier wird oft mit Code-/Programmteilen interagiert. Da müssen auch alle "Rahmenbedingungen" der Programmteile erfasst werden, die für diese Testreihe nötig sind.
- Nur ein Item pro Test. Das ist etwas Definitionssache und muss gegebenenfalls für den nächsten Punkt passend definiert werden.
- DRY - Don't Repeat Yourself! Auch bei den Tests sollte natürlich im Hinblick auf die Wartbarkeit und Erweiterbarkeit der Tests mehrfach derselbe Code vermieden werden. Das lässt sich nicht immer machen, gerade bei Akzeptanz-Tests muss gelegentlich derselbe Test mit unterschiedlichen Parametern von außerhalb durchlaufen werden.
Vorgehensweise
Die hier beschriebene Vorgehensweise ist vielleicht nicht das Nonplusultra, aber mir hilft es enorm.