Im Grunde geht es bei Exercism vor allem um die Tests und das Testen, denn sie bringen deine Implementierung voran und sagen dir, wann eine Übung fertig ist.
Sofortiges Feedback
Pharo unterstützt die Arbeit mit Tests hervorragend, und auch inkrementelles Testen! Du kannst jeden Test für eine Übung ausführen, indem du neben einer Testfallklasse oder -methode auf den Orb klickst.
Die Test-Orbs sind entsprechend dem Ergebnis des letzten Testlaufs eingefärbt:
- grün für einen bestandenen Test
- gelb für eine fehlgeschlagene Assertion
- rot für einen Laufzeitfehler oder eine Ausnahme
Geordnete Tests
Die Tests in den Übungen von Exercism sind absichtlich nummeriert, um eine feste Ausführungsreihenfolge vorzugeben (z. B. test01_verifySomeProperty, test02_verifyAnotherProperty usw.).
Wenn du an einer Übung arbeitest, empfiehlt es sich, auf den Orb für den ersten Test zu klicken, den Fehler und das, was nötig ist, um ihn zu bestehen, zu verstehen und dann den Code in deiner Lösung zu ergänzen, damit er funktioniert. In Pharo ist es ganz normal, diese Änderungen im Debugger vorzunehmen, wo du sowohl Zugriff auf den Code-Editor als auch auf eine Ansicht aller Variablen und Parameter hast, die dir helfen können, das Problem zu verstehen.
HINWEIS: Es ist nicht üblich, Tests mit einem Ordnungspräfix zu versehen, und du solltest das auch NICHT tun, wenn du Tests für dein eigenes Projekt schreibst.
Es läuft auch mit fehlerhaftem Code
Pharo läuft ohne Weiteres mit fehlerhaftem Code, und der Debugger öffnet sich einfach erneut, wenn ein Fehler auftritt (sei es ein Syntaxfehler, ein ungültiger Wert oder sogar eine fehlende Klasse oder Methode). Diese Technik war ein wesentlicher Einfluss für die testgetriebene Entwicklung, und du kannst diese Vorgehensweise ausprobieren, wenn du den ersten Test für eine beliebige Übung ausführst. Der Debugger zeigt dir sofort, dass deine Lösungsklasse nicht gefunden wird (du hast ja noch nichts geschrieben). Praktischerweise gibt es einen Button „Create“, mit dem du die fehlende Klasse hinzufügen und die Ausführung fortsetzen kannst, bis sie entweder beendet ist oder ein weiterer Fehler auftritt.
Bei deinem ersten Test stößt du als Nächstes auf einen zweiten Fehler, weil du noch keine Methoden geschrieben hast. Auch hier kannst du mit dem Button „Create“ im Debugger eine definieren und die Ausführung fortsetzen. An dieser Stelle kannst du auch weiter unten im Stacktrace klicken, dir die Anforderungen des fehlgeschlagenen Tests ansehen und deine neue Methode so anpassen, dass sie ihn besteht.
Den Debugger lieben lernen
Später in deinem Entwicklungszyklus kann es auch nützlich sein, weiter hinten im Stack zu klicken und den Button „Restart“ zu verwenden, um die Programmausführung an einem früheren Punkt fortzusetzen. So kannst du dann Schritt für Schritt durch dein Programm gehen und sehen, was passiert. Das ist eine wichtige und nützliche Methode, um zu verstehen, warum dein Programm nicht funktioniert.
Neben den Variablen im Debugger kannst du auch eine beliebige Anweisung markieren und auf inspect/print klicken, um das Ergebnis ihrer Auswertung zu sehen. Das kann nützlich sein, wenn du Ergebnisse einer Methode testest oder den internen Zustand eines Objekts untersuchen möchtest.
Vergiss nicht, dass du im Debugger auch Änderungen am laufenden Code vornehmen kannst, und beim Speichern einer Änderung wird die Ausführung einfach in der gerade gespeicherten Methode neu gestartet. So kannst du mit Änderungen experimentieren und ihre Ergebnisse sehen, während du noch „im Moment“ bist.
Zusammenfassend: Hab keine Angst davor, den Debugger in Pharo zu benutzen. Wir sehen ihn als wertvolles Werkzeug, das hilft, ein Problem zu verstehen und damit zu experimentieren.
Größere Testgruppen und Automatisierung
Wenn du größere Gruppen von Tests ausführen möchtest, kannst du sie auch über das Package-Menü starten oder das Tool Test Runner verwenden (Zugriff über das World-Menü oder mit <meta> + OU).
Du kannst Tests auch programmatisch im Playground ausführen, indem du den folgenden Ausdruck auswertest und ausgibst:
AllExercismTests suite run.
Wenn du mehr über die Interna von Tests erfahren möchtest, kannst du etwas über SUnit lesen oder den Code in der TestCase-Hierarchie durchstöbern.
Wusstest du schon: TDD wurde in Smalltalk erfunden, indem die Testbibliothek SUnit eingeführt wurde
