29 lines
1.4 KiB
Markdown
29 lines
1.4 KiB
Markdown
<!-- 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.
|