Tutoriel sur dix raisons pour échouer ses tests unitaires en toutes circonstances

Voici l'histoire de la recette du poulet au whisky, à la sauce XML… Laquelle de ces 2 versions allez-vous préférer ?

public class RecetteTest {
 
    @Test
    public void testToXml() {
        Recette r = new Recette('poulet au whisky');
        assertNotNull(r);
        String s = r.toXml();
        assertNotNull(s);
        String[] splits = s.split('\n');
        assertTrue(splits.length == 8);
        for (String split : splits) {
            if (split == null || ''.equals(split)) {
                fail('error');
            }
        }
        assertEquals('<!--?xml version=\'1.0\' encoding=\'UTF-8\'?-->').trim(), splits[0].trim());
        assertEquals(''.trim(), splits[1].trim());
        assertEquals('\t'.trim(), splits[2].trim());
        assertEquals('\t\tpoulet'.trim(), splits[3].trim());
        assertEquals('\t\tolives'.trim(), splits[4].trim());
        assertEquals('\t\twhisky'.trim(), splits[5].trim());
        assertEquals('\t'.trim(), splits[6].trim());
        assertEquals(''.trim(), splits[7].trim());
    }
}

public class RecetteTest {
 
    @Test
    public void testToXml() {
        // execute XML marshalling
        Recette recette = new Recette('poulet au whisky');
        String actualXml = recette.toXml();
 
        // read exepected result
        String expectedXml = readFileFromClasspath('expected_poulet-au-whisky.xml');
 
        // check result
        assertEquals(formatXml(expectedXml), formatXml(actualXml));
    }
 
    /**
    * read into a String a text file from classpath
    *
    * @param filePath
    * @return the String content
    */
    protected static String readFileFromClasspath(String filePath) {
        // ...
    }
 
    /**
    * @param unformatedXml
    * @return a formated and indented XML
    */
    protected static String formatXml(String unformatedXml) {
        // ...
    }
}

Écrire des méthodes trop longues, exploser la complexité cyclomatique, appliquer des non-conventions de nommage, éviter soigneusement les commentaires dans le code, écrire en « ASCII art », pratiquer la duplication de code… Toutes ces pratiques malheureusement trop répandues sont autant de raisons de ne pas avoir envie de maintenir un code ou un test legacy… Un test qui ne marche plus et que personne ne veut réparer est à l'agonie. Ce n'est qu'une question de temps avant que plus personne ne puisse le remettre en état. Soyez donc « fourmi » plutôt que «cigale » quand vous écrivez vos tests ! Pensez à leur avenir, à la personne qui devrait les relire, les comprendre, les mettre à jour, les corriger. Toutes les bonnes pratiques de qualité de code valables sur votre application le sont également sur les tests.

• Pensez à la lisibilité et à la clarté de votre test. Évitez toute ambiguïté ! Un test est une histoire qu'on doit pouvoir rapidement comprendre.
• Le plus simple est toujours le mieux, Keep It Simple and Stupid ! Évitez d'alourdir le code du test avec des assertions inutiles, ou des bouts de code morts.

Un bon test doit être au maximum isolé du monde extérieur, ne pas dépendre de paramètres que l'on ne maîtrise pas dans son test. Écrire un test dont le comportement dépend de la date à laquelle il s'exécute peut avoir de fâcheuses conséquences ; ça n'ira pas jusqu'à une rupture du continuum espace-temps provoquant la destruction totale de l'univers, mais cela mettra bel et bien vos tests en porte à faux ! Pour illustrer cette idée, dans l'exemple suivant, que se passera-t-il si l’on exécute le test le 22 octobre 2015 ?

public class Dolorean {
 
    public String startTemporalConvector(Date destinationDate) {
        if (destinationDate.after(new Date())) {
            return 'future';
        } else {
            return 'past';
        }
    }
}
 
public class DoloreanTest {
 
    @Test
    public void testTravelInPast() throws ParseException {
        Date psteDate = new SimpleDateFormat('dd/mm/yyyy').parse('12/11/1955');
        String destination = new Dolorean().startTemporalConvector(psteDate);
        assertEquals('past', destination);
    }
 
    @Test
    public void testTravelInFuture() throws ParseException {
        Date futureDate = new SimpleDateFormat('dd/mm/yyyy').parse('21/10/2015');
        String destination = new Dolorean().startTemporalConvector(futureDate);
        assertEquals('future', destination);
    }
}

… le test testTravelInFuture() qui était vert jusqu'à présent passera rouge ! Pour rendre ce test insensible au temps qui passe, il faut casser cette dépendance à la date système. Il existe plusieurs façons de faire, mais le principe reste le même.

II-A. Solution 1 (à la main)▲

public class Dolorean {
 
    public String startTemporalConvector(Date destinationDate) {
        // pivot date is now configurable !
        if (destinationDate.after(DateFactory.getNow())) {
            return 'future';
        } else {
            return 'past';
        }
    }
}
 
public interface DateProvider {
    Date create();
}
 
public class DateFactory {
 
    public static DateProvider impl = new DateProvider() {
        @Override
        public Date create() {
            return new Date();
        }
    };
 
    public static Date getNow() {
        return impl.create();
    }
}
 
public class DoloreanTest {
 
