4.5Tests automatiques & qualité
L'essentiel en 30 secondes
- Trois niveaux de vérification : les tests unitaires (une procédure ou une classe donne-t-elle le bon résultat ? — le plus rentable car il cible une règle métier), les tests d'interface (rejouer un scénario enregistré : ouvrir, saisir, valider, vérifier) et l'audit du projet.
- Le principal intérêt des tests automatiques n'est pas de trouver des bugs aujourd'hui mais de détecter les RÉGRESSIONS demain : retester toute l'application à la main est impossible, donc on ne le fait pas — et les régressions passent en production.
- Bonnes pratiques : commencer par le cœur métier (calculs, règles critiques), tester les cas limites (zéro, valeurs vides, changements d'année), écrire un test à chaque bug corrigé — et garder les tests à jour, car des tests obsolètes ignorés sont pires que pas de tests.
Mini-cas filé — Yacine sécurise les calculs de son négoce
Yacine, développeur WinDev dans une PME de négoce de matériel électrique à Oran, vient de corriger un bug sur le calcul des remises : un client s'en est aperçu trois mois plus tard sur sa facturation. Il décide de ne plus jamais se contenter de « ça a l'air de marcher ». Il écrit d'abord des tests unitaires sur le cœur métier : le calcul de la TVA sur le catalogue électrique, les remises, les échéances. Il teste systématiquement les cas limites — taux à zéro, montant négatif, date de changement d'année — car c'est là que se cachent les bugs. Il enregistre ensuite quelques scénarios d'interface sur le parcours critique (saisie d'une commande de bout en bout) pour détecter les régressions. Et il s'impose une règle : à chaque bug corrigé, il écrit un test qui le reproduit, pour qu'il ne revienne jamais. Il note le vrai bénéfice, le plus sous-estimé : la confiance de modifier le code sans peur. Il complète par la revue de code et les retours des utilisateurs : la qualité dépasse les tests.
Cas autonome de cette section : il revient dans le cours, le schéma, le script et le défi 48h de la section 4.5.
1. Trois niveaux de vérification
La qualité d'une application ne se décrète pas : elle se construit et se vérifie. WinDev distingue plusieurs approches. (1) Les tests unitaires : vérifier qu'une procédure ou une classe donne le bon résultat pour des entrées données (le calcul de TVA renvoie-t-il la bonne valeur ? et pour un taux à zéro ? et pour un montant négatif ?). C'est le test le plus rentable, car il cible précisément une règle métier. (2) Les tests d'interface (IHM) : rejouer automatiquement un scénario d'utilisation (ouvrir une fenêtre, saisir, valider, vérifier le résultat) — WinDev permet d'enregistrer ces scénarios. (3) L'audit et les outils d'analyse du projet, qui signalent anomalies et points d'amélioration.
2. Les tests automatiques changent tout
Pourquoi les tests automatiques changent tout ? Parce qu'ils sont rejouables à volonté. Leur bénéfice principal n'est pas de trouver des bugs aujourd'hui, mais de détecter les régressions demain : quand on modifie une règle ou corrige un défaut, comment savoir qu'on n'a rien cassé ailleurs ? Retester manuellement toute l'application est impossible en pratique — on ne le fait donc pas, et les régressions passent en production. Les tests automatiques font ce travail en quelques minutes. C'est aussi, souvent sous-estimé, la confiance de modifier le code : sans tests on empile des rustines, avec tests on refactorise sereinement.
3. Bonnes pratiques & qualité au sens large
Quelques bonnes pratiques. (1) Commencez par le cœur métier (calculs, règles critiques) plutôt que de viser une couverture totale. (2) Testez les cas limites (zéro, valeurs vides, valeurs extrêmes, dates de changement d'année) : c'est là que se cachent les bugs. (3) Écrivez un test à chaque bug corrigé pour garantir qu'il ne reviendra pas. (4) Gardez les tests à jour : des tests obsolètes qu'on ignore sont pires que pas de tests. Enfin, la qualité dépasse les tests : revue de code, documentation, conventions et retours des utilisateurs en font aussi partie.
🔎 Exemple concret — 🔎 Exemple concret — Un test unitaire et ses cas limites
Cibler une règle métier, comme le fait Yacine :
// Test unitaire du calcul de TVA du catalogue electrique
PROCEDURE Test_TVA()
sTTC est un numerique = CalculeTTC(1000, 19)
SI sTTC <> 1190 ALORS
Erreur("TVA attendue 1190, obtenue : " + sTTC)
FIN
// Cas limites : taux a zero et montant negatif
SI CalculeTTC(0, 19) <> 0 ALORS
Erreur("Cas limite zero non gere")
FINLecture : un test unitaire vérifie une procédure pour des entrées données, y compris les cas limites où se cachent les bugs.
Leçon : ce test devient le garde-fou qui détecte une régression si la règle est modifiée plus tard.
Vocabulaire de la section
- Test unitaire
- Vérifier qu'une procédure ou une classe donne le bon résultat pour des entrées données — le test le plus rentable, car il cible une règle métier.
Exemple simple : Yacine teste le calcul de TVA du catalogue électrique.
Ce que ce n'est pas : cliquer à la main dans l'interface pour « voir si ça marche ».
Réflexe : vérifier une règle → le test unitaire.
- Test d'interface (IHM)
- Rejouer automatiquement un scénario d'utilisation (ouvrir, saisir, valider, vérifier) ; WinDev permet d'enregistrer ces scénarios.
Exemple simple : Yacine enregistre la saisie d'une commande de bout en bout.
Ce que ce n'est pas : un test qui ne vérifie que des calculs isolés.
Réflexe : rejouer un parcours → le scénario d'interface.
- Régression
- Un défaut introduit par une modification dans une partie qui fonctionnait — le risque principal en maintenance, et la raison d'être des tests automatiques.
Exemple simple : La correction des remises de Yacine ne doit pas casser les totaux.
Ce que ce n'est pas : un bug présent depuis la première version.
Réflexe : protéger l'existant → contre les régressions.
- Cas limites
- Zéro, valeurs vides, valeurs extrêmes, changements d'année, chaînes très longues, caractères spéciaux : là où se cachent la plupart des bugs.
Exemple simple : Yacine teste une remise de 0 % et un montant négatif.
Ce que ce n'est pas : ne tester que des valeurs « normales », bien rondes.
Réflexe : trouver les bugs → tester les cas limites.
- Qualité au sens large
- Au-delà des tests : revue de code, documentation, conventions d'équipe et retours des utilisateurs font aussi partie de la démarche qualité.
Exemple simple : Yacine fait relire son code et note les retours des commerciaux.
Ce que ce n'est pas : croire que les seuls tests suffisent à la qualité.
Réflexe : démarche complète → la qualité au sens large.
En pratique — En pratique — Mettre en place des tests
- Commencez par des tests unitaires sur le cœur métier : les calculs et règles critiques (TVA, remises, échéances) — le meilleur rapport effort/bénéfice, comme Yacine.
- Testez systématiquement les cas limites : zéro, valeurs vides, montants négatifs, dates de changement d'année, chaînes très longues.
- Enregistrez quelques scénarios d'interface sur les parcours les plus critiques (saisie d'une commande de bout en bout) pour détecter les régressions.
- À chaque bug corrigé, écrivez un test qui le reproduit : vous garantissez qu'il ne reviendra jamais. Et gardez vos tests à jour.
Script pas-à-pas — tester comme Yacine (5 min)
1) Identifiez le cœur métier de votre application (calculs, règles critiques). 2) Écrivez un test unitaire par règle (TVA, remises, échéances) qui vérifie un résultat connu. 3) Ajoutez les cas limites : zéro, valeurs vides, montant négatif, changement d'année. 4) Enregistrez un scénario d'interface sur le parcours de saisie de commande. 5) À chaque bug corrigé, ajoutez un test qui le reproduit. 6) Passez la batterie de tests après chaque modification et tenez-la à jour.
Soyez ciblé : le cœur métier et les cas limites rapportent le plus ; gardez les tests à jour, sinon ils donnent un faux sentiment de sécurité.
Modèle copier-coller — ma fiche tests
Unitaires : une procedure/classe -> bon resultat (coeur metier)
Interface : rejouer un scenario enregistre (ouvrir, saisir, valider)
Regressions: LE risque en maintenance -> detectees en minutes
Cas limites: zero, vide, negatif, changement d'annee
Regle d'or : un test a CHAQUE bug corrige
Tenue : tests obsoletes ignores = pires que pas de tests
Au-dela : revue de code, documentation, conventions, retours usersTest unitaire de TVA
Yacine vérifie que CalculeTTC(1000, 19) renvoie bien 1190.
Cas limite
Yacine teste une remise à 0 %, un montant négatif et un changement d'année.
Scénario d'interface
Yacine enregistre la saisie complète d'une commande pour la rejouer.
Test après correction
Yacine écrit un test reproduisant le bug de remise pour qu'il ne revienne jamais.
✓ Bonnes pratiques
- Commencer par le cœur métier, pas par une couverture totale.
- Tester les cas limites et écrire un test à chaque bug corrigé.
- Garder les tests à jour et compléter par la revue de code.
✗ Pièges fréquents
- Viser 100 % de couverture sur une petite application.
- Laisser des tests obsolètes que tout le monde ignore.
- Croire que tester l'affichage vérifie les calculs.
Points clés à retenir
- Trois niveaux : tests unitaires (rentables), scénarios d'interface, audit du projet.
- Le but des tests automatiques est de détecter les régressions, pas seulement les bugs du jour.
- Bonnes pratiques : cœur métier, cas limites, un test par bug corrigé.
- ⚠️ Tenir les tests à jour ; la qualité inclut revue de code, documentation et retours utilisateurs.
Défi 48h — appliquez demain
Comme Yacine, choisissez une règle métier de votre application (un calcul de TVA, de remise ou d'échéance) et écrivez au moins trois tests unitaires : un cas « normal » et deux cas limites (zéro, valeur négative, changement d'année). Enregistrez ensuite un scénario d'interface sur un parcours critique. Prenez le dernier bug corrigé et écrivez le test qui le reproduit. Lancez la batterie et notez le temps gagné : ces quelques minutes remplacent une relecture manuelle impossible.
- J'écris des tests unitaires ciblés sur le cœur métier.
- Je teste les cas limites et j'enregistre des scénarios d'interface.
- J'ajoute un test à chaque bug corrigé et je tiens mes tests à jour.
Questions fréquentes
Les tests automatiques valent-ils l'investissement sur un petit projet ?
Oui, mais de façon ciblée : n'essayez pas de tout tester, concentrez-vous sur le cœur métier (calculs et règles critiques) et sur les bugs déjà rencontrés. Quelques tests bien choisis rapportent beaucoup ; une couverture exhaustive coûterait plus qu'elle ne rapporte sur un petit projet. Une application de gestion vit longtemps et évolue : le vrai coût n'est pas d'écrire le test, c'est de ne pas l'avoir quand une modification casse silencieusement un calcul et qu'un client s'en aperçoit trois mois plus tard. Les tests donnent aussi la confiance de modifier et servent de documentation.
Comment savoir si mon application est de bonne qualité ?
En regardant plusieurs dimensions objectives : elle fait ce qu'elle doit (justesse), elle résiste aux imprévus (robustesse), elle est utilisable efficacement (ergonomie), elle reste rapide sur des volumes réels (performance) et elle peut évoluer sans douleur (maintenabilité) — le tout validé par les utilisateurs réels. La justesse est la plus importante : en gestion, un total faux ou un stock incohérent sont des défauts graves, d'autant plus dangereux qu'ils ne provoquent aucune erreur visible. Complétez par la sécurité et la déployabilité, et écoutez les signaux d'alerte (peur de modifier, bugs récurrents, régressions).
Quel est le principal intérêt des tests automatiques ?