# Architecture des tests ## Séparation physique Le code de production sous `src/` ne contient aucun corps de test. Les tests unitaires résident dans `unit_tests/` à la racine de la crate et sont rattachés explicitement au module testé : ```rust #[cfg(test)] #[path = "../unit_tests/example.rs"] mod tests; ``` Les tests d’intégration, d’environnement et les smokes automatisés résident sous `tests/`, selon le mécanisme Cargo standard. Cette séparation reprend le modèle utilisé dans KSP : elle garde `src/` exclusivement consacré au code de production tout en permettant aux unit tests d’accéder au contexte privé du module auquel ils sont rattachés. ## Tests ciblés Un delta ne relance pas automatiquement tous les tests du workspace. Les crates affectées sont testées explicitement avec `cargo test -p ... --all-targets --all-features`. La suite globale est conservée comme gate lourde pour les frontières de version, la stabilisation et les changements transverses dont l’impact ne peut pas être borné avec confiance. ## Tracing dans les tests `game-logging-lib::with_test_tracing` installe un subscriber local au thread pour la durée du corps de test. Il évite les conflits liés à plusieurs initialisations globales et permet aux tests d’émettre des événements `tracing` consultables avec les mécanismes habituels du test runner.