Interface und Tests

DrunkRobot

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.

Info

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.

Info

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

#!/usr/bin/env python3

import unittest
from Planet import Direction, Planet


class FirstPlanetTest(PlanetTestCase):

    def setUp(self):
        self.planet = Planet()

    def test_target_not_reachable_with_loop(self):
        # ...

    def test_empty_planet(self):
        # ...

    def test_shortest_path(self):
        # ...


if __name__ == "__main__":
    unittest.main()

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.

Tip

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).