Les tests à l'examen : E7 et E6 SLAM, exercices corrigés

1.

test1 et test2 encadrent la valeur limite : 4 échecs, pas de verrouillage ; 5 échecs, verrouillage.

2. La règle « un succès ne déverrouille pas un compte verrouillé » n'est pas testée. C'est pourtant la plus importante pour la sécurité : sans elle, un attaquant qui finirait par trouver le mot de passe débloquerait le compte.

    @Test
    void test4() {
        for (int i = 0; i < 5; i++) {
            compte.enregistrerEchec();
        }
        compte.enregistrerSucces();
        assertTrue(compte.estVerrouille());
        assertEquals(5, compte.getNbEchecs());
    }

Le test vérifie que le compte reste verrouillé et que le compteur n'a pas été remis à zéro. Les boucles for sont courantes dans les sujets pour répéter une action ; dans un projet, on préférerait une petite méthode utilitaire echouer(n) pour garder le test lisible.

import static org.junit.jupiter.api.Assertions.*;

import org.junit.jupiter.api.Test;

class PolitiqueMotDePasseTest {

    @Test
    void accepteDouzeCaracteresAvecChiffreEtMajuscule() {
        assertTrue(PolitiqueMotDePasse.estRobuste("Sorbier2027a"));
    }

    @Test
    void refuseOnzeCaracteres() {
        assertFalse(PolitiqueMotDePasse.estRobuste("Sorbier2027"));
    }

    @Test
    void refuseSansChiffre() {
        assertFalse(PolitiqueMotDePasse.estRobuste("SorbierLogistique"));
    }

    @Test
    void refuseSansMajuscule() {
        assertFalse(PolitiqueMotDePasse.estRobuste("sorbier2027abc"));
    }

    @Test
    void refuseNull() {
        assertFalse(PolitiqueMotDePasse.estRobuste(null));
    }
}

• Le premier test est le cas nominal à la limite : exactement 12 caractères, avec un chiffre et une majuscule. Il prouve que 12 suffit.
• Le deuxième est la limite de l'autre côté : 11 caractères, tout le reste valide. Il prouve que la longueur est vérifiée, et au bon seuil.
• Les troisième et quatrième testent chaque condition seule : chaque mot de passe est assez long et ne manque que d'une chose. Un mot de passe trop court et sans chiffre ne dirait pas laquelle des deux règles a provoqué le refus.
• Le dernier vérifie le cas null, prévu par la spécification.

401 signifie « non authentifié » : l'API n'a pas reconnu l'appelant. 403 signifie « authentifié mais pas autorisé ». Le salarié devrait être reconnu, puis refusé : l'attendu 403 est le bon, d'après les conventions HTTP.

Pour trancher, on regarde pourquoi l'authentification échoue :

• si le test fabrique mal le jeton (secret de test absent, en-tête mal écrit comme Bearer oublié), c'est le test qui est faux : « Le jeton de test n'était pas valide ; je le corrige, le test passe à 403, ce qui prouve que la route refuse bien les salariés » ;
• si le jeton est valide mais que la route vérifie le rôle avant l'authentification, ou renvoie 401 pour un mauvais rôle, c'est le code : « La route renvoie 401 au lieu de 403 pour un rôle insuffisant ; je corrige le code de statut dans le middleware, et je relance toute la suite pour vérifier la non-régression ».

Dans les deux cas, on ne modifie pas l'attendu pour « faire passer » le test : on cherche qui a raison à partir de la règle (ici, la sémantique des codes HTTP), puis on corrige ce qui est faux.

1. Un test unitaire vérifie une unité de code (une méthode, une classe) isolée de ses dépendances, en quelques millisecondes ; un test d'intégration vérifie que plusieurs composants fonctionnent ensemble (une route, ses middlewares et la base, par exemple).
2. C'est le fait de rejouer, après chaque modification, les tests qui passaient avant, pour vérifier que la modification n'a rien cassé. Après chaque bug corrigé, on ajoute le test qui l'aurait détecté.
3. Une doublure de test qui remplace une dépendance et vérifie que le code testé l'appelle comme prévu (par exemple, qu'un courriel est envoyé à la bonne adresse), sans effet réel.
4. La couverture mesure les lignes exécutées par les tests, pas les résultats vérifiés : un test sans assertion ou sans valeur limite couvre le code sans détecter ses erreurs, et une règle absente du code n'apparaît dans aucune mesure.
5. Il liste les cas de test qui vérifient chaque exigence (préconditions, étapes, résultat attendu) ; la MOA le déroule pendant la recette pour décider si elle accepte la livraison.

Les tests 1 et 2 fixent la règle ; 4 est le test de droits, indispensable ; 6 vérifie l'exigence la plus facile à oublier, la conservation des réservations existantes. Si le temps manque, on garde 1, 4, 5 et 7, et on annonce les autres comme « à écrire » dans le rapport.