NRF SDK 0.9Maintenance
Tester son mod
Vérifiez les décisions, le paquet et le comportement en partie avec des preuves adaptées à chaque niveau.
Tester les décisions sans ouvrir le jeu
Prérequis : le premier mod et sa configuration Gradle. Créez le fichier ci-dessous dans le même projet. Le plugin fournit kotlin.test et prépare les ressources pour les tests Windows.
import kotlin.test.Test
import kotlin.test.assertEquals
import kotlin.test.assertNotNull
import nimby.*
class SignalTests {
@Test fun unknownBlockStaysClosed() {
val mod = nimby.mod.createMod()
val decision = mod.evaluate(
mapOf("active" to true),
Observation(block = Occupancy.Unknown, fresh = true, routeKnown = true)
)
val indication = assertNotNull(mod.indication(decision)?.of(nimby.mod.firstSignal))
assertEquals(nimby.mod.Aspect.Closed, indication.aspect)
assertEquals(nimby.mod.Reason.Unknown, indication.reason)
}
@Test fun knownClearBlockOpens() {
val mod = nimby.mod.createMod()
val decision = mod.evaluate(
mapOf("active" to true),
Observation(block = Occupancy.Clear, fresh = true, routeKnown = true)
)
val indication = assertNotNull(mod.indication(decision)?.of(nimby.mod.firstSignal))
assertEquals(nimby.mod.Aspect.Open, indication.aspect)
assertEquals(nimby.mod.Reason.Clear, indication.reason)
}
}.\gradlew.bat windowsTestLe premier test vérifie le repli ; le second vérifie le cas nominal. mod.indication(decision)?.of(firstSignal) retrouve les enums du modèle : comparez leurs valeurs typées, jamais le code Decision.aspect à un ordinal local. Les tests vérifient aussi le motif. Pour plusieurs modèles ou des dépendances entre voisins, utilisez evaluateNetwork avec des Signal préparés et vérifiez chaque indication avec son modèle.
| Situation à fournir au test | Résultat à définir |
|---|---|
| Occupation inconnue, observation périmée ou itinéraire inconnu | Un repli explicite, sans déduire que la voie est libre. |
| Réglage indisponible, valeur par défaut, bornes numériques | Une décision cohérente avec le contrat du réglage. |
| Voisin absent, autre modèle, chaîne ou cycle | Une résolution bornée et un repli testable. |
| Signal fermé pour deux motifs différents | Les consignes de conduite attendues pour chaque motif. |
| Animation juste avant, à et après une limite de phase | L’image attendue pour un temps simulé fourni explicitement. |
Vérifier chaque niveau séparément
| Vérification | Ce qu’elle établit | Ce qui reste à vérifier |
|---|---|---|
| windowsTest | Résultat des règles sur les entrées du test. | Données et comportement dans une vraie partie. |
| assembleReleaseMod | Production des fichiers et du catalogue du mod. | Chargement et comportement du paquet. |
| verifyNativeMod | Chargement, arrêt et rechargement hors jeu. | Interactions avec le jeu et son interface. |
| Essai en partie | Résultat sur la sauvegarde, le SDK et le jeu utilisés. | Autres cartes, tailles de réseau et scénarios. |
Un rapport UP-TO-DATE signifie que Gradle réutilise un résultat dont les entrées sont inchangées. Pour exécuter de nouveau une tâche lors d’une recette précise, utilisez --rerun-tasks et conservez la commande avec le rapport. Ce choix n’est pas nécessaire à chaque modification de texte.
.\gradlew.bat windowsTest verifyNativeMod --rerun-tasksRendre un essai en partie reproductible
- Préparez une copie ou une sauvegarde de test et notez le point de départ. Conservez les versions du jeu, du SDK et des mods.
- Définissez un résultat observable : indication, consigne appliquée, panneau, objets créés ou résultat de ticket. Fixez aussi le cas de refus attendu.
- Essayez la pause, la reprise, plusieurs vitesses et un chargement de partie. Vérifiez que les données de l’ancienne session ne déclenchent pas une action.
- Pour un outil de construction, vérifiez l’aperçu, la confirmation, les résultats partiels, les objets créés et l’annulation autorisée.
- Terminez l’essai en fermant vos fenêtres et connexions et en retirant les effets temporaires. Notez ce qui a été restauré.