Suivi du ratio de couverture des tests avec SimpleCov

[adipasquale]

Contexte

On avait parlé d’explorer la mise en place de coverage lors d’un point tech avec François

Solution

Je suis parti sur SimpleCov qui semble être le plus abouti.

Il ne fait le coverage QUE du code ruby.

C’était un peu compliqué à mettre en place sur notre GitHub Action à cause du double niveau de parallélisme qu’on utilise : matrix GH action + parallel_tests.
Heureusement, la doc de SimpleCov est top et propose des solutions pour ces situations.

J’ai repris le code proposé dans la doc et j’ai fait la plomberie dans notre GH Action :

• définir les bonnes variables d’environnements pour que les runs de tests aient des noms uniques pour SimpleCov
• uploader les rapports de couverture générés par chaque run
• rajouter un job qui attend la fin des feature specs et unit tests, télécharge les rapports de couverture, les fusionne et utilise simplecov-check-action pour rajouter un check dans la pull request.

J’ai laissé la config par défaut : le check sera un fail si le coverage est < 90%.

On avait plutôt évoqué au point tech la possibilité d’empêcher des régressions du coverage.
C’est plus technique à mettre en place car il faudrait partager les résultats du dernier run sur production.
Ça me paraît faisable mais ça demande encore un peu d’ingénierie dans la GH Action :

• quand on est sur la branche production il faudrait uploader le resultset.json vers une URL publique (les artifacts GH ne sont que intra-workflows)
• quand on est sur les branches de PR il faudrait télécharger ce fichier et le stocker dans coverage.last_run.json
• puis il faudrait activer l’option SimpleCov.maximum_coverage_drop

On calcule ici le coverage par ligne sur toutes les lignes ruby

[AntoineGirard]

Du coup ici, on n'est pas bloquant ?
Est-ce qu’on ne risque pas la regression de code coverage en dessous de 90% en étant pas bloquant ?

[adipasquale]

en effet bien vu je l’avais mis en me disant qu’on allait être en dessous

[adipasquale]

La question que je me pose c’est : est-ce utile d’avoir ce taux de couverture planqué dans les checks GH ? est-ce qu’on va vraiment le suivre ?

ping @francois-ferrandis

[francois-ferrandis]

La question que je me pose c’est : est-ce utile d’avoir ce taux de couverture planqué dans les checks GH ? est-ce qu’on va vraiment le suivre ?

ping @francois-ferrandis

Je vois qu'il existe des actions qui postent un commentaire sur la PR pour informer du taux de couverture, par exemple celle-ci : https://github.com/marketplace/actions/coverage-diff

If acting on a PR, it will [...] produce a diff coverage report with the json-summary file from repository's default branch. Then it will publish the diff coverage report as comment to the PR. If a comment had already previously be written, it will be updated.

C'est à ce genre d'affichage que je pensais initialement quand j'ai évoqué le sujet, mais on peut aussi explorer d'autres pistes.

[adipasquale]

@francois-ferrandis merci super intéressant ! l’enjeu principal pour pouvoir afficher un diff de coverage c’est de stocker et pouvoir récupérer le résultat du dernier run de coverage sur la branche main.

Cette GH action que tu suggères stocke ce fichier json dans le wiki du repo ce qui paraît assez intelligent :) le wiki se comporte en partie comme un repo git et on peut y pusher des fichiers.

ça demande quand même un peu d’ingénierie supplémentaire, je ne sais pas si on veut investir ce temps (et la future maintenance de ce code supplémentaire). Moi ça m’amuse pas mal de faire cette plomberie dans les github actions mais je soumets l’investissement de ce temps à la délibération collective :)