    @BeforeClass
    public static void setupNow() {
        // set now = 1/1/2000
        DateFactory.impl = new DateProvider() {
            @Override
            public Date create() {
                try {
                    return new SimpleDateFormat('dd/mm/yyyy').parse('1/1/2000');
                } catch (ParseException e) {
                    return null;
                }
            }
        };
    }
 
    @Test
    public void testTravelInPast() throws ParseException {
        Date psteDate = new SimpleDateFormat('dd/mm/yyyy').parse('12/11/1955');
        String destination = new Dolorean().startTemporalConvector(psteDate);
        assertEquals('past', destination);
    }
 
    @Test
    public void testTravelInFuture() throws ParseException {
        Date futureDate = new SimpleDateFormat('dd/mm/yyyy').parse('21/10/2015');
        String destination = new Dolorean().startTemporalConvector(futureDate);
        assertEquals('future', destination);
    }
 
}

II-B. Solution 2 (avec un framework de mock)▲

public class Dolorean {
 
    public String startTemporalConvector(Date destinationDate) {
        // pivot date is now configurable !
        if (destinationDate.after(now())) {
            return 'future';
        } else {
            return 'past';
        }
    }
 
    Date now() {
        return new Date();
    }
 
}
 
@RunWith(MockitoJUnitRunner.class)
public class DoloreanTest {
 
    private static Dolorean dolorean;
 
    @BeforeClass
    public static void setupNow() throws ParseException {
        // setup mocked now() method on a dolorean
        dolorean = Mockito.mock(Dolorean.class);
        Date firstJanuary2000 = new SimpleDateFormat('dd/mm/yyyy').parse('1/1/2000');
        Mockito.when(dolorean.now()).thenReturn(firstJanuary2000);
        // do not mock startTemporalConvector()
        Mockito.when(dolorean.startTemporalConvector(Mockito.any(Date.class))).thenCallRealMethod();
    }
 
    @Test
    public void testTravelInPast() throws ParseException {
        Date psteDate = new SimpleDateFormat('dd/mm/yyyy').parse('12/11/1955');
        String destination = dolorean.startTemporalConvector(psteDate);
        assertEquals('past', destination);
    }
 
    @Test
    public void testTravelInFuture() throws ParseException {
        Date futureDate = new SimpleDateFormat('dd/mm/yyyy').parse('21/10/2015');
        String destination = dolorean.startTemporalConvector(futureDate);
        assertEquals('future', destination);
    }
 
}

II-C. La cerise sur le gâteau▲

Quand on est concentré sur l'écriture du code d'une fonctionnalité, on a parfois tendance à négliger l'implémentation de son test et à s'autoriser quelques libertés sur du code qui n'est « que » du code de test… Certains raccourcis pourraient pourtant bien s'avérer fatals pour vos tests, dans un futur plus ou moins proche ! On aura, par exemple, tendance à oublier la sémantique des types que l'on manipule. Prenons le cas de test suivant :

public class Recette {
 
    private String nom;
 
    public Recette(String nom) {
        super();
        this.nom = nom;
    }
 
    public Set loadIngredients() {
        ...
    }
 
}
 
public class RecetteTest {
 
    @Test
    public void testLoadIngredients() {
        Recette recette = new Recette('poulet au whisky');
        Set ingredients = recette.loadIngredients();
 
        ArrayList ingredientsList = new ArrayList(ingredients);
        assertEquals('olives', ingredientsList.get(0));
        assertEquals('whisky', ingredientsList.get(1));
        assertEquals('poulet', ingredientsList.get(2));
    }
 
}

Le test fonctionne, tout est vert… Jusqu'au jour où arrive un projet de migration de l'application : il est temps d'abandonner Java 5 au profit de Java 7 ! Seulement voilà, avec la version 7 du JRE, les tests échouent avec l'erreur.

org.junit.ComparisonFailure: expected:<[olives]> but was:<[whisky]>
    at org.junit.Assert.assertEquals(Assert.java:123)
    at jre.RecetteTest.testLoadIngredients(RecetteTest.java:23)

Que s'est-il passé ? L'implémentation des assertions est depuis le début fausse ! En effet, les ingrédients chargés par loadIngredients() sont retournés dans un java.util.Set, un type représentant un ensemble au sens mathématique, dans lequel il n'existe pas de doublon, et surtout, pas d'ordre sur les éléments ! (C'est ici notre erreur puisque notre test se base sur un supposé ordre pour vérifier le contenu du java.util.Set). Ainsi, le java.util.Set ne garantissant aucun ordre, les nouvelles implémentations Java 7 pour java.util.Set (telles que java.util.HashSet) ne retournent plus les éléments dans le même ordre que la version 5, ce qui reste sémantiquement correct, mais a pour effet indésirable l'échec cuisant de notre test… Une implémentation correcte serait tout simplement :

public class RecetteTest {
 
    @Test
    public void testLoadIngredients() {
        Recette recette = new Recette('poulet au whisky');
        Set ingredients = recette.loadIngredients();
 
        Set expectedIngredients = new HashSet() {{
            add('olives');
            add('whisky');
            add('poulet');
        }};
        assertEquals(expectedIngredients, ingredients);
    }
}

Parfois, il nous faut accéder au disque de la machine dans un test unitaire.

Soit dans l'implémentation même du test, pour en améliorer la lisibilité (en listant par exemple depuis un fichier plat, un jeu de données d'entrée ; ou de la même façon, un résultat de méthode qui sert de référence (XML, json, CSV…)).

