Chapitre 04 — Tests internes du framework#
Comment Ocarina se teste lui-même. Cinq familles de tests, une politique de couverture lucide, un rapport Allure historisé sur GitHub Pages.
Plan#
| # | Fichier | Sujet |
|---|---|---|
| 01 | 01-strategy.md | Stratégie « dehors comme un utilisateur » + le conftest.py (FakeDriver, RecordingPOM, builders). |
| 02 | 02-cram-prysk.md | Cram tests (prysk) : fichiers .t |
| 03 | 03-pytest-scenarios.md | Scénarios de test appliqués au framework (pytest + allure + hypothesis). |
| 04 | 04-mypy-plugins-types.md | Tests sur le typage statiques via pytest-mypy-plugins (*.yml). |
| 05 | 05-syrupy-snapshots.md | Snapshot tests (syrupy) pour pretty_print_results et results_to_json. |
| 06 | 06-hypothesis-properties.md | Property-based testing pour les invariants. |
| 07 | 07-coverage-policy.md | Politique de couverture : ce qui est testé, ce qui ne l’est PAS, pourquoi. |
| 08 | 08-allure-history.md | Allure + action composite allure-history + déploiement GH Pages. |
Tableau récapitulatif#
| Famille | Outil | Quantité | Sujet | Cible |
|---|---|---|---|---|
| Scénarios | pytest + allure-pytest | ~15 fichiers test_*.py | DSL, orchestration, acteur Playwright | Couvre le comportement |
| Cram | prysk | 15 fichiers .t | CLI Selenium + Playwright : parsing, validations, defaults | Couvre la surface utilisateur CLI |
| Types statiques | pytest-mypy-plugins | ~5 fichiers *test_types.yml | Inférences de type, narrowing, erreurs attendues | Couvre le typage |
| Snapshots | syrupy | 2 fichiers .ambr | Sortie de pretty_print_results, results_to_json | Couvre le format de sortie |
| Property-based | hypothesis | 1 fichier (test_invariants_properties.py) | Comportement sur valeurs aléatoires | Couvre la robustesse aux inputs |
Approche#
Dans le fichier conftest.py :
Philosophy : exercise the framework from the outside the way a real user does. No asserts on private attributes, no mocks of framework internals — just a minimal fake driver + driver pool, and small constructors for Scenario / Test / TestSuite / TestCampaign / TestCycle.
Les tests n’inspectent pas les mécanismes internes (phénomène de la sonde anale*). Ils exercent le framework comme un projet utilisateur le ferait. C’est la garantie que les tests valident le contrat public, pas l’implémentation.
* Attribuer ce phénomène sous forme de citation à un confrère de la littérature pour les plus facétieux.