Skip to content

Guide de survie : les tests fonctionnels

De la méthode à la classe

Passer du code à la vérification demande un changement de mentalité. On ne cherche plus à construire quelque chose qui marche, mais à prouver que cela fonctionne dans toutes les situations (même les pires).

Ce guide divise la procédure en deux niveaux : le niveau Micro (la méthode) et le niveau Macro (la classe).

Partie 1 : Tester une Méthode (Niveau Micro)

Approche "Boîte Noire"

Imaginez que la méthode est une boîte noire. Vous ne regardez pas le code à l'intérieur. Vous vous concentrez uniquement sur ce qui rentre (Entrées) et ce qui sort (Sorties).

Étape 1 : Analyser le Contrat

Le Contrat est déterminé par deux éléments :

  1. Le summary : la description de la méthode, de ses paramètres et de sa valeur de retour prend toute sa signification. Elle détermine l'objectif de la méthode.
  2. La signature de la méthode : la signature nous donne des détails techniques comme le type des variables et le niveau d'accès (public, private, etc.).

Avant d'écrire le test, posez-vous deux questions :

  1. Quels sont les paramètres acceptés ? (Ex. : un entier, une chaîne, un objet)
  2. Quel est le résultat attendu ? (Une valeur de retour ou une exception ?)

Étape 2 : Le "Chemin Heureux" (Happy Path)

C'est le scénario idéal où l'utilisateur fait exactement ce qu'il faut.

  • Objectif : Valider que la logique de base fonctionne.
  • Exemple : Pour une addition (2, 2), je m'attends à recevoir 4.

Étape 3 : Les Cas Limites (Boundaries)

C'est ici que se cachent 80% des bugs. Testez les frontières des types de données :

  • Nombres : testez 0, 1, -1, la valeur maximale (MaxInt) et la valeur minimale.
  • Listes/Tableaux : Une liste vide, une liste avec 1 seul élément, le premier et le dernier élément.
  • Chaînes de caractères : Une chaîne vide "", une chaîne avec seulement des espaces " ", ou null.

Règle d'or : Si votre méthode accepte un nombre, testez toujours 0 et un nombre négatif.

Étape 4 : Les Cas d'Erreur (Exceptions)

Si la méthode a des règles (ex. : « l'âge ne peut pas être négatif »), vous devez tester son comportement avec de mauvaises données.

  • Action : Appeler la méthode avec une valeur invalide.
  • Attente : la méthode doit lancer une exception (mécanisme vu en Programmation 2, par ex. ArgumentException). Elle ne doit pas « ne rien faire » ou planter silencieusement.

Ce que l'on peut faire pour corriger le problème :

  • Retour hâtif : tester la valeur au début de la méthode et utiliser return pour l'arrêter.
  • Retour significatif : prévoir une valeur de retour qui indique que la méthode est erronée (ex. : -1 pour un index de tableau).

Partie 2 : Tester une Classe (Niveau Macro)

Gestion de l'État

Une classe possède une "mémoire", un "état" (ses attributs). Le résultat d'une méthode dépend souvent de ce qui s'est passé avant.

Étape 1 : L'Initialisation

  • Créez une instance de la classe (via le constructeur).
  • Vérifiez que les attributs ont bien leurs valeurs par défaut en utilisant le débogueur.

Étape 2 : Accesseurs et Mutateurs (Get/Set)

Normalement, les attributs d'une classe ne sont pas publics. Nous ajoutons une méthode « get » (accesseur) pour consulter et obtenir la valeur d'un attribut et « set » (mutateur) pour modifier un attribut. Ces méthodes servent à la modification et à la lecture directe. Les autres méthodes peuvent apporter des changements différents (classement d'un tableau de noms par ordre alphabétique, affichage à l'écran, etc.).

  • Si vous faites un setValeur(10), le getValeur() doit retourner 10.
  • Vérifiez que le set respecte les règles de validation (puis-je mettre la quantité d'essence d'une voiture à -10 litres ?).

Étape 3 : Scénarios de Vie (Séquences)

Testez l'histoire de l'objet. L'ordre des appels est important.

  1. État initial : créer l'objet.
  2. Action : appeler une méthode qui modifie l'état (ex. : ajouterArticle).
  3. Vérification : vérifier l'état intermédiaire (ex. : l'article est maintenant dans la liste des articles du panier).
  4. Action suivante : appeler une autre méthode (ex. : viderPanier).
  5. Vérification finale : L'objet est-il revenu à zéro ?

La Structure d'un Test : Le modèle "AAA"

Pour garder vos tests lisibles, utilisez toujours cette structure en trois parties :

  1. ARRANGE (Préparer) :

    • Créer les objets et initialiser les variables.
    • C'est la mise en place du décor.

  2. ACT (Agir) :

    • Appeler LA méthode que vous voulez tester.
    • C'est l'action précise.

  3. ASSERT (Affirmer/Vérifier) :

    • Comparer le résultat obtenu avec le résultat attendu.
    • C'est le verdict.

Exemple de test


public bool Depot_MontantPositif_AugmenteSolde()
{
    bool ok = false;

    // 1. ARRANGE
    Compte monCompte = new Compte();
    monCompte.solde = 100;

    // 2. ACT
    monCompte.Deposer(50);

    // 3. ASSERT
    if(monCompte.Solde == 150)
    {
        ok = true;
    };

    return ok;
}