0.1.0-0-pre.4

docs/testing/001-TEST_ARCHITECTURE.md

@@ -0,0 +1,28 @@
+<!-- file: docs/testing/001-TEST_ARCHITECTURE.md -->
+<!-- version: 1 -->
+
+# 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.