Interface und Tests
Aus diversen Gründen kann es vorkommen, dass euer Roboter unterschiedlichen Prüfungsszenarien nicht bewältigen kann. Mal ist der Vergaser verstopft, mal flippt ein Bit im Speicher durch kosmische Strahlung oder die Wasserader unter dem Gebäude 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
, get_paths
und shortest_path
wie erwartet verhalten und die Funktionsdefinition nicht verändert wurde.
Tests
Zusätzlich zum Interface wird erwartet, dass ihr euren Code selbständig testet.
Neben dem ständigen Ausprobieren auf den Planeten sollen dazu Unittests1 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 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 (sog. Edge-Cases
)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).
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.
cd <robolab-project>/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
).