How-to: Automatisierten Test ergänzen

Ort und Stil

Game/Shared-Test nach Subject in tests/HolodeckArena.Game3D.Tests; Bootstrap in tests/HolodeckArena.Bootstrap.Tests. Datei <Subject>Tests.cs, xUnit [Fact]/[Theory], Arrange–Act–Assert, deterministische Werte und keine Reihenfolge-/Zeit-/Netzabhängigkeit.

Vorgehen

1. Reine Domain aus Node lösen oder bestehenden Shared-Typ direkt testen.
2. Testdouble als kleine lokale Klasse verwenden, etwa IDungeonEnemySpawner; nicht echten Nakama/Dockerzugriff in Unit Tests.
3. Bei Seedlogik zweimal gleichen Seed und Hash/Definition vergleichen; anderen Seed kontrolliert abgrenzen.
4. Bei Catalogeinträgen Lookup, Duplicate/invalid references, Compatibility und Version prüfen. Resourceexistenz benötigt Godot-Kontext und darf nicht nur durch res://-Stringtest simuliert werden.
5. Godot-Typen ohne SceneTree nur testen, wenn ihre Methoden keinen Engine-Lifecycle brauchen. Signals, _Ready, Physics, Navigation und PackedScene-Loads manuell oder über künftiges Godot-Testharness.

Ausführen

dotnet test tests/HolodeckArena.Game3D.Tests/HolodeckArena.Game3D.Tests.csproj --filter FullyQualifiedName~Subject
dotnet test tests/HolodeckArena.Bootstrap.Tests/HolodeckArena.Bootstrap.Tests.csproj

CI führt derzeit keinen separaten allgemeinen Testworkflow aus; Release/Deploy sind kein Ersatz. Nakama besitzt Node-Tests unter src/server/nakama/modules/tests; sicherheitskritische Backendlogik braucht darüber hinaus einen Container-/PostgreSQL-Integrationstest oder dokumentierten Smoke-Test.

Verwandt: Testing, Konventionen, Änderungsmatrix.