Coder chez Google - Les tests

Ce billet fait partie d'une série en 4 volets : #1, #2, #3, #4.

Suite de ma sélection de citations et de notes sur le livre Software engineering at Google.

Cette partie rassemble mes notes sur les tests.

Vue d'ensemble des tests

Chap. 11 Testing Overview

Intérêts d'une suite de tests :

• réduire les bogues
• confiance accrue lors des changements
• des tests clairs et ciblés constituent une bonne documentation
• revues de code plus simples
• conception réfléchie
• sorties de nouvelles versions (releases) plus rapides et de meilleure qualité

En tant que premier client de votre code, un test peut vous en apprendre beaucoup sur vos choix de conception.

À mesure que la base de code grossit, les tests vont commencer à souffrir de problèmes d'instabilité et de lenteur. S'ils deviennent un gouffre pour la productivité de l'équipe, la confiance des développeurs dans les tests va s'effriter. Une mauvaise suite de tests peut être pire que pas de suite de test. Corriger les tests permet de maintenir un niveau de confiance élevé dans le processus.

Selon l'expérience de Google, à mesure que l'on s'approche d'1% d'instabilité, les tests commencent à perdre de leur valeur.

Si vous devez réparer un test défectueux que vous n'avez jamais vu, vous serez reconnaissant que quelqu'un ait pris le temps de le rendre facile à comprendre.

Google classe les tests en 3 catégories : "petit", "moyen" et "grand" :

• petits tests :
  • doivent se lancer sur un seul processus et de préférence sur un seul thread
  • n'ont pas le droit de faire des IO (pas d'accès réseau ou disque)
  • servent à combattre l'instabilité
• tests moyens :
  • peuvent se lancer sur plusieurs processus, utiliser des threads
  • peuvent effectuer des appels bloquants, y compris des appels réseau mais seulement sur localhost
  • c'est là que l'intégration d'une base de données se fait
• grands tests :
  • peuvent effectuer des appels réseau, et pas seulement sur localhost

Imposer des petits tests rend la vitesse et le déterminisme plus faciles à atteindre. Les tests plus importants ne sont préconisés que pour les scénarios les plus complexes.

Google vise 80% de petits tests, 15% de moyens et 5% de grands, voir la pyramide de tests de Mike Cohn.

The Beyoncé Rule:

If you liked it, then you shoulda put a test on it.

La couverture de code (code coverage) mesure le taux de code source exécuté quand une suite de test est lancée. Sur 100 lignes de code, si vos tests en exécutent 90, vous avez une couverture de code de 90%. Mais ça ne mesure que le fait qu'une ligne est invoquée, et non pas le résultat. Comme d'autres mesures, elle a l'inconvénient de devenir rapidement un but en soi.

Testing on the Toilet a été une stratégie à l'intérieur du groupe pour diffuser la culture des tests.

Testing has enabled Google to build larger systems with larger teams faster than we ever thought possible.

Test unitaire

Chap. 12 Unit Testing

Il s'agit des petits tests.

Après la prévention des bogues, l'objectif le plus important des tests est d'améliorer la productivité des développeurs.

Un bon test est un test dont la raison d'être et la cause de l'échec sont immédiatement clairs et permettent de faire le diagnostic d'une défaillance.

Un bon test doit être exhaustif et concis, voir What Makes a Good Test? :

• il est exhaustif lorsqu'il contient toutes les informations nécessaires à sa compréhension
• il est concis lorsqu'il ne contient rien d'autre que ce qui est nécessaire pour être exhaustif

Il est souvent utile de transgresser le principe DRY dans les tests quand ça permet d'aboutir à davantage de clarté. Le corps d'un test doit contenir toutes les informations nécessaires pour le comprendre :

DAMP, not DRY (descriptive and meaningful phrases)

Tester les comportements, pas les méthodes. Utiliser le GivenWhenThen :

"Given that a bank account is empty, when attempting to withdraw money from it, then the transaction is rejected."

Il y a une relation de plusieurs-à-plusieurs entre des méthodes et des comportements : la plupart des méthodes mettent en œuvre des comportements multiples, dont certains reposent sur l'interaction de plusieurs méthodes.

Nommez les tests d'après le comportement testé, pas d'après le nom de la méthode testée. Ça donne des noms de tests verbeux par rapport au code de production mais ça n'est pas grave dans les tests.

Ne mettez pas de logique dans les tests.

Déterminer avec précision le framework de test et normaliser le processus est extrêmement bénéfique pour l'équipe.

Test doubles

Chap. 13 Test doubles

Les Test Doubles sont des objets ou des fonctions qui remplacent une implémentation réelle dans un test.

Par exemple, utiliser une base de données in-memory pour émuler un serveur SQL complet.

Il y a trois techniques pour utiliser les Test Doubles :

• faking
• stubbing, valeur de retour d'une fonction en dur
• interaction testing

Tests à grande échelle

Chap. 14 Larger Testing

Les tests à grande échelle donnent l'assurance que le système global fonctionne comme prévu.

Ils peuvent impliquer un ensemble de dépendances réelles et prendre beaucoup de temps à s'exécuter. Certains prennent des heures, ou même des jours.

For years, Google has run an annual war game called DiRT (Disaster Recovery Testing) during which faults are injected into our infrastructure at a nearly planetary scale.