Interface und Tests

drunkrobot

Aus diversen Gründen kann es vorkommen, dass es euer Roboter nicht auf den großen Prüfungsplaneten schafft. Mal ist der Vergaser verstopft, mal flippt ein Bit im Speicher durch kosmische Strahlung oder die Wasserader unterm Foyer stört das Chakra des Gyro-Sensors. Da ihr euch natürlich viel Mühe mit dem Algorithmus zur Berechnung des kürzesten Weges gegeben habt, wäre es ja schade, wenn wir ihn nicht in die Benotung einfließen lassen können. Das geht ohne Roboter aber nur, wenn alle Gruppen die gleiche Programmierschnittstelle implementieren. Dieses sogenannte Interface möchten wir euch hier kurz vorstellen.

Die Nutzung und Implementierung des Interface und die Programmierung der weiter unten genauer beschriebene Testklasse RoboLabPlanetTests sind Pflicht.

Interface

Um uns das Interface bereitzustellen, müsst ihr die vorgegebene Klassen aus dem bereitgestellten Template verwenden. Damit ist sichergestellt, dass wir in der Lage sind, auf eure Karte vom Planeten zuzugreifen und den Algorithmus zu testen. Welche internen Datenstrukturen ihr verwendet oder welche Funktionen ihr hinzufügt ist uns egal - Wichtig ist, dass sich add_path und shortest_path wie erwartet verhalten.

Tests

Zusätzlich zum Interface wird erwartet, dass ihr euren Code selbständig testet. Neben dem ständigen Ausprobieren auf den Planeten sollen dazu Unittests [1][2] verwendet werden. Im Ordner src/tests/ des Templates befindet sich im Modul test_planet.py ein erstes Beispiel hierzu.

In der Beispielklasse ExampleTestPlanet findet ihr einen groben Aufbau, an dem ihr euch für Eure Implementierung orientieren könnt.
Die von euch zu vervollständigende Klasse TestRoboLabPlanet enthält bereits sieben Testfälle, die zu befüllt und programmiert werden müssen. Überlegt euch dazu geeignete Lösungen zur Prüfung dieser Fälle. Für besondere oder sehr spezielle Situationen auf dem Planeten können weitere Testfälle erstellt werden, um beispielsweise die Funktion und Korrektheit eures Algorithmus zur Findung des kürzesten Weges zu prüfen.

Es empfiehlt sich weitere Testklassen und -fälle für geeignete Teile Eures Codes anzulegen, beispielsweise einen Communication-Test (nicht verpflichtend).

Beispiel: Unit-Tests

Das Testskript kann von der Kommandozeile aus lokal auf Eurem Rechner gestartet werden. Sollte eines eurer Module Klassen aus dem Paket ev3dev.ev3 importieren, kann die lokale Ausführung jedoch fehlschlagen, da eurem Rechner die entsprechende Hardware fehlt.

Achtet darauf, die zu testenden Klassen in Module auszulagern, welche nach Möglichkeit ohne den Import des Pakets ev3dev.ev3 auskommen.

robolab-group-xxx/src$ python -m unittest tests.test_planet
.......
----------------------------------------------------------------------
Ran 7 tests in 0.001s

OK

Das Argument tests.test_planet beschreibt dabei, welche Datei im Test-Ordner ausgeführt werden soll. Standardmäßig werden dann alle in dieser Datei definierten Testklassen ausgeführt.
Über das Schema tests.test_module.test_class kann noch weiter definiert werden, welche Testklasse ausgeführt werden soll (zum Beispiel tests.test_planet.TestRoboLabPlanet).
Es ist sogar möglich nur eine einzelne Methode einer Testklasse auszuführen, dafür kann einfach das Schema tests.test_module.test_class.test_method verwendet werden (zum Beispiel tests.test_planet.TestRoboLabPlanet.test_empty_planet).