Tests unitaires / E2E

Tests E2E

Plus résilient de passer par un attribut data- (ex: data-test) que par des classes css ou des éléments html

= un test isolé des autres tests et des dépendances "dures à tester" (pas de base de données, d'utilisation du système de fichiers, du réseau, etc)
Ajouter une classe n'est pas un déclencheur d'écriture de test. Le déclencheur = implémenter un nouveau comportement
Eliminer la dépendance entre tests et code : le test doit tester l'API / le contrat, pas les détails de l'implémentation !!
- Ne pas tester le code "interne"
- Ne pas tout rendre "public" pour pouvoir le tester
- Garder une API publique légère

L'idéal = un nom qui reprend la règle de gestion testée (exemple Divide_should_raise_an_error_when_denominator_is_zero)
On peut s'inspirer des patterns de nommage inspiré du BDD : should/when et given/when/then

Généralement divisé en 3 sections (qu'on peut retrouver sous le nom Arrange/Act/Assert) :
- Initialisation des données (Arrange)
- Appel de la fonctionnalité à tester (Act)
- Vérification du résultat (Assert)

Workflow :

Red => écrire un test qui ne passe pas
Green => faire en sorte que le test passe rapidement, même si le code est moche
Refactor => refactorer le code (appliquer des patterns, enlever les duplicata, les code smells, etc). A ce moment là on n'écrit pas de nouveaux tests unitaires ! (car si on en ajoute ils seront couplés à l'implémentation)
Un test qui passe = un commit

Deux niveaux de TDD :

TDD, where did it all go wrong
Livre Software Craft de Cyrille Martraire
A lire :
- Test-Driven Development by Example de Kent Beck
- Refactoring to Patterns de Joshua Kerievsky