La gestion des exceptions et les doublures de test

Ce document présente les notions essentielles sur la gestion des exceptions et les doublures de test, destinées aux étudiants et développeurs souhaitant approfondir leurs compétences en tests unitaires, notamment en Java avec JUnit et Mockito. Il couvre les différentes méthodes pour gérer les exceptions dans les tests, les types de doublures de test, ainsi que les bonnes pratiques pour écrire des tests efficaces.

La gestion des exceptions

La gestion des exceptions dans les tests unitaires est une étape cruciale pour s'assurer que le code réagit correctement aux erreurs. En Java, plusieurs méthodes existent pour tester les exceptions levées par une méthode.

Gestion des exceptions avec annotations

• La méthode la plus simple consiste à utiliser l'annotation @Test de JUnit en spécifiant la classe d'exception attendue :

@Test(expected = Exception.class)

Cette méthode repose sur les assertions et permet de vérifier que l'exception spécifiée est levée lors du test. Cependant, elle présente une limitation : le test passe si n'importe quelle instruction lève l'exception, sans garantir que c'est bien l'instruction attendue.

Gestion des exceptions avec try-catch

Une autre approche consiste à utiliser un bloc try...catch dans le test. On appelle la méthode censée lever l'exception dans le bloc try. Si aucune exception n'est levée, on appelle la méthode fail() pour indiquer que le test a échoué. Dans le bloc catch, on peut alors vérifier le message de l'exception à l'aide d'assertions comme assertThat (disponible depuis JUnit 4.4).

Gestion des exceptions avec les règles JUnit

JUnit propose également une méthode basée sur les règles (Rules) qui permet de spécifier plus finement l'exception attendue et son message. Cette méthode utilise des objets Matchers issus de la librairie Hamcrest, intégrée dans JUnit 4.4 et supérieur. Elle offre plus de contrôle que l'annotation @Test(expected=...).

Les doublures de test

Une doublure de test est un objet qui remplace un objet réel pour faciliter le test d'une unité de code. Elle permet de reproduire l'état ou le comportement d'un objet dont dépend la partie testée.

Exemple : pour tester une voiture, on peut utiliser une doublure de moteur simulant l'avance ou le recul.

Les doublures peuvent être créées manuellement ou générées automatiquement avec des outils comme Mockito ou EasyMock.

Types de doublures de test

• Dummy : objet utilisé uniquement pour remplir des paramètres, sans être réellement utilisé. Par exemple, un objet vide passé en argument.
• Stub : objet qui fournit une réponse prédéfinie à un appel de méthode, utilisé dans les tests en boîte blanche. Il tient compte du contexte du test.
• Mock : objet préprogrammé avec des attentes précises sur les appels qu'il doit recevoir. Il vérifie que ces appels ont bien eu lieu.
• Spy : un stub qui en plus vérifie le comportement, par exemple combien de fois une méthode a été appelée.
• Fake : objet avec une implémentation fonctionnelle simplifiée par rapport à la version finale, souvent utilisé pour simuler un service externe ou une base de données.

Exemple de Dummy

Un dummy peut être une instance d'une interface métier passée en paramètre mais qui ne sera jamais utilisée dans le test. Par exemple :

interface Service {
  void execute();
}

class DummyService implements Service {
  public void execute() {
    // Ne fait rien
  }
}

Exemple de Stub

Un stub fournit une réponse fixe. Par exemple, une méthode d'authentification qui renvoie toujours true :

class AuthStub {
  public boolean authenticate(String user, String pass) {
    return true; // réponse prédéfinie
  }
}

Exemple de Spy

Un spy permet de vérifier le comportement, par exemple le nombre d'appels :

class AuthSpy extends AuthStub {
  private int callCount = 0;

  @Override
  public boolean authenticate(String user, String pass) {
    callCount++;
    return super.authenticate(user, pass);
  }

  public int getCallCount() {
    return callCount;
  }
}

Exemple de Mock

Un mock est un spy avec des attentes précises sur les appels. Par exemple, on peut vérifier que la méthode authorize a été appelée :

Mock<Auth> mockAuth = mock(Auth.class);
when(mockAuth.authorize(anyString())).thenReturn(true);

// exécution du test

verify(mockAuth).authorize("user");

Exemple de Fake

Un fake est une implémentation simplifiée mais fonctionnelle, par exemple une base de données en mémoire :

class FakeDatabase {
  private Map<String, String> data = new HashMap<>();

  public void save(String key, String value) {
    data.put(key, value);
  }

  public String find(String key) {
    return data.get(key);
  }
}

Les doublures de test avec Mockito

Mockito est un framework populaire pour créer des doublures en Java. Il permet de créer des mocks, stubs et spies facilement.

Création de mocks

Deux façons principales :

• Par injection
• Par appel d'une méthode statique mock()

Spécification des comportements

Avec Mockito, on utilise le mot-clé when pour définir les comportements :

• when(...).thenReturn(...) : pour retourner une valeur
• when(...).thenThrow(...) : pour lever une exception
• On peut enchaîner plusieurs comportements successifs

Utilisation des spies

Mockito permet aussi de créer des spies, qui sont des objets réels surveillés.

Matchers

Pour vérifier les arguments passés aux méthodes, Mockito utilise la méthode equals() par défaut, mais on peut utiliser des matchers pour ignorer la valeur exacte :

• anyInt(), anyString(), any(), etc.

Attention : si un matcher est utilisé dans une expression, tous les arguments doivent être des matchers.

Vérification avec verify

La méthode verify permet de vérifier que certaines méthodes ont été appelées, avec les bons arguments. Si la vérification échoue, une exception est levée et le test échoue.

Méthodes doXXX pour les méthodes void

• doThrow : pour simuler une exception
• doNothing : pour ne rien faire
• doReturn : pour retourner une valeur
• doAnswer : pour fournir une réponse dynamique en fonction des paramètres

Que faut-il tester ?

Plusieurs critères permettent de définir ce qu'il faut tester, regroupés sous les acronymes Right-BICEP et CORRECT.

Right-BICEP

• Right : vérifier que les résultats sont corrects.
• B (Boundary) : tester les conditions limites, données mal formatées, nulles, etc.
• I (Inverse) : vérifier la relation inverse, par exemple tester la racine carrée avec la mise au carré.
• C (Cross-Check) : vérifier le résultat par une autre méthode.
• E (Error condition) : forcer l'apparition d'erreurs.
• P (Performance) : vérifier que les performances sont correctes.

CORRECT

• C (Conformance) : la valeur est-elle dans le format attendu ?
• O (Ordering) : les valeurs sont-elles dans le bon ordre ?
• R (Range) : la valeur est-elle dans l'intervalle attendu ?
• R (Reference) : le code utilise-t-il un service externe hors contrôle du test ?
• E (Existence) : la valeur existe-t-elle ?
• C (Cardinality) : y a-t-il assez de valeurs ?
• T (Time) : les opérations se déroulent-elles dans le bon ordre et dans le délai prévu ?

Le patron de test AAA (Arrange, Act and Assert)

Le patron AAA est une méthode standard pour écrire des tests unitaires clairs et structurés :

• Arrange : préparation des variables et création des objets à tester.
• Act : appel de la méthode à tester.
• Assert : vérification des résultats avec des assertions.

Glossaire des termes clés

• Annotation @Test(expected=...) : annotation JUnit pour indiquer qu'une exception est attendue dans un test.
• Dummy : objet doublure utilisé uniquement pour remplir des paramètres, sans comportement.
• Stub : doublure qui fournit une réponse prédéfinie à un appel de méthode.
• Mock : doublure programmée avec des attentes précises sur les appels reçus.
• Spy : doublure qui surveille les appels et vérifie le comportement.
• Fake : doublure avec une implémentation fonctionnelle simplifiée.
• Matcher : objet utilisé pour vérifier les arguments dans les tests, notamment avec Mockito.
• Mockito : framework Java pour créer des doublures de test (mocks, stubs, spies).
• Try...catch : structure de gestion des exceptions permettant de tester précisément l'instruction qui doit lever une exception.
• Hamcrest : librairie fournissant des matchers pour les assertions dans JUnit.
• fail() : méthode JUnit indiquant qu'un test a échoué si une exception attendue n'a pas été levée.
• AAA (Arrange, Act, Assert) : patron pour structurer un test unitaire.

Points clés à retenir

• Tester les exceptions est essentiel pour garantir la robustesse du code ; plusieurs méthodes existent (annotations, try-catch, règles).
• Les doublures de test (dummy, stub, mock, spy, fake) permettent d'isoler l'unité testée en simulant ses dépendances.
• Mockito est un outil puissant pour créer et gérer ces doublures en Java.
• Les tests doivent couvrir les cas normaux, les limites, les erreurs, et vérifier la conformité, l'ordre, la performance, etc.
• Le patron AAA facilite la rédaction de tests clairs et structurés.