Définir le comportement attendu

Un script de suivi de dépenses peut s’exécuter sans erreur tout en donnant un résultat inutilisable : une dépense mal décrite, un total incohérent ou un récapitulatif incomplet suffisent à poser problème. Avant d’ajouter la saisie et l’export, vous allez préciser ce que le programme doit accepter et produire. Cette description servira de référence pour vérifier chaque évolution.

Décrire le comportement avant de coder

Un cahier des charges fonctionnel décrit les services attendus du programme sans imposer leur réalisation technique. Pour le projet, le périmètre est un script Python dans suivi_depenses.py : il devra permettre de saisir une dépense, de la classer, de calculer des totaux et de préparer un récapitulatif exportable. Le HTML fourni représente les zones du projet ; il ne remplace pas le script et n’est pas modifié dans cette leçon.

Pour chaque opération, séparez trois éléments : les données reçues, le traitement attendu et le résultat observable. Cette séparation évite les formulations floues comme « gérer correctement les dépenses ». Par exemple, pour une dépense de 12,50 €, dans la catégorie « Transport », décrite comme « Billet de train », le script doit conserver ces trois informations et pouvoir les retrouver dans son récapitulatif.

Lister les entrées et les résultats

Les résultats doivent être assez précis pour être vérifiés. Pour une dépense de 12,50 € dans « Transport » et une autre de 7,50 € dans « Repas », le total attendu est de 20,00 €. Les montants par catégorie attendus sont de 12,50 € pour « Transport » et de 7,50 € pour « Repas ». Vous pourrez ainsi comparer les résultats affichés ou exportés à des valeurs connues.

Prévoir les cas limites

Un cas de test représentatif décrit une situation précise, les données utilisées et le résultat attendu. Les cas habituels ne suffisent pas : examinez aussi une liste vide, une seule dépense, plusieurs dépenses dans la même catégorie et une dépense avec un montant nul. Ces situations révèlent notamment si le script sait produire un récapitulatif même lorsqu’il n’a rien à afficher.

• Aucune dépense : le total vaut 0,00 € et le récapitulatif ne présente aucune dépense fictive.
• Une dépense de 12,50 € : elle apparaît une fois et le total vaut 12,50 €.
• Deux dépenses de 12,50 € et 7,50 € dans des catégories différentes : le total vaut 20,00 € et chaque catégorie affiche son propre montant.
• Deux dépenses dans la même catégorie : le total de cette catégorie correspond à la somme des deux montants.
• Montant nul : le comportement doit être défini explicitement ; pour ce projet, la dépense peut être conservée et son montant compte pour zéro.
• Montant négatif ou saisie non numérique : le script ne doit pas intégrer silencieusement une valeur invalide ; les règles de refus ou de nouvelle saisie seront réalisées dans la leçon consacrée à la validation.

Transformer les attentes en critères vérifiables

Un critère d’acceptation exprime une condition observable qui permet de décider si le résultat répond au besoin. Préférez « avec deux dépenses de 12,50 € et 7,50 €, le total affiché est 20,00 € » à « les totaux sont corrects ». Le premier énoncé peut être vérifié sans interprétation ; le second ne précise ni les données ni le résultat attendu.

• Chaque dépense enregistrée conserve son montant, sa catégorie et sa description.
• Le total général correspond à la somme des montants enregistrés.
• Chaque catégorie présente le total de ses dépenses, sans mélanger les catégories.
• Une saisie invalide est signalée ou redemandée ; elle ne modifie pas les résultats.
• Le récapitulatif exporté correspond aux données utilisées pour les calculs.

Ces critères décrivent le comportement visé, pas encore le code à écrire. Votre fichier contient déjà les données structurées et la fonction d’affichage avec son résultat calculé ; vous poursuivrez directement dans suivi_depenses.py, sans remplacer ces éléments par un nouveau projet. Les prochains ajouts devront satisfaire les cas de test préparés ici.

À retenir

• Décrivez les entrées, les traitements attendus et les résultats observables.
• Incluez les situations habituelles et les cas limites dans vos tests.
• Formulez des critères d’acceptation précis, avec des données et des résultats vérifiables.
• Gardez les règles métier explicites : une valeur nulle et une saisie invalide ne sont pas équivalentes.

Dans la prochaine leçon, vous mettrez en œuvre la saisie des dépenses et la validation de leurs champs à partir de ces attentes.