Clean code - chapitre 9 « Tests »


#1
  • Très important d’écrire des tests propres. Exemple d’une entreprise où le fait d’écrire les tests de façon pas maintenable a coulé le projet
  • Des tests propres, c’est des codes lisibles.
  • Marine : « Dans un test, il vaut mieux privilégier la lisibilité à la réduction de duplication » cf 99 bottles.
  • Un test doit être construit selon la structure ‘Given, when, then’, équivalent à ‘acteur, action, assertion’
  • Un test doit tester une seule chose. En tout cas un seul concept
  • Un test doit renvoyer un booléen
  • Un test doit utiliser assert_equal plutot que assert true ou false, pour la lisibilité
  • Il évoque la possibilité de refactorer la partie assertion dans une fonction à part. Possibilité de refactorer en conservant la lisibilité.
  • Elodie : « Le refactoring peut-il exister en dehors de la pratique du TDD ? »

Les 3 lois du TDD :

  • commencer par écrire un test d’échec
  • le test écrit doit être le plus petit possible
  • écrire uniquement le code de production suffisant pour faire passer le test

F.I.R.S.T

  • Fast : les tests doivent être rapides
  • Independant : les tests doivent pouvoir être lancés dans n’importe quel ordre, ne pas dépendre les uns des autres
  • Repeatable : les tests doivent pouvoir être lancés dans n’importe quel environnement
  • Self-validating : les tests doivent renvoyés un booléen
  • Timely : écrire le test en premier, juste avant d’écrire le code de production

#2

Une deuxième lecture nous permet de dire :

  • C’est important de garder le code de test lisible.
  • Pour garder une bonne lisibilité des tests, il ne faut pas hésiter à créer des fonctions spécifiques dans les tests pour simplifier.
  • La complexité des tests peut devenir un signal que quelque chose pourrait être amélioré.
  • Il faut essayer de tester les concepts, un par test, plutôt que de tester l’implémentation. C’est peut-être avec l’expérience qu’on y arrive…