public class ECommerceServiceTest {
 
    ECommerceService service = new ECommerceService();
 
    @Test
    public void testFacturation() throws Exception {
        // input dataset read from file system
        String order = readFile('ma_commande1.csv');
 
        // run code
        String actualBill = service.createBill(order);
 
        // expected output read from file system
        String expectedBill = readFile('ma_facture1.csv');
 
        assertEquals(expectedBill, actualBill);
    }
 
}

Soit parce que le code testé génère lui-même un fichier d'output sur disque (ex. : tester une classe qui produit un fichier de reporting sur disque).

public class ECommerceService {
 
    List orderList = ...
 
    public void createOrdersReport(String outputFile) {
        FileWriter w = new FileWriter(new File(outputFile));
        w.write(toCsv(orderList));
        w.close();
    }
 
}
 
public class ECommerceServiceTest {
 
    ECommerceService service = new ECommerceService();
 
    @Test
    public void testCreateOrdersReport() throws Exception {
        // invoke service dumping output on file system
        String outputReport = 'orders_report.csv';
 
        // run code
        service.createOrdersReport(outputReport);
 
        // check result from file system
        String actualReport = readFile(outputReport);
        String expectedReport = ...
        assertEquals(expectedReport, actualReport);
    }
}

Dans les deux cas, on sera amené à résoudre les problèmes habituels liés aux fichiers sur disque…

IV-A. Les problèmes classiques liés aux systèmes de fichiers▲

File outputFile1 = new File('./work/out.txt');
// pointe vers ./work/out.txt sous Unix, et .\work\out.txt sous Windows
 
File outputFile2 = new File('.\\work\\out.txt');
// sous Unix, pointe vers le ficher nommé 'work\out.txt' du répertoire courant !!

IV-B. Système de fichiers et bonnes pratiques dans les tests▲

File inputFile = new File('./src/test/resources/montest1.txt');

// pointe vers /tmp/out.txt sous Unix, et c:\temp\out.txt sous Windows (ou le temp\ de l'utilisateur)
File outputFile = new File(System.getProperty('java.io.tmpdir') + '/out.txt');

public class TestReportService {
 
    private static String tmpDir = System.getProperty('java.io.tmpdir');
    private static String reportPath = '/report/';
    private static File reportDir = new File(tmpDir + reportPath);
 
    private ReportService reportService = new ReportService();
 
    @BeforeClass
    public static void setupPaths() {
        // create output dir if not exists
        if (!reportDir.exists()) {
            reportDir.mkdirs();
        }
    }
 
    @Test
    public void testMyReport() {
        String reportName = 'my_report';
        File generatedCsv = new File(tmpDir + reportPath + 'my_report.csv');
        reportService.report(reportName, generatedCsv);
        File expectedCsv = readFile('src/test/resources/expected_my_report.csv');
        assertCsvEquals(expectedCsv, generatedCsv);
    }
 
    private void assertCsvEquals(File expectedCsv, File generatedCsv) {
        // ...
    }
 
    private File readFile(String string) {
        //...
    }
}

public class TestReportService {
 
    private static String tmpDir = System.getProperty('java.io.tmpdir');
    private static String reportPath = '/report/';
    private static File reportDir = new File(tmpDir + reportPath);
 
    private ReportService reportService = new ReportService();
 
    @BeforeClass
    public static void setupPaths() {
        // create output dir if not exists
        // ...
    }
 
    @Test
    public void testMyReport() {
        // ...
    }
 
    @AfterClass
    public static void cleanUpFiles() throws IOException {
        // remove all contained generated files and directory
        FileUtils.deleteQuietly(reportDir);
    }
}

public class TestReportService {
 
    private static String tmpDir = System.getProperty('java.io.tmpdir');
    private static String reportPath = '/report/';
    private static File reportDir = new File(tmpDir + reportPath);
 
    private ReportService reportService = new ReportService();
 
    @BeforeClass
    public static void setupPaths() throws IOException {
        // create output dir
        if (!reportDir.exists()) {
            reportDir.mkdirs();
        }
        // auto delete folder on exit
        reportDir.deleteOnExit();
    }
 
    @Test
    public void testMyReport() {
        String reportName = 'my_report';
        File generatedCsv = new File(tmpDir + reportPath + 'my_report.csv');
        generatedCsv.deleteOnExit(); // auto delete generated CSV on exit
 
        reportService.report(reportName, generatedCsv);
        File expectedCsv = readFile('src/test/resources/expected_my_report.csv');
 
        assertCsvEquals(expectedCsv, generatedCsv);
    }
}

public class ReportService {
 
    public void report(String reportName, File outputFile) {
        try {
            // ...
        } catch (Exception e) {
            e.printStackTrace();
        }
        return;
    }
}

public class TestReportService {
 
    private static String tmpDir = System.getProperty('java.io.tmpdir');
    private static String reportPath = '/report/';
    private static File reportDir = new File(tmpDir + reportPath);
 
    private ReportService reportService = new ReportService();
 
    @BeforeClass
    public static void setupPaths() throws IOException {
        // create output dir
        if (!reportDir.exists()) {
            reportDir.mkdirs();
        }
    }
 
