Best Practice für selbst programmierte Test Frameworks

Veröffentlicht auf 31. März 2009

Für die Erstellung von Test Frameworks im Sinne vom Erstellen von Klassen und Methoden, die einem das Programmieren von Tests erleichtern sollen, sind einige Regeln zu beachten.
Darunter gehören eigentlich schon alle Punkte, die man als "gutes Software-Design" kennt.

Nachfolgend sind die wichtigsten Punkte , die man für die Testautomatisierung beachten sollte nochmals aufgelistet:

  • Gute Dokumentation des Codes erleichtert die Einarbeitung für andere Mitarbeiter.
  • Methoden erhalten eine Beschreibung ihrer Funktion, Parameter und Rückgabewerte.
  • Dokumentation von Änderungen.
  • Verwenden einer Coding Guidline, für halbwegs einheitlichen Code.
  • Strukturierung des Codes durch Einrückungen.
  • Eindeutige Benennung von Variablen, Methoden etc.
  • Verwendung eines Präfix für Variablen etc.: pb_WeiterButton.
  • Variablen werden wenn möglich bereits zusammen mit der Definition initialisiert.
  • Variablen die auf NULL geprüft werden sollen, müssen auch erst auf NULL gesetzt werden.
  • Variablen werden nur einmal im Code verwendet. Ausnahme: Schleifenvariablen.
  • "Keep it simple" - lesbarer Code.
  • Die Testschritte sollten ausgegeben werden, damit anhand des Protokolls der Testverlauf nachvollziehbar ist.
  • Ausgabe von Fehlermeldungen, wenn Fehler auftauchen können, dies erleichtert das spätere Debuggen.
  • Modularisierung erleichtert die Durchführung von Änderungen.
  • Kapselung erleichtert den Austausch von Komponenten bei neuen Versionen.
  • Keine globalen Funktionen!
  • Der Rückgabewert VOID für Methoden ist meist der schlechteste.
  • Keine statischen Definitionen von Pfaden oder irgendwelchen Werten, wenn die Informationen anders bereitgestellt werden können.
  • Methoden die bestimmte Voraussetzungen haben, sollten diese zu Beginn der Methode auch prüfen.
  • Große Methoden sind zu groß (komplex)!
  • Mehr als 5 Parameter sind in der Regel zu viel für eine Methode (Überschaubarkeit).
  • Anwendung von Design Patterns.
  • Verwendung von Interfaces als Schnittstellen zu anderen Systemen, Datenbanken etc.
  • Keine Endlosschleifen verwenden, wenn dies nicht gewollt ist. Am besten mit Timeouts arbeiten, damit diese Schleifen auf jeden Fall verlassen werden.
  • Trennung von Konfigurationsdaten und Programmcode vermeidet Fehler bei der Konfiguration.
  • Alle logisch zusammengehörende Konfigurationsdaten an einem Ort.
  • Pro Datei eine Klasse, logische Einheit.
  • Pfade zu Fensterobjekten werden in Variable abgespeichert, damit muss bei Änderungen nur der Pfad der Variable geändert werden, nicht die gesamte Programmierung.
  • Stringbezeichnungen von Fensterobjekten, Menus etc. werden in Records abgespeichert, um Änderungen leichter durchführen zu können.
  • Trennung von Testdaten und Testfallprogrammierung garantiert die allgemeine Gültigkeit eines Testfalls.
  • Immer wiederkehrende Schrittfolgen sollten schon zu Beginn in größeren Methoden zusammengefasst werden, die auf andere Methoden zugreifen. Damit soll Mehrarbeit bei späteren Änderungen verhindert werden.
  • Testfällen sollten am besten Records oder Listen übergeben werden anstatt viele Parameter.
  • Testfälle, die einmal auf „Failed“ gesetzt wurden, sollten auch im weiteren Verlauf auf „Failed“ bleiben.
  • Kein Kopieren und Einfügen! Schreiben Sie eine Schleife oder eine neue Funktion für wiederholbaren/wiederkehrenden Code!!
  • Niemals Bildschirmpositionen für die Durchführung von Aktionen oder Kennzeichnung von Fensterobjekten verwenden!!
  • Positionen auf der Oberfläche sollten immer relativ zu anderen Objekten bestimmt werden.
  • Der Ausgangszustand beinhaltet eine Anwendung im Ursprungszustand (ohne Benutzereinstellungen, Änderungen der Oberfläche, etc.), ggf. eine Rücksetzung der Testumgebung, aber immer "neue" Testdaten! Auf den original Referenzdaten darf nie gearbeitet werden!!
  • Schlägt ein Test an einer Stelle fehl, sollte trotzdem der Test noch laufen und Ergebnisse liefern. Er darf auf keinen Fall folgende Tests blockieren! Dazu gehört eine robuste Programmierung.
  • Ausgangs- und Endzustand eines Testfalls sollten möglichst die gleichen sein.

Geschrieben von Robert Bullinger

Veröffentlicht in #Testautomatisierung

Kommentiere diesen Post