Vitesse et fiabilité de la suite

Une suite de dix-huit minutes n'est plus lancée avant de pousser. Une suite qui échoue une fois sur six pour des raisons variables n'est plus lue : l'équipe relance, et si ça passe, on fusionne. Dans les deux cas, la suite a cessé de faire son travail, et ce n'est pas parce qu'elle contient de mauvais tests — c'est parce qu'elle est devenue trop coûteuse ou trop bruyante pour qu'on lui accorde de l'attention.

Ces deux dégradations s'installent progressivement et se traitent de la même manière : par la mesure. Personne ne devine correctement où passe le temps d'une suite de tests, et personne ne devine la cause d'un test instable. Les deux se constatent, avec des outils qui sont déjà dans votre projet. Cette leçon commence donc par lire les données que Surefire et Gradle produisent déjà, puis passe à la parallélisation, aux causes réelles de l'instabilité, et à ce que la couverture de code mesure vraiment.

Mesurer avant d'optimiser

Surefire écrit un fichier XML par classe de test dans target/surefire-reports, avec la durée de chaque méthode. Un tri par durée décroissante suffit à identifier les coupables.