Valider le parcours complet

Un outil peut réussir ses tests de calcul tout en échouant lorsque ses modules sont assemblés. Un test de bout en bout permet de vérifier que les dépenses traversent le service, le stockage et la collecte asynchrone sans rompre leurs contrats.

Dans cette leçon, vous exécutez les tests déjà prévus par le projet et vous vérifiez séparément les composants métier et asynchrones. Vous ne modifiez pas le périmètre de l’outil : l’objectif est de confirmer le comportement assemblé avec le stockage en mémoire et la consultation simulée.

1. Lancer la suite complète

Placez-vous à la racine du projet, là où se trouve pyproject.toml. La commande suivante demande à pytest d’exécuter tous les tests, y compris ceux du service et de la collecte asynchrone. Utilisez la même commande après chaque modification qui pourrait changer un contrat ou un résultat métier.

python -m pytest

La sortie indique les tests exécutés et leur état. Une exécution réussie se termine par un récapitulatif sans tests en échec ; le nombre exact dépend du contenu de la suite.

En cas d’échec, lisez d’abord le nom du test et l’assertion qui a échoué, puis remontez à la première ligne du projet dans la trace. Un échec n’implique pas nécessairement une erreur dans le dernier module modifié : il peut révéler une incompatibilité entre deux composants. Corrigez la cause, puis relancez la suite complète, pas seulement le test qui a échoué.

2. Isoler les étapes du parcours

Quand la suite complète échoue, ciblez les deux modules de tests du projet pour localiser la zone concernée. Le premier commande les tests unitaires du service ; le second cible la collecte asynchrone. Ces commandes sont des outils de diagnostic : elles ne remplacent pas la validation finale de l’ensemble.

python -m pytest tests/test_service.py
python -m pytest tests/test_collecte.py

Chaque commande affiche son propre récapitulatif. Les tests de collecte doivent se terminer sans dépendre d’un service distant : le scénario assemblé utilise la consultation simulée prévue pour le projet.

Les tests de collecte doivent vérifier le résultat observable du traitement : les réponses sont associées aux dépenses ou aux devises attendues, et les erreurs prévues par le scénario ne font pas disparaître les autres résultats attendus. Les tests unitaires du service, eux, contrôlent les règles métier et les échanges avec le stockage. Vous n’avez pas besoin de réexpliquer ces mécanismes : ils ont été étudiés dans les leçons précédentes sur les tests isolés, les mocks et asyncio.

3. Vérifier les contrats et la couverture

Les tests d’exécution et la vérification statique ne répondent pas à la même question. Après la suite pytest, relancez mypy sur le paquet afin de repérer les incohérences de types que les exemples de test n’ont pas déclenchées. Utilisez la configuration du projet dans pyproject.toml, déjà mise en place dans la leçon consacrée à mypy.

python -m mypy src/depenses

mypy termine sans diagnostic si les modules vérifiés respectent la configuration de types. En présence d’un diagnostic, corrigez le contrat concerné et relancez la commande.

Vous pouvez ensuite mesurer la couverture de la suite sans modifier les tests ni introduire une dépendance à un service externe. Cette mesure indique quelles lignes du paquet ont été exécutées ; elle ne prouve pas à elle seule que chaque résultat est correct. Examinez notamment les chemins de collecte et les cas d’erreur utiles, plutôt que de chercher un pourcentage maximal.

python -m coverage run -m pytest
python -m coverage report -m

Le rapport présente la couverture par fichier et les lignes non exécutées. Il complète les résultats des tests, mais ne remplace ni leur lecture ni les vérifications de types.

4. Contrôler le parcours de bout en bout

Pour conclure, reliez les résultats aux critères de livraison fixés précédemment : les tests du service passent, la collecte asynchrone se termine avec les résultats attendus et l’ensemble de la suite reste vert. Si le point d’entrée de démonstration du projet est utilisé pendant cette vérification, exécutez-le selon la commande documentée dans le paquet et confirmez qu’il fonctionne sans service distant. Ne déduisez pas la réussite de bout en bout d’un seul test unitaire.

Gardez les vérifications séparées dans votre compte rendu de travail : pytest valide le comportement testé, mypy les contrats de types et Coverage.py l’étendue d’exécution. Le profilage, lui, n’est pas nécessaire pour établir la validité fonctionnelle ; les mesures de performance seront documentées dans la prochaine leçon.

À retenir

• Lancez la suite complète avec python -m pytest après toute modification du projet.
• Ciblez tests/test_service.py ou tests/test_collecte.py pour localiser un échec.
• Validez séparément l’exécution des tests, les types avec mypy et la couverture avec Coverage.py.
• Confirmez que la collecte asynchrone fonctionne avec le scénario simulé, sans rendre les tests dépendants d’un service distant.

La prochaine leçon permettra de consigner les résultats de validation et les seuils de performance retenus pour la livraison.