    @Test
    public void testMyReport() {
        String reportName = 'my_report';
        File generatedCsv = new File(tmpDir + reportPath + 'my_report.csv');
 
        reportService.report(reportName, generatedCsv);
        // OOps !!! The report() invokation has thrown an exception and catched it silently before returning...
 
        // ... And the report file has not been dumped !!!
        File expectedCsv = readFile('src/test/resources/expected_my_report.csv');
 
        assertCsvEquals(expectedCsv, generatedCsv);
        // ... But the test is green because a previously generated my_report.Csv exists !
    }
}

public class TestReportService {
 
    private static String tmpDir = System.getProperty('java.io.tmpdir');
    private static String reportPath = '/report/';
    private static File reportDir = new File(tmpDir + reportPath);
 
    private ReportService reportService = new ReportService();
 
    @BeforeClass
    public static void setupPaths() throws IOException {
        // first, clean old generated files
        FileUtils.deleteQuietly(reportDir);
        // then recreate empty dir
        reportDir.mkdirs();
    }
 
    @AfterClass
    public static void cleanUpFiles() throws IOException {
        // clean up before leaving place
        FileUtils.forceDelete(reportDir);
    }
 
    @Test
    public void testMyReport() {
        //    ...
    }
 
}

Si vous êtes déjà familiarisés à l'écriture des tests unitaires, vous l'aurez compris : écrire une fonctionnalité et les tests associés sont 2 choses intimement liées :

• le test unitaire dépend évidement du code testé ;
• mais la fonctionnalité doit également être écrite de manière à pouvoir être testée par une classe de test ! Qui ne s'est jamais retrouvé obligé de refactoriser du code pour pouvoir « brancher » son test unitaire ?

Ce constat est probablement la raison d'exister des pratiques dites « Test First » ou « Test Driven Development » (écrire les tests avant/pendant la fonctionnalité). Même les détracteurs de ces pratiques s'accorderont à dire qu'il est assez exceptionnel d'écrire a posteriori un test sur un code legacy sans avoir besoin de refactoriser celui-ci un minimum… Alors que se passe-t-il si j'organise mon planning de travail comme suit : la première semaine, j'écris du code, la semaine suivante, j'écris les tests ?

• Je risque de commiter du code non testé (donc buggé), qui pourra être utilisé par mes camarades, et leur faire perdre un temps précieux à cause de bugs dont je suis l'auteur.
• Je vais devoir me remémorer le contexte de chaque fonctionnalité au moment où je me décide à écrire son test. Ce travail est un coût supplémentaire que j'ai pourtant déjà payé une première fois pour développer la fonctionnalité. Je risque, de plus, d'être moins pertinent dans mes cas de tests, en oubliant par exemple les cas aux limites, qui me sont sortis de l'esprit.
• Par ailleurs, le refactoring nécessaire pour écrire mon test sera beaucoup plus lourd, car mon code est probablement déjà utilisé un peu partout.

Un dernier cas de figure sujet à polémique, dans lequel tout le monde se reconnaîtra : le cas de la « deadline » intenable. La stratégie habituellement suivie est la suivante :

1. Je code la fonctionnalité ;
2. Je teste rapidement « à la main » ;
3. Je livre en UAT/Prod ;
4. Après le rush de la mise en production, je peux prendre le temps pour finalement écrire mes tests unitaires.

Les objectifs seront en apparence remplis, mais il ne faudra pas perdre de vue le coût du compromis.

• Comme dit précédemment, le coût d'écriture des tests a posteriori sera plus important, et la qualité de la couverture risque d'être moins bonne.
• Il va probablement falloir refactoriser du code déjà validé et parti en production, pour pouvoir écrire les tests. Cela impliquera de devoir valider à nouveau le code refactorisé, pour s'assurer de la non-régression.

Alors voilà, ça y est, après pas mal d'efforts, vous disposez dans votre projet d'un bon paquet de tests unitaires : 95% de vos classes « intelligentes» ont leur classe de test associée ; de quoi être serein face aux évolutions à venir ! Pas convaincu ?! Et pour cause, il s'agit ici d'un indicateur assez naïf de couverture de tests.

Pour être réellement « couvert », il vous faudra bien entendu enrichir chacune de vos classes de tests de cas de tests judicieux, afin de couvrir la plus grande partie des chemins d'exécution possibles…

