NCrunch-like sur IntelliJ.

Vous avez sans doute remarqué, peut-être même déjà utilisé cette fonctionnalité d’IntelliJ : l’auto-testing:

Cela n’a l’air de rien, vu comme ça. Mais l’auto-testing va révolutionner la pratique des tests dans vos équipes.

Dans cet article nous allons découvrir ensemble comment utiliser l’auto-testing pour avoir une couverture du code actualisée en temps réel, et comment l’utiliser dans le cadre du TDD.

• Un peu de théorie
  • Petit rappel : qu’est-ce que le TDD ?
  • Pourquoi la mise en pratique du TDD pose problème (même quand les équipes sont d’accord sur la théorie)
  • Auto-Testing, Test Coverage, Real Time Code Coverage ?
  • Et concrètement, comment le nouvel outil d’auto-testing va me permettre de mettre du Real Time Code Coverage en place ?
• Mise en place
• Mobilité
  • Les avantages du Real Time Code Coverage
  • Les inconvénients
  • Les cas d’utilisations
  • En Bonus : Un exemple de TDD en Continuous Coverage.
  • Deuxieme Bonus: Ma présentation à Devoxx:

Un peu de théorie

Petit rappel : qu’est-ce que le TDD ?

TDD, pour Test Driven Development, se décompose en 3 phases, et 7 actions du développeur :

Phase rouge :

1. écrire un test;
2. lancer le test;
3. valider que le test nouvellement écrit échoue (le code à tester n’a pas encore été écrit) afin de vérifier que le test est utile.

Phase verte :

1. écrire juste le code suffisant pour passer le test;
2. lancer le test;
3. vérifier que le test passe.

Phase de Refactoring :

1. puis réfactorer le code, c’est-à-dire l’améliorer tout en gardant les mêmes fonctionnalités 
   … et on repasse à l’étape 1 pour la fonctionnalité suivante.

Soit 7 actions manuelles à faire par l’utilisateur

Soit, contrairement à l’approche « Test-After-Driven-Development »

1. écrire du code
2. écrire un test
3. lancer le test
4. verifier que le test passe (le code a-t-il une quelconque influence sur le résultat du test ? Mystère…).

Ce qui, soit dit-en passant, est toujours mieux que l’approche « No-Test-Driven-Development »

1. écrire le code;
2. tester manuellement (le code va-t-il toujours passer les tests après 3 refactoring et 2 changements d’équipes ? Mystère…).

Pourquoi la mise en pratique du TDD pose problème (même quand les équipes sont d’accord sur la théorie)

Sur la théorie, beaucoup d’équipes sont d’accord sur la nécessité du TDD pour avoir une couverture de tests saine et efficace. Mais dans la pratique, avec le stress de tous les jours, les développeurs ont tendance à écrire en premier le code, ensuite éventuellement les tests.

L’une des causes principales du « Test-After » est relative au nombre d’étapes de la méthode: 7 étapes, en comptant le refactoring, contre 4 pour le « Test-After » : l’étape de lancement des tests et celle de refactoring sautent.

Pourquoi ? Généralement par oubli : difficile d’y penser dans le feu de l’action, lorsque toute notre attention est concentré dans l’implémentation de la fonctionnalité.

On entend également parfois dire que la phase de test est trop longue et coupe « l’élan » du développeur. Parfois aussi on retrouve le sentiment que leur jeux de tests ne couvre efficacement l’application.

Autant de problèmes que des tests lancés automatiquement en continu pendant le développement et une couverture de tests actualisée en temps réel permettront de régler facilement.

Auto-Testing, Test Coverage, Real Time Code Coverage ?

L’Auto-Testing (ou Continuous Testing), agit comme une usine d’intégration en continu sur votre machine locale : plus besoin de penser à lancer les tests, l’IDE le fait pour vous. Si en plus vous faites du TDD, on parle alors de Continuous Test Driven Development (CTDD). 

Le nombre d’étapes à faire par l’utilisateur et leur complexité est moindre:

1. écrire un test
   (le test est lancé automatiquement)
2. vérifier que le test a échoué
3. écrire juste le code suffisant pour passer le test
   (le test est lancé automatiquement)
4. verifier que le test a réussi
5. puis réfactorer le code, c’est-à-dire l’améliorer tout en gardant les mêmes fonctionnalités
   … et on repasse à l’étape 1 pour la fonctionnalité suivante.

Le Test Coverage, c’est indiquer si un bloc de code est exécuté (ou non) par au moins un test.

Le Real Time Code Coverage, c’est donc calculer en temps réel quelles sont les lignes de code couvertes par vos tests.

Et concrètement, comment le nouvel outil d’auto-testing va me permettre de mettre du Real Time Code Coverage en place ?

