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 beschriebenen Unit-Tests für Planet sind Pflicht.
¶ Interface
Um uns das Interface bereitzustellen, müsst ihr die vorgegebenen Traits aus dem bereitgestellten Template verwenden.
Damit ist sichergestellt, dass wir in der Lage sind, eure Implementierung zu testen.
Welche internen Datenstrukturen ihr verwendet oder welche Funktionen ihr hinzufügt, ist uns egal.
Wichtig ist, dass sich die vorgegebenen Funktionen wie erwartet verhalten und die Signaturen nicht verändert wurden.
¶ Unit-Tests
Zusätzlich zum Interface wird erwartet, dass ihr euren Code selbständig testet.
Neben dem ständigen Ausprobieren auf den Planeten sollen dazu Unit-Tests[1] [2] verwendet werden.
Diese befinden sich in den Modules tests.rs im jeweiligen src-Ordner der einzelnen Crates (Planet, Communication und Movement).
Auf Windows kompilieren leider keine Tests für die Fortbewegung, da ev3-dev aktuell nicht mit Windows kompatibel ist.
Daher können derzeit keine Movement-Tests geschrieben werden.
¶ How to run
Grundsätzlich können die Tests durch die Verwendung von just ausgeführt werden.
just test // führt alle Tests aus
just test-communication // führt nur Communication-Tests aus
just test-planet // führt nur Planet-Tests aus
Eine andere Möglichkeit ist, die Tests in der IDE direkt auszuführen.
Nach Ausführen der Tests wird eine Zusammenfassung in der Konsole angezeigt:
just test-communication
cargo-zigbuild nextest run --target x86_64-unknown-linux-gnu --package communication
Finished `test` profile [unoptimized + debuginfo] target(s) in 0.09s
────────────
Nextest run ID c825178b-f0c1-441a-9d0a-a8a3c61edcdf with nextest profile: default
Starting 0 tests across 1 binary (1 test skipped)
────────────
Summary [ 0.000s] 0 tests run: 0 passed, 1 skipped
error: no tests to run
(hint: use `--no-tests` to customize)
error: Recipe `test-communication` failed on line 76 with exit code 4
¶ Communication
Die Unit-Tests hierfür dienen dazu, unabhängig von dem fahrenden Roboter das Senden und Empfangen von Nachrichten zu prüfen oder sogar das Befahren eines Planeten zu simulieren.
¶ Planet
Die Unit-Tests hierfür sollen die drei Grundfunktionen add_path(), get_paths() und shortest_path() auf ihre Funktionalität prüfen.
Dazu existieren 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 den Planeten bietet es sich an, weitere Testfälle zu erstellen.