Prenons un exemple : voici un programme de simulation d'attaque « zombie » ; il y a d'un côté les zombies (à l'humour assez mordant), et de l'autre, une population saine, que ça ne fait pas rire du tout : chaque personne contaminée passe à son tour dans la catégorie zombie. On considère qu'en un jour, un seul zombie peut contaminer 10 personnes saines.

public class ZombieWarSimulator {
 
   /**
   * @param initialPeople initial number of healthy people
   * @param initialZombies initial number of zombies
   * @param days defining the simulation duration
   * @return new number of zombies after the number of days
   */
   public static int getZombieNumberAfterDays(int initialPeople, int initialZombies, int days) {
      int currentPeople = initialPeople;
      int currentZombies = initialZombies;
 
      for (int day = 0; day < days; day++) {
         // each day a zombie contaminate 10 people
         int newZombies = Math.min(currentZombies * 10, currentPeople);
         currentZombies = currentZombies + newZombies;
         currentPeople = currentPeople - newZombies;
      }
 
      return currentZombies;
   }
}
 
public class ZombieWarSimulatorTest {
 
   @Test
   public void simulateZDay() {
      // 3 days after 1 initial zombie
      int newZombies = ZombieWarSimulator.getZombieNumberAfterDays(10000, 1, 3);
      assertThat(newZombies).isEqualTo(1331);
   }
 
}

Notre test est correct et valide le cas général : 3 jours après l'apparition du patient « 0 », on compte 1331 personnes infectées. Mais le code fonctionne-t-il dans les cas suivants :

• apparition simultanée de plusieurs patients « 0 » ;
• pas de patient « 0 » ;
• population entièrement contaminée ;
• cas du jour « Z » ;
• etc.

Pour avoir une bonne couverture de code, il nous faudra ajouter les cas aux limites à ce cas général.

public class ZombieWarSimulatorTest {
 
   @Test
   public void simulateZDay() {
      // 3 days after 1 initial  zombie
      int newZombies = ZombieWarSimulator.getZombieNumberAfterDays(10000, 1, 3);
      assertThat(newZombies).isEqualTo(1331);
   }
 
   @Test
   public void simulateZDay2Zombies() {
      // 3 days after 2 initial zombies
      int newZombies = ZombieWarSimulator.getZombieNumberAfterDays(10000, 2, 3);
      assertThat(newZombies).isEqualTo(2662);
   }
 
   @Test
   public void simulateNoZombie() {
      // no zombie
      int newZombies = ZombieWarSimulator.getZombieNumberAfterDays(10000, 0, 3);
      assertThat(newZombies).isEqualTo(0);
   }
 
   @Test
   public void simulate28DaysLater() {
      // 28 days after 1 initial zombie
      int newZombies = ZombieWarSimulator.getZombieNumberAfterDays(10000, 1, 28);
      assertThat(newZombies).isEqualTo(10001);
   }
 
   @Test
   public void simulateBeforeZDay() {
      // 1 zombie and no contamination days
      int newZombies = ZombieWarSimulator.getZombieNumberAfterDays(10000, 1, 0);
      assertThat(newZombies).isEqualTo(1);
   }
 
}

Voilà qui est beaucoup mieux ! Mieux, mais pas ultime. En effet, notre test en l'état manque d'élégance : nous avons beaucoup de duplication de code.

Heureusement, les frameworks de test fournissent aujourd'hui des solutions de tests paramétrables, telles que JUnitParams que j'utiliserai ici (ou encore le runner JUnit Parameterized, ou les Parameters de TestNG) :

@RunWith(JUnitParamsRunner.class)
public class ZombieWarSimulatorTest {
 
   @Test
   @Parameters(value = {
      "10000, 1, 3, 1331",   // 3 days after 1 initial  zombie in 10000 people
      "10000, 2, 3, 2662",   // 3 days after 2 initial  zombies in 10000 people
      "10000, 0, 3, 0",      // no initial zombies in 10000 people
      "10000, 1, 28, 10001", // 28 days after 1 initial zombie in 10000 people
      "10000, 1, 0, 1"       // 1 zombie and no contamination days in 10000 people
   })
   public void simulateZDay(int initialPeople, int initialZombies, int days, int finalZombies) {
      int newZombies = ZombieWarSimulator.getZombieNumberAfterDays(initialPeople, initialZombies, days);
      assertThat(newZombies).isEqualTo(finalZombies);
   }
 
}

Convaincu ? C'en est tellement simple que l'on peut même « blinder » notre code, en étendant encore davantage notre couverture avec des cas de tests supplémentaires, pour pas plus cher !

@RunWith(JUnitParamsRunner.class)
public class ZombieWarSimulatorTest {
 
   @Test
   @Parameters(value = {
      "10000, 1, 3, 1331",         // 3 days after 1 initial  zombie in 10000 people
      "100000, 1, 4, 14641",       // 4 days after 1 initial  zombie in 100000 people
      "1000000, 1, 5, 161051",     // 5 days after 1 initial  zombie in 1000000 people
      "10000, 2, 3, 2662",         // 3 days after 2 initial  zombies in 10000 people
      "100000, 2, 4, 29282",       // 4 days after 2 initial  zombies in 100000 people
      "1000000, 2, 5, 322102",     // 5 days after 2 initial  zombies in 1000000 people
      "10000, 3, 3, 3993",         // 3 days after 3 initial  zombies in 10000 people
      "100000, 3, 4, 43923",       // 4 days after 3 initial  zombies in 100000 people
      "1000000, 3, 5, 483153",     // 5 days after 3 initial  zombies in 1000000 people
      "10000, 0, 3, 0",            // no initial zombies, 3 days later
      "10000, 0, 4, 0",            // no initial zombies, 4 days later
      "10000, 0, 5, 0",            // no initial zombies, 5 days later
      "10000, 1, 28, 10001",       // 28 days after 1 initial zombie in 10000 people
      "10000, 1, 280, 10001",      // 280 days after 1 initial zombie in 10000 people
      "10000, 1, 2800, 10001",     // 2800 days after 1 initial zombie in 10000 people
      "10000, 1, 0, 1",            // 1 zombie and no contamination days
      "10000, 2, 0, 2",            // 2 zombies and no contamination days
      "10000, 3, 0, 3"             // 3 zombies and no contamination days
   })
   public void simulateZDay(int initialPeople, int initialZombies, int days, int finalZombies) {
      int newZombies = ZombieWarSimulator.getZombieNumberAfterDays(initialPeople, initialZombies, days);
      assertThat(newZombies).isEqualTo(finalZombies);
   }
 
}

Formidable non ? Pas si sûr… En effet, les TU c'est bien, en abuser ça craint. Nous venons ici d'ajouter des cas de tests supplémentaires qui n'ont pas augmenté notre couverture de code : en effet, ils sont redondants avec les cas précédents, ils n'apportent donc rien de plus. La situation est même pire que ça.

• Le coût récurrent de maintenance de ce test a été augmenté (si je change l'implémentation de getZombieNumberAfterDays(), je dois mettre à jour d'autant plus de valeurs de référence de « newZombies »).
• Le test a perdu en clarté : les cas de test intéressants qu'il serait judicieux de mettre en lumière sont noyés dans un brouhaha de tests identiques.
• Le temps d'exécution de mes tests est rallongé.

Comme nous venons de le voir, avoir une armada de tests unitaires sur son application, c'est très rassurant et sécurisant ; ça laisse supposer que l'on bénéficie d'une bonne couverture de tests qui en cas de régression s'avérera salvatrice. « C'est pas faux ! » diront certains… Mais si ça implique d'avoir des builds qui tournent pendant des plombes, cela risque fort d'être très mauvais pour la productivité et la réactivité de l'équipe de développement…

VII-A. Conséquences▲

VII-B. Alors que faire ?▲

Comme nous venons de le voir, une des actions possibles pour lutter contre des tests unitaires trop longs, c'est de les optimiser, notamment en profitant des architectures multicœurs des machines modernes afin de les exécuter en parallèle.

VIII-A. Le geste technique▲

<plugins>
   [...]
   <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-surefire-plugin</artifactId>
      <version>2.16</version>
      <configuration>
         <!-- make tests classes & methods runnable in parallel -->
         <parallel>both</parallel>
         <!-- use a 10 thread thread pool -->
         <threadCount>10</threadCount>
      </configuration>
   </plugin>
   [...]
</plugins>

<plugins>
   [...]
   <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-surefire-plugin</artifactId>
      <version>2.16</version>
      <configuration>
         <!-- run tests on a pool of 3 concurrent process -->
         <forkCount>3</forkCount>
         <!-- use a pool of JVMs -->
         <reuseForks>true</reuseForks>
      </configuration>
   </plugin>
   [...]
</plugins>

VIII-B. Le 2e effet Kiss Cool▲

public interface Cache {
   Object get(int id);
   int size();
   void flush();
}
 
//not thread safe impl
public class CacheImpl implements Cache {
 
   Map<Integer, Object> cache = new HashMap<Integer, Object>();
   int size = 0;
 
   public Object get(int id) {
      if (cache.get(id) == null) {
         cache.put(id, load(id));
         size++;
      }
      return cache.get(id);
   }
 
   protected Object load(int id) {
      // load from DB...
   }
 
   void flush() {
      cache = new HashMap<Integer, Object>();
      size = 0;
   }
 
   public int size() {
      return size;
   }
 
}
 
public class CacheTest {
 
   private static Cache cache = new CacheImpl();
 
   @Test
   public void testLoadFromCache() throws Exception {
      cache.flush();
      cache.get(1);
      assertEquals("1 object should be in cache", 1, cache.size());
   }
 
   @Test
   public void testLoad2FromCache() throws Exception {
      cache.flush();
      cache.get(1);
      cache.get(2);
      assertEquals("2 objects should be in cache", 2, cache.size();
   }
 
}

Failed tests:
CacheTest.testLoad2FromCache:25 2 objects should be in cache expected:<2> but was:<3>
CacheTest.testLoadFromCache:18 1 object should be in cache expected:<1> but was:<3>

public class CacheTest {
 
   private static Cache cache = new CacheImpl();
 
   @Test
   public void testLoadFromCache() throws Exception {
      int size = 0;
      synchronized (cache) {
         cache.flush();
         cache.get(1);
         size = cache.size();
      }
      assertEquals("1 object should be in cache", 1, size);
   }
 
   @Test
   public void testLoad2FromCache() throws Exception {
      int size = 0;
      synchronized (cache) {
         cache.flush();
         cache.get(1);
         cache.get(2);
         size = cache.size();
      }
      assertEquals("2 objects should be in cache", 2, cache.size());
   }
 
}

public interface Cache {
   Object get(int id);
   void flush();
   int size();
}
 
// thread-safe cache impl
public class CacheImpl implements Cache {
 
   Map<Integer, Object> cache = new HashMap<Integer, Object>();
   int size = 0;
 
   public synchronized Object get(int id) {
      if (cache.get(id) == null) {
         cache.put(id, load(id));
         size++;
      }
      return cache.get(id);
   }
 
   protected Object load(int id) {
      // load from DB...
   }
 
   public synchronized void flush() {
      cache = new HashMap<Integer, Object>();
      size = 0;
   }
 
   public synchronized int size() {
      return size;
   }
 
 }

public class CacheSpyImpl extends CacheImpl implements Cache {
   public static int loadNumber = 0;
   @Override
   protected Object load(int id) {
      loadNumber++;
      return super.load(id);
   }
}
 
public class CacheTest {
 
   private Cache cache = new CacheSpyImpl();
 
   @Before
   public void initCache() {
      CacheSpyImpl.loadNumber = 0;
      cache.flush();
   }
 
   @Test
   public void testLoadFromCache() throws Exception {
      cache.get(1);
      assertEquals("The object should have been loaded from DB", 1,      CacheSpyImpl.loadNumber);
   }
 
   @Test
   public void testReloadFromCache() throws Exception {
      cache.get(1);
      assertEquals("The cache should have been loaded from DB", 1, C     acheSpyImpl.loadNumber);
      // get from cache
      cache.get(1);
      assertEquals("The object should be in cache", 1, CacheSpyImpl.loadNumber);
   }
 
}

Failed tests:
CacheTest.testReloadFromCache:29 The cache should have been loaded from DB expected:<1> but was:<2>
CacheTest.testLoadFromCache:23 The object should have been loaded from DB expected:<1> but was:<2>

public class FnocServiceTest {
 
   String outputReport = "output.csv";
   FnocService service = new FnocService();
 
   @Test
   public void testCreateOrdersReport() throws Exception {
      // create orders report
      dumpReeport(new Order("Best of Star Acadebide"), outputReport);
      // check result from file system
      String actualReport = readFile(outputReport);
      String expectedReport = readFile("src/test/resources/order_report_cd.csv");
      assertEquals(expectedReport, actualReport);
   }
 
   @Test
   public void testCreateOrdersReport() throws Exception {
      // create orders report
      service.dumpReeport(new Order("Walking Beer", "World Bar Z"), outputReport);
      // check result from file system
      String actualReport = readFile(outputReport);
      String expectedReport = readFile("src/test/resources/order_report_bluray.csv");
      assertEquals(expectedReport, actualReport);
   }
 
}

public class FnocServiceTest {
 
   FnocService service = new FnocService();
 
   @Test
   public void testOrdersReportCD() throws Exception {
      // generate unique file name e.g /tmp/out~7549426430997112982.csv
      String outFile = File.createTempFile("out~", ".csv").getAbsolutePath();
      // create orders report
      service.dumpReeport(new Order("Best of Star Acadebide"), outFile);
      // check result from file system
      String actualReport = readFile(outFile);
      String expectedReport = readFile("src/test/resources/order_report_cd.csv");
      assertEquals(expectedReport, actualReport);
   }
 
   @Test
   public void testOrdersReportBluray() throws Exception {
      //generate unique file name e.g /tmp/out~54659864654654.csv
      String outFile = File.createTempFile("out~", ".csv").getAbsolutePath();
      // create orders report
      service.dumpReeport(new Order("Walking Beer", "World Bar Z"), outFile);
      // check result from file system
      String actualReport = readFile(outFile);
      String expectedReport = readFile("src/test/resources/order_report_bluray.csv");
      assertEquals(expectedReport, actualReport);
   }
 
}

/**
 * A JUnit4 Category for test that need to be executed in a monothread environnemnet (disable parallelisation of tests execution)
*/
public interface SequentialTestCategory { }

@Category(SequentialTestCategory.class)
public class TestComplicatedAndNotThreadSafeCode {
 
   public void testUnthreadsafeMethod1() {
      ...
   }
 
   public void testUnthreadsafeMethod2() {
      ...
   }
 
}

<properties>
   <test.parallel>both</test.parallel>
</properties>
...
 
<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-surefire-plugin</artifactId>
 
   <executions>
      <execution>
         <!-- thread safe tests -->
         <id>default-test</id>
         <phase>test</phase>
         <goals>
            <goal>test</goal>
         </goals>
         <configuration>
            <excludedGroups>SequentialTestCategory</excludedGroups>
            <parallel>${test.parallel}</parallel>
            <perCoreThreadCount>true</perCoreThreadCount>
            <threadCount>10</threadCount>
         </configuration>
      </execution>
      <execution>
         <!-- thread unsafe tests -->
         <id>sequential-tests</id>
         <phase>test</phase>
         <goals>
            <goal>test</goal>
         </goals>
         <configuration>
            <groups>SequentialTestCategory</groups>
            <parallel>none</parallel>
         </configuration>
      </execution>
   </executions>
</plugin>
...

/$ mvn test -Dtest.parallel=none

À présent, voici l'histoire de Bob. Qui est Bob ? Un développeur lambda plus vraiment junior, pas vraiment senior, Bob c'est vous, c'est moi. À travers ses expériences passées, Bob a fini par comprendre (certes dans la douleur), pourquoi tester son code. Il est aujourd'hui parfaitement convaincu de l'utilité des tests, la difficulté résidant à présent dans « l'art et la manière »

Bob travaille actuellement sur le projet« Pwetter », un système de microblogage très prometteur. Il vient de développer une nouvelle fonctionnalité, permettant de rechercher les « Pwets » postés contenant certains mots-clés. Bien décidé à mettre en pratique les bons principes, il ajoute dans le projet la classe de test unitaire suivante :

public class PwetterSearchTest {
 
   @BeforeClass
   public void static startup() {
      PwetServer.connect("mongodb://dbdev1.pwetter.net,dbdev2.pwetter.net:2500/?replicaSet=test");
   }
 
   @AfterClass
   public void static shutdown() {
      PwetServer.disconnect();
   }
 
   @Test
   public void testSearch() throws Exception {
      // Arrange
      PwetService api = PwetServer.getServiceInterface();
      api.post("Hey people ! So@t rocks !!!");
      api.post("Be smart, enjoy coding");
      api.post("So@t, what else ?");
 
      // Act
      List<Pwet> pwets = api.search(new KeywordFilter("So@t"));
 
      // Assert
      assertThat(pwets).containsExactly("Hey people ! So@t rocks !!", "So@t, what else ?");
   }
 
}

Bob exécute son test, tout fonctionne. Et pourtant, ce n'était peut-être pas une bonne idée. Mais il est où le problème, me direz-vous ?

Même s'il faut accorder à Bob que :

• le test unitaire fonctionne ;
• il couvre une fonctionnalité importante ;
• il valide l'algorithme de recherche, la persistance, et l'intégration réussie dans le reste du projet.

… Il n'a d'unitaire que le nom, et ressemble furieusement à un « test d'intégration » :

• il teste une fonctionnalité entière, qui s'appuie sur plusieurs « briques logicielles », qui couvre une grande partie de code, et dans un contexte « intégré » avec le reste du code ;
• il dépend de la disponibilité de la « base » ;
• il peut être assez long à s'exécuter.

En outre, un test d'intégration ne remplace pas les tests unitaires du code sous-jacent, mais il en est complémentaire. Un test unitaire trop gourmand (qui couvre beaucoup de code dans un seul test) :

• sera fragile (la moindre évolution du code le fera virer au rouge) ;
• sera très difficile à maintenir (il ne sera pas aisé de trouver l'origine du problème dans un périmètre aussi vaste !) ;
• nous donnera finalement une faible couverture de code (dans un use case fonctionnel, on ne teste pas les n cas aux limites des briques logicielles sous-jacentes).

Ce test a malgré tout une certaine valeur, mais il n'a pas sa place parmi les tests unitaires. Il doit en être isolé (avec les autres « tests d'intégration »), afin de pouvoir être exécuté de manière dissociée des vrais tests unitaires. Ainsi, les vrais tests unitaires ne seront pas pénalisés par sa fragilité !

Qui dans sa vie de développeur n'a jamais été confronté au fameux test, qui des fois passe, des fois échoue ? Nous venons de le voir, les raisons possibles sont multiples :

• bugs d'accès concurrents ;
• logique métier testée intrinsèquement non déterministe ;
• problèmes aléatoires de dépassement de mémoire (OutOfMemory) ;
• indisponibilité temporaire du réseau ;
• indisponibilité temporaire de la base ;
• espace disque insuffisant ;
• partage d'une ressource commune non stable (telle qu'un composant tiers extérieur) ;
• utilisation d'une dépendance SNAPSHOT.

Quelle qu'en soit la cause, ces tests en échec sur le build continu, qui mystérieusement se réparent tout seuls viennent briser votre concentration, et parasiter votre tâche en cours, et émoussent irrémédiablement votre vigilance : c'est l'histoire du jeune garçon qui criait « au loup », ces faux positifs vous amènent à ne plus prêter attention aux builds en échec sur la forge logicielle… Ce « bruit » implique des retards sur la correction des véritables régressions, noyées dans la masse, ce qui aura pour conséquences :

• l'augmentation du coût de maintenance des tests (plus une correction est faite tardivement, plus elle est difficile, plus elle coûte cher) ;
• la généralisation du « bypass » des tests de la part les développeurs.

Cela peut aboutir à la désactivation partielle, voire globale des tests unitaires par un développeur exaspéré (voilà, les TU sont morts, « game over ») !

Ces faux positifs sont une plaie, parfois trop souvent pris à la légère, qu'il faut à tout prix régler au plus tôt :

• en corrigeant le problème, si c'est corrigeable ;
• à défaut, en isolant en quarantaine les tests pathologiques (en les catégorisant par exemple), et ainsi éviter les faux positifs à répétition sur le continuous build (en attendant une réelle correction, les tests pathologiques seront lancés avec une fréquence moindre, et uniquement dans un contexte dédié, sous contrôle d'un développeur averti) ;
• dans le pire des cas et faute de mieux, en désactivant/supprimant le test incriminé, qui finalement fait plus de mal que de bien (la question à se poser à ce moment-là est bel est bien : « le soldat Ryan mérite-t-il d'être sauvé ? »).

Nous avons passé en revue des problématiques que l'on rencontre classiquement quand on écrit et maintient des tests unitaires automatisés… Même si certains problèmes ont des solutions, et ne demandent qu'un peu d'expérience ou d'astuce pour être résolus, d'autres en revanche n'ont pas de solution “miracle”, et appellent au compromis, et nous amèneront à nous poser la question : quel est le coût de mise en place, le coût de maintenance, et le gain à la clé ?

XI-A. Actif▲

XI-B. Passif▲

XI-C. To test or not to test ?▲

Cet article a été publié avec l'aimable autorisation de la société SoatSoat. Les articles originaux (10 trucs infaillibles pour rater ses tests unitaires en toutes circonstances partie 1 et partie 2) peuvent être vus sur le blog/site de Soat.

Nous tenons à remercier ced pour sa relecture attentive de cet article et Mickaël Baron pour la mise au gabarit.