L’auto-testing permet de lancer les tests sur votre machine locale à chaque build du projet.
Combiné avec le build automatique, il permet de relancer les tests à chaque modification du code.
Combiné au test code coverage, vous avez la couverture de tests du projet actualisée en continu.

Un peu comme avec le plugin NCrunch de Visual Studio pour le DotNet, mais pour IntelliJ et Java, en somme.

 

La différence par rapport aux autres plugins d’auto-testing est que ces fonctionnalités sont intégrées nativement dans IntelliJ Idea, offrant ainsi de meilleurs performances.

Mise en place

Vous devez avoir au moins la version 2016.3 (3.0) d’IntelliJ IDEA.

1. Configurer le build automatique sur votre projet (désactivé par défaut sur Intellij) ;

2. lancer les tests que vous désirez faire tourner en continu (via le test launcher, pas via maven) en mode « test coverage »

3. dans le run d’un test, sélectionner l’option « toggle auto-test »

Désormais, à chaque modification, les tests seront relancés et la couverture de tests actualisée en continu.

Et en pratique ?

Prenons un exemple simple, le kata « FizzBuzz ».

Pour les nombres de 1 à 100 :

• pour les multiples de 3 : afficher Fizz,
• pour les multiples de 5 :  afficher Buzz,
• pour les multiples de 3 et 5 : afficher FizzBuzz.
• et pour les autres, afficher simplement le nombre

Lors de l’ajout de nouveaux tests, la couverture du code est mise à jour automatiquement:

L’ajout de nouveau code non testé est tout de suite visible grâce à la couverture de code continue :

 

Et les erreurs sont visibles à peine codées :

Et voilà, vous bénéficiez du Continuous Coverage.

 

Les avantages du Real Time Code Coverage

• Les tests sont lancés en continu, sans intervention du développeur.
  Pratique pour détecter un bug à peine codé.
• La couverture de test est actualisée en continu.
  Pratique pour détecter un pan de code non couvert dans du code legacy
• A peine écrits, les tests sont lancés.
  Pratique pour vérifier que les tests ne passent pas (1ère étape du TDD)
• À peine écrit, le code est testé.
  Pratique pour verifier que le code passe les tests.
• Une fois le continuous testing sélectionné, il continuera à se lancer systématiquement.
  Plus besoin d’y penser après le redémarrage d’Intellij.
• Le code coverage est indépendant du continuous testing. Il est possible d’avoir l’un sans l’autre.
  La nouveauté réside dans le fait d’avoir l’un avec l’autre, chose que les solutions précédentes ne proposaient pas.

Les inconvénients

• Gourmand en temps et en CPU : les tests sont exécutés intégralement à chaque auto-build du projet (du moins en l’état actuel de la fonctionnalité)
• Disponible uniquement sur le test launcher de Intellij.
• Un laps de temps de quelques secondes lors du recalcul de la couverture du code par les tests.
• La coloration des lignes ne tient pas compte du résultat des tests (contrairement à NCrunch).

Les cas d’utilisations

J’ai particulièrement tiré profit du continuous coverage pour les fonctionnalités algorithmiquement complexes, pour lesquelles je souhaite une couverture précise et pertinente.
Je restreins manuellement le périmètre des tests à seulement ceux couvrant la fonctionnalité concernée, afin de préserver les performances et d’avoir une couverture actualisée rapidement.

Pour conclure, la combinaison couverture de code et build automatique permet grandement de faciliter la pratique du TDD, mais il est dommage que l’on doive manuellement restreindre le perimètre des tests pour des questions de performances.

En Bonus : Un exemple de TDD en Continuous Coverage.

Toujours autour du kata fizzBuzz     J’écris un test, et juste assez de code pour que cela compile: Je lance les tests une première fois en coverage: je n’aurais plus besoin de le faire ensuite Je vérifie que le test ne passe pas Je commence à écrire mon code . Et au fur et à mesure, je vois que mon code est couvert par la couverture de tests Et je vois en direct que mon test passe Passage au cas suivant: le Buzz : D’abord le test Je vérifie que le test échoue Ensuite le code Tous les tests passent ! Je continue à écrire mon code. Et là, problème : la couverture de tests continue m’indique que la ligne 20 de mon code n’est pas couvert par les tests. Aurais-je mal respecté le TDD et oublié un cas de test ? Je corrige immédiatement en rajoutant un test À peine écrit, le test est exécuté automatiquement et passe Cas d’utilisation suivant : le FizzBuzz À peine écrit, le test échoue je corrige (il manquait un +) et je vois en direct, les tests passer au vert

 

Deuxieme Bonus: Ma présentation à Devoxx:

 

 

source: https://www.jetbrains.com/help/dotcover/Continuous_Testing.html