Vérifier le programme de bout en bout

Un programme peut réussir chaque opération séparément et échouer lorsque vous les enchaînez : lecture du relevé, validation, sauvegarde JSON, appel à l’API et calcul du total converti. Vous allez vérifier ce parcours avec des données contrôlées, puis provoquer une erreur volontaire pour confirmer qu’elle est signalée sans produire un résultat trompeur.

Vous disposez déjà des fonctions métier et des traitements d’erreur vus dans les leçons précédentes. Ici, l’objectif n’est pas de modifier leur fonctionnement, mais d’exécuter l’application comme un utilisateur le ferait et de comparer les effets observés aux résultats attendus.

Préparer un relevé de test

Créez un fichier releve_test.csv à la racine du projet. Il contient deux dépenses faciles à contrôler mentalement : 42,80 € et 18,50 €, soit un total de 61,30 €. Le fichier respecte le schéma utilisé par le projet : les noms de colonnes sont date, libelle et montant.

date,libelle,montant
2025-01-15,Courses,42.80
2025-01-16,Transport,18.50

Lancez l’application depuis la racine du projet, dans l’environnement virtuel déjà préparé. La commande ci-dessous suppose que l’argument positionnel de depenses.main est le chemin du relevé, comme dans le parcours d’import. Si votre aide en ligne indique une autre forme d’argument, utilisez celle définie par votre point d’entrée plutôt que de modifier le programme pour ce test.

python -m depenses.main releve_test.csv

Le programme signale l’enregistrement de 2 dépenses et affiche un total converti à deux décimales. La valeur convertie dépend du taux retourné par l’API au moment de l’exécution.

Le taux de change peut varier : ne comparez donc pas le total converti à une valeur fixe supposée valable en permanence. Vérifiez plutôt que le taux affiché ou utilisé est positif et que le total correspond à 61,30 multiplié par ce taux, arrondi uniquement pour l’affichage. Contrôlez également que depenses.json a été créé et contient deux dictionnaires avec les trois champs attendus.

Tester une donnée invalide

Créez une seconde version du relevé où le montant de la deuxième ligne n’est pas numérique. Ce cas vérifie que l’erreur de conversion ou de validation remonte jusqu’au point d’entrée, qui doit présenter un message compréhensible et terminer avec un code d’échec. Une ligne rejetée ne doit pas être présentée comme une dépense enregistrée.

date,libelle,montant
2025-01-15,Courses,42.80
2025-01-16,Transport,à déterminer

python -m depenses.main releve_invalide.csv
echo $?

Le programme affiche une erreur contextualisée, idéalement avec le numéro de la ligne, et la commande echo affiche un code différent de 0.

Distinguer les pannes de l’API

Un test avec un relevé valide dépend aussi du réseau et du service distant. En cas de panne, vérifiez que le message distingue clairement l’échec de l’API d’un problème CSV. Si un taux de repli est configuré selon les règles du projet, le programme doit le signaler comme tel ; sans taux de repli valide, il ne doit pas inventer un taux ni afficher une conversion comme si elle provenait du service.

Pour rendre le résultat reproductible, notez pour chaque exécution le fichier fourni, le nombre de dépenses annoncé, le contenu JSON obtenu, le taux utilisé et le code de sortie. Relancez ensuite le test valide, puis le test invalide. Vous vérifiez ainsi les deux branches principales du parcours sans confondre une variation normale du taux avec une régression du calcul.

Automatiser les vérifications métier

Le projet contient aussi des fichiers de tests pour les calculs de transactions.py et les opérations de fichiers.py. Exécutez la suite avec la bibliothèque standard unittest depuis la racine. Cette commande découvre les fichiers dont le nom commence par test_ dans le dossier indiqué et permet de vérifier les fonctions sans solliciter l’API à chaque test.

python -m unittest discover -s tests -v

Chaque test exécuté est affiché. La fin indique le nombre de tests et OK si aucun test n’a échoué ; une erreur ou un échec est accompagné de détails permettant d’identifier le test concerné.

Si la suite échoue, lisez le nom du test et son résultat attendu avant de modifier le code. Une erreur de test peut signaler un défaut dans une fonction, une hypothèse incorrecte sur les données ou un fichier temporaire qui n’a pas été nettoyé. Après correction, relancez les tests puis les deux scénarios de bout en bout : les tests unitaires ne remplacent pas la vérification du parcours complet.

À retenir

• Préparez un relevé valide et calculez son total avant de lancer l’application.
• Vérifiez les dépenses enregistrées, le JSON produit, le taux utilisé et le total converti.
• Provoquez une erreur de donnée et contrôlez le message ainsi que le code de sortie.
• Distinguez une panne de l’API d’une erreur CSV et signalez tout taux de repli.
• Exécutez les tests automatisés avec python -m unittest discover -s tests -v.

Vous pouvez maintenant vérifier que le suivi reste cohérent dans des conditions normales comme en présence d’entrées invalides ou d’une indisponibilité externe.