Documenter les résultats de livraison
Objectif : Présenter les vérifications de types, les résultats des tests et les mesures de performance obtenues.
Une livraison n’est pas justifiée par le fait que les commandes ont été lancées : leurs résultats doivent être conservés et comparés à des critères explicites. Vous allez établir un compte rendu qui distingue les vérifications de types, les tests, la couverture et les mesures de performance, sans présenter une valeur non mesurée comme un résultat.
Préparer une validation traçable
Reprenez le cahier de vérification défini pour le projet et reliez chaque critère à une preuve : commande exécutée, résultat obtenu et décision. Notez aussi le contexte utile pour reproduire la validation, notamment la version de Python, la révision du code et l’environnement dans lequel les commandes ont été lancées. Si un critère n’a pas été vérifié, indiquez-le comme non vérifié plutôt que de le traiter implicitement comme réussi.
python -m mypy src/depenses
python -m pytest
python -m coverage run --branch -m pytest
python -m coverage report -mLes commandes affichent les diagnostics de mypy, le bilan des tests, puis le rapport de couverture avec les lignes manquantes. Consignez les valeurs réellement affichées dans votre environnement.Exécutez les contrôles dans un environnement où les outils du projet sont installés. La commande de couverture relance les tests avec la mesure des branches, puis le rapport présente notamment les lignes exécutées et manquantes ; elle ne remplace pas le bilan fonctionnel de pytest. Ces commandes ne modifient pas les fichiers métier, mais produisent des résultats qui peuvent varier selon la version des outils et l’état du code.
Consigner les résultats fonctionnels
Pour mypy, notez la commande, le périmètre analysé et le nombre de diagnostics. Une sortie sans erreur signifie que les vérifications configurées n’ont pas signalé d’incohérence de types ; elle ne prouve ni que toutes les valeurs possibles sont valides, ni que le comportement métier est correct. Pour pytest, consignez le nombre de tests réussis, échoués ou ignorés, ainsi que toute erreur de collecte ou de configuration.
Le rapport de couverture complète ces informations : relevez le pourcentage et les éventuelles lignes manquantes, puis vérifiez si celles-ci concernent des branches pertinentes du service ou de la collecte. Un pourcentage élevé ne suffit pas à conclure que les scénarios importants sont bien testés. Dans le compte rendu, associez chaque résultat à son interprétation et, si nécessaire, à une action de suivi.
Documenter les performances et décider
Pour la performance, rattachez la mesure au scénario reproductible déjà préparé : indiquez le jeu de données, le nombre de répétitions, la statistique retenue et le temps mesuré. Mentionnez la machine et les conditions susceptibles d’influencer le résultat, par exemple une charge inhabituelle ou une exécution sous profiler. Le profiling sert à expliquer où le temps est dépensé ; ne présentez pas son temps d’exécution instrumenté comme un benchmark comparable.
Un seuil de performance n’a de sens que s’il est documenté avec son périmètre et ses conditions de mesure. Comparez le résultat obtenu à ce seuil, puis indiquez si le critère est satisfait, non satisfait ou impossible à évaluer. Si aucune limite chiffrée n’a été fixée, rapportez la mesure et précisez qu’elle ne permet pas, à elle seule, de déclarer le critère conforme.
Terminez par une décision explicite : livraison validée, bloquée ou validée sous réserve. Justifiez-la en reliant les critères d’acceptation aux preuves collectées ; énumérez les anomalies restantes et les réserves. Cette décision ne demande pas de modifier les modules du projet : l’état actuel permet de lancer les contrôles et de documenter leurs résultats, sans présumer de leur succès avant exécution.
À retenir
- Reliez chaque critère de livraison à une commande, un résultat réel et une interprétation.
- Distinguez la vérification des types, les tests fonctionnels et la couverture.
- Décrivez le scénario et les conditions des mesures de performance ; ne confondez pas benchmark et profilage.
- Ne concluez qu’à partir de critères mesurables et signalez explicitement les réserves.