Fixer le périmètre et les critères de livraison
Objectif : Définir les opérations métier et les résultats attendus pour la version industrialisée de l’outil de dépenses.
Fixer ce qui doit être livré
Une suite de tests qui passe ne suffit pas, à elle seule, à prouver qu’un outil répond au besoin. Il faut savoir quelles opérations la version doit prendre en charge et quels résultats vous considérerez comme corrects. Vous allez formaliser ce périmètre avant d’assembler les modules et de lancer la validation complète.
Le projet fil rouge représente un outil qui reçoit des dépenses, les valide, les agrège et peut consulter des données distantes de façon asynchrone. Pour cette livraison, distinguez les comportements indispensables de ceux qui ne sont pas prévus : vous éviterez ainsi de traiter une amélioration facultative comme une condition de réussite, ou de livrer une fonction essentielle sans l’avoir vérifiée.
Délimiter les opérations métier
Commencez par écrire le parcours attendu en termes observables, sans décrire prématurément l’organisation interne des modules. L’utilisateur doit pouvoir soumettre une dépense avec une description et un montant positif, obtenir un résultat de traitement compréhensible, puis consulter le nombre de dépenses acceptées et leur montant total. Une entrée invalide ne doit pas être comptabilisée comme une dépense traitée.
La collecte distante constitue un autre comportement à borner. La version doit pouvoir demander des données à plusieurs sources sans dépasser le plafond de concurrence prévu, et produire un résultat exploitable même lorsqu’une consultation échoue ou dépasse son délai. Les limites précises dépendent du service visé ; pour l’exercice, inscrivez une valeur de configuration à confirmer plutôt que d’inventer un engagement de disponibilité externe.
Rendre les critères vérifiables
Un critère d’acceptation décrit une condition que vous pouvez vérifier par un test, une commande ou une mesure. Évitez les formulations comme « rapide », « robuste » ou « bien typé » si elles ne sont associées à aucun constat concret. Pour chaque critère, notez l’action, le résultat attendu et la méthode de vérification ; vous pourrez ensuite relier les exigences aux tests et aux outils déjà étudiés.
| Domaine | Critère d’acceptation | Vérification attendue |
|---|---|---|
| Données | Une dépense valide conserve sa description et son montant ; un montant nul ou négatif est refusé. | Tests unitaires des cas valides et invalides. |
| Agrégation | Le total et le nombre affichés correspondent exactement aux dépenses acceptées. | Comparaison avec le jeu de référence ci-dessous. |
| Collecte | Une consultation en échec ou expirée ne fait pas échouer toute la collecte ; la concurrence respecte le plafond configuré. | Tests ciblés de la collecte et vérification de la limite. |
| Qualité du code | Les interfaces publiques du paquet sont annotées et la vérification statique ne signale pas d’erreur. | Exécution de mypy selon la configuration du projet. |
| Performance | L’agrégation optimisée conserve le résultat de référence et reste plus rapide que la version naïve sur le scénario mesuré. | Scénario reproductible de scripts/profiler.py ; comparaison avant-après. |
Les critères doivent rester proportionnés à ce que vous contrôlez. Par exemple, vous pouvez exiger qu’une consultation respecte un délai donné dans un test simulé, mais vous ne pouvez pas garantir la disponibilité d’un service tiers à partir d’un test local. Gardez cette distinction dans le cahier : le logiciel peut gérer un échec externe sans pouvoir empêcher qu’il survienne.
Établir un jeu de référence
Un jeu de données de référence fixe les entrées et les résultats métier attendus. Il permet de vérifier plusieurs composants avec la même base et de repérer une divergence entre le résultat du service et ce que le besoin prévoit. Pour éviter les écarts d’arrondi, exprimez les montants en centimes dans ce petit oracle de vérification ; le modèle de données de production reste défini dans les modules prévus par le contrat.
depenses_reference = [
{"description": "Transport", "centimes": 1250},
{"description": "Repas", "centimes": 2380},
{"description": "Fournitures", "centimes": 499},
]
nombre_attendu = 3
total_attendu_centimes = 4129
assert len(depenses_reference) == nombre_attendu
assert sum(depense["centimes"] for depense in depenses_reference) == total_attendu_centimes
print(f"Dépenses attendues : {nombre_attendu}")
print(f"Total attendu : {total_attendu_centimes / 100:.2f} €")Dépenses attendues : 3
Total attendu : 41.29 €Ce fragment est autonome et exécutable ; il fixe les entrées de référence et contrôle les deux valeurs qui serviront d’attendus, sans dépendre d’un module encore à assembler. Vérifiez aussi que votre cahier précise le traitement d’une liste vide et d’une entrée invalide : ces cas ne figurent pas dans ce jeu minimal, mais doivent être couverts par les tests appropriés. Ne transformez pas l’oracle en copie de la logique de production, car deux implémentations identiques pourraient reproduire la même erreur.
À retenir
- Délimitez les opérations que la version doit assurer et nommez explicitement ce qui reste hors périmètre.
- Formulez chaque critère sous une forme observable, avec une méthode de vérification.
- Conservez un jeu de référence déterministe et ses résultats attendus pour contrôler le comportement métier.
- Séparez les garanties vérifiables localement des dépendances externes, puis mesurez les performances sur le scénario reproductible déjà préparé.
À la prochaine étape, vous assemblerez les modules autour de ces critères et des contrats définis dans les leçons précédentes.