Coder's IO

Dans les tests unitaires, il existe plusieurs façons de vérifier que le comportement des exceptions répond bien aux attentes.

Pour information j'utilise fest-assert pour la gestion des assertions ; même si l'information n'est pas capitale, cela permet de savoir de quoi on parle 😉

Voici un premier exemple qui présente la manière basique d'effectuer cette vérification : 

   @Test
    public void first_way_to_exception() throws Exception {

        //case 1
        try {
            ms.computeSomething(1, 1);
            fail("should throw an exception!");
        } catch (Exception e) {

        }

       //case 2
        try {
            ms.computeSomething(1, 2);
        } catch (Exception e) {
            fail("no exception should be threw");
        }

    }

Dans le cas 1, on va vérifier que le fil d’exécution du test unitaire passe bien dans le block catch, ce qui voudrait dire qu’une exception a bien été levée et correspond au comportement attendu.
Si l’invocation de la méthode du service ne lançait pas d’exception alors le test échouerait avec la méthode fail(..) 

Cette solution très pragmatique et qui fonctionne bien, implique la mise en place de pas mal de lignes de code qui présente peu d’intérêt pour le test unitaire en lui-même.

Avec l’évolution du JDK et de JUnit, il est possible d'avoir recours aux annotations. En effet, l'ajout du paramètre expected dans l'annotation @Test permet d'exprimer de manière plus synthétique le fait que le lancement d'une exception est attendu par le test. Voici un exemple d'implémentation : 

  @Test(expected=OneException.class)
   public void second_way_to_exception() throws Exception {
        ms.computeSomething(1, 1);
   }

Cette solution est plus concise, néanmoins elle ne permet pas de manipuler l'exception levée pour, par exemple, analyser le message contenu dans l'exception à l'instar de la première solution.

La troisième solution repose sur une librairie nommée catch-exception.
Cette librairie permet d'obtenir, en quelque sorte, un mix des deux solutions précédentes.
c'est-à-dire que le code écrit restera (très) concis et que cela permettra de faire une analyse fine de l'exception que l'on souhaite traiter. 
Voici un exemple : 

 @Test
 public void third_way_to_exception() throws Exception {
        catchException(ms).computeSomething(1, 1);

         assertThat(caughtException())
             .isInstanceOf(OneException.class)
             .hasMessage(EVERYONE_ARE_EQUALS_TO_1);
 }
    
Cette librairie fournit une manipulation à la Mockito (très expressive). Il est d'ailleurs très facile de comprendre l'exemple.
La première ligne du test va encapsuler l'instance de l'objet que l'on souhaite surveiller. Ensuite, on enregistre la méthode que l'on souhaite contrôler.

Après, on écrit l'assertion. Dans ce cadre, on a accès à un ensemble d'informations (comme son type, le contenu du message, etc..)

Des trois solutions, c'est naturellement la dernière que je retiendrai.

Vous trouverez plus de détails dans le lien attaché à ce post.

    #java #test_unitaire #exception