3 Tests

Tests

Wir haben derzeit eine Test Coverage von 100%.

Um in unsere Tests einzusteigen, ist es am Besten in der Klasse OPTestEvaluator zu beginnen. In der Methode OPTestEvaluator >> prettify:shouldEqual: könnt ihr sehen, wie wir das vom OPPrinter gegebene Interface nutzen, um den Eingabestring zu formatieren und dies dann gegen das Ergebnis, welches wir erwarten, testen.

Dabei haben wir für jeden unserer implementierten Knoten bzw. für jeden getesteten Knoten eine eigene Klasse angelegt, welche eine Subklasse vom OPTestEvaluator ist. Dabei steht in der Methode startSymbol die jeweilige Regel als Symbol, bei welcher wir für diese Klasse beginnen zu parsen.

Das Ziel dieses Vorgehens ist es möglichst kleinteilige Tests zu schreiben, sodass diese unabhängig voneinander sind. Wenn wir also an einer Formatierung doch noch einmal etwas ändern, sollen nach Möglichkeit nur die Tests dieses Knotens fehlschlagen. Dies ist jedoch nicht immer möglich, da Knoten aus Unterknoten aufgebaut sind.

Allerdings kommt es so auch zustande, dass wir keine komplette Methode auf ihre Formatierung testen. Denn sonst müssten wir unter Umständen bei jeder neu implementierten Regel erneut diesen Test anpassen.

Die Klassen TestUI und TestComments sind dabei etwas besonders. TestUI testet die Funktion des Buttons und des Code Highlightings. TestComments fasst verschiedene Test bezüglich Kommentaren zusammen, welche von unterschiedlichen Knoten starten. Wahrscheinlich wäre es ratsam diese Tests direkt in den entsprechenden Testklassen zu implementieren, sodass diese Klasse überflüssig wird. Weiterhin sind die Tests in keinem Fall vollständig und müssen noch deutlich vervollständigt werden. Die Wünsche unseres Kunden haben wir als Issues festgehalten.

Wir haben außer unseren Richtlinien für Tests auch noch einige Coding Standards und Github Regeln festgelegt.

Übersicht über die implementierten Regeln von OhmExplicitSendsSmalltalk