Tests aquatiques 💧

Published in

La Fabrique

5 min readApr 20, 2018

Chez KissKissBankbank, nous testons notre code Ruby avec cet outil quelque peu connu dans le Ruby game : RSpec. Récemment, nous avons automatisé ces mêmes tests avec un outil d’intégration continue, lui aussi plutôt populaire, j’ai nommé CircleCI.

Puis, las des ~40 minutes nécessaires pour exécuter tous nos tests (oui, c’est très long), nous avons décidé d’activer la parallélisation sur CircleCI, ce qui nous a alors permis de diviser le temps d’exécution de nos tests par autant de containers utilisés.

Mais c’est également ce qui signa le début de La Grande Guerre Des Specs.

En effet, c’est précisément après la mise en place de cette parallélisation que nos tests se sont mis à échouer de manière aléatoire sur CircleCI, mais pas en local.

Comment reproduire un échec CircleCI en local ?

Sur CircleCI, dans l’encart TEST, au tout début du fichier de logs, deux éléments vont se révéler très utiles :

Le premier élément à récupérer est la liste des fichiers de tests qui ont été exécutés dans le container sélectionné ;
Le deuxième élément est le numéro de seed. Ce numéro permettra à RSpec de rejouer les specs exactement dans le même ordre, et donc de reproduire les mêmes erreurs.

Ensuite, en local :

bundle exec rspec --fail-fast 'spec/api/history_api_spec.rb' 'spec/api/project_api_spec.rb' [...] --seed 35366

(L’option --fail_fast permet de stopper l’exécution des tests dès le premier échec.)

En utilisant cette technique, nous avons pu reproduire exactement le même échec en local, et donc identifier la raison de ces noyades aléatoires : les fuites de données.

Étanchéité et imperméabilité

Le premier side effect de la parallélisation a été de changer l’ordre d’exécution des tests. C’est en constatant que certains tests échouaient uniquement s’ils étaient exécutés après d’autres que nous avons compris que nos tests n’étaient ni imperméables, ni étanches.

Mais-dis moi Jamy, qu’entends-tu donc par tests imperméables et étanches ? Eh bien Fred, c’est simple, un test étanche est un test dont les data ne vont pas “fuir” ; tandis qu’un test imperméable est un test dont le résultat n’est pas impacté par les éventuelles fuites d’autres tests.

C’est évidemment la combinaison des deux qui va être problématique. Il n’y aura pas de problèmes en cas de fuite de données si les tests sont tous imperméables, comme il n’y en aura pas non plus en cas de tests non imperméables mais étanches.

La bonne pratique

Vaut-il donc mieux travailler sur l’étanchéité ou l’imperméabilité ?

Une des réponses les plus naturelles à cette question serait de dire : écrivons plutôt des tests imperméables, nous n’aurons alors pas de data à nettoyer et gagnerons en performance.

Le problème avec cette option est qu’elle est tout simplement difficile à mettre en place au niveau de la globalité d’une équipe. On ne va pas se mentir, ça n’est déjà pas simple d’assurer une couverture de test optimale ; il faut parfois insister et argumenter pour que des tests soient tout simplement écrits. Devoir en plus s’assurer que chaque test écrit soit 100% imperméable est une difficulté supplémentaire. Cela demande plus d’effort du côté de celui∙celle qui écrit le test, et plus de vigilance du côté des relecteurs∙rices.

Alors que, du côté de la team étanchéité, on s’affranchit purement et simplement de cette difficulté. On met en place une fois un outil de nettoyage de data et hop, terminé bonsoir ✌️

Nous avons donc choisi de travailler sur l’étanchéité, tout simplement parce qu’il n’était pas possible en terme de planning de repasser sur chacun de nos tests pour s’assurer de leur imperméabilité, et les réécrire le cas échéant.

Rendre vos tests étanches

Cette décision prise, nous avons alors mis en place DatabaseCleaner, qui, comme son nom l’indique, est un outil de nettoyage de base de données.

Celui-ci propose plusieurs stratégies de nettoyage :

truncation supprime les données en utilisant TRUNCATE TABLE ;
deletion supprime les données en utilisant DELETE FROM ;
transaction annule les transactions.

Il est généralement conseillé d’utiliser transaction, puisque c’est souvent bien plus rapide de rollback une transaction plutôt que de supprimer des données à postériori.

Nous avons donc mis en place cette configuration :

database_cleaner.rb

Après ça, les fuites ont beaucoup diminué, mais n’ont pas disparu pour autant, puisque tous nos tests utilisant la méthode before(:all)étaient toujours sujets à des fuites intempestives.

`before(:all)` VS `transaction`

Dans un bloc de type before(:each), le code est exécuté dans une seule transaction. Avec la stratégie transaction, cette transaction sera rollback par DatabaseCleaner.

Le code dans un before(:all) étant exécuté en dehors de cette transaction, les data éventuellement générées par ce code ne seront donc pas nettoyées par DatabaseCleaner.

L’exécution de nos tests étant déjà très longue (40 minutes, rappelez-vous 😢), nous avons décidé de ne pas changer globalement notre stratégie de nettoyage, mais plutôt de manière ponctuelle. À chaque before(:all), son after(:all) :

exemple d’utilisation ponctuelle du after(:all)

Et c’est ainsi que la lumière fut :

Pro tip de fin : il existe cette petite option de configuration dans RSpec :

RSpec.configure do |config|
  config.order = :random
end

Cette simple ligne permet de demander à RSpec de jouer systématiquement les exemples et les groupes d’exemples d’un test dans un ordre aléatoire. C’est un bon moyen d’être sûr∙e qu’un test est cloisonné de manière interne, et pas seulement par rapport aux autres tests.

Quelques ressources supplémentaires :