Cypress, Playwright, testing-library... À la poubelle ? 🗑️
craftacademy.substack.com
Pas si vite moussaillon du Craft !
Vaste sujet que celui-ci :) Commençons par les bases : le TDD
Le TDD permet grâce à une boucle de feedback très rapide de piloter l'écriture de notre code production, en vérifiant que les comportements à implémenter sont bien implémentés.
Le point important ici est feedback. Il se doit d'être le plus rapide possible, et d'être le plus fiable possible. Et c'est là que les choses commencent à se complexifier.
Un TDD avec feedback extrêmement rapide, quasi instantané, utilise majoritairement des tests rapides, sans I/O d'aucune sorte.
Quid de leur fiabilité maintenant ? Ces tests vont nous permettre de piloter la logique métier de notre application frontend, en voyant notre app comme une grosse machine à état : "étant donné cet état initial, quand une action est effectuée, alors cet état final doit en résulter". Si ces tests passent, + les tests d'intégration sur les adapters, alors la suite apporte une très grande fiabilité quant à notre logique métier, son orchestration, et les branchements avec le monde extérieur.
Ces tests apportent-ils pour autant la fiabilité que l'on peut mettre en prod les yeux fermés et partir en weekend l'esprit tranquille ?
Non.
Du moins, pas à 100% (ce qui n'est jamais atteignable évidemment). On est plutôt sur un solide 80% par exemple.
Si on travaille seul, ou que le projet n'est pas nécessairement complexe, et qu'un bug n'est pas susceptible d'impacter énormément d'utilisateurs, ces 80% peuvent suffire !
Quid d'une application avec beaucoup d'écrans ? Des dizaines de développeurs travaillant dessus en trunk-based development ?
Les choses peuvent vite mal tourner. Une modification d'un CSS à endroit qui cascade des effets négatifs à un autre, obstruant par exemple un élément cliquable, et bim c'est toute une fonctionnalité qui n'est pas disponible. Alors que tous nos tests sont au vert. C'est ballot.
Que faire alors ?
Celles et ceux qui suivent ma formation savent que j'adore créer des DSL pour rédiger mes tests de façon lisible, et pouvoir écrire les nouveaux très facilement, un peu comme on empilerait des Legos.
L'avantage de cette DSL, c'est qu'on peut l'utiliser aussi pour rédiger des tests Cypress.
Il y a donc une implémentation de la DSL purement en mémoire, pour piloter le code très rapidement grâce au TDD.
Et il y a une implémentation Cypress, pour que la même suite de tests s'exécute cette fois dans Cypress :) (en implémentant par exemple qu'un simple happy path et wrong path).
De fait, on peut lancer dans notre pipeline la première suite de tests pour avoir une confiance d'environ 80% en moins de 5 minutes, puis exécuter la seconde dans une étape "d'acceptation", qui elle peut prendre un peu plus longtemps :)
Je montrerai tout ça dans un futur module du cursus Craft Academy :)
Happy Coding !
PS : Ce sont les derniers jours pour profiter des soldes sur https://craftacademy.fr ! Jusqu'à -60% :)
Cypress, Playwright, testing-library... À la poubelle ? 🗑️
Cypress, Playwright, testing-library... À la poubelle ? 🗑️
Cypress, Playwright, testing-library... À la poubelle ? 🗑️
Pas si vite moussaillon du Craft !
Vaste sujet que celui-ci :) Commençons par les bases : le TDD
Le TDD permet grâce à une boucle de feedback très rapide de piloter l'écriture de notre code production, en vérifiant que les comportements à implémenter sont bien implémentés.
Le point important ici est feedback. Il se doit d'être le plus rapide possible, et d'être le plus fiable possible. Et c'est là que les choses commencent à se complexifier.
Un TDD avec feedback extrêmement rapide, quasi instantané, utilise majoritairement des tests rapides, sans I/O d'aucune sorte.
Quid de leur fiabilité maintenant ? Ces tests vont nous permettre de piloter la logique métier de notre application frontend, en voyant notre app comme une grosse machine à état : "étant donné cet état initial, quand une action est effectuée, alors cet état final doit en résulter". Si ces tests passent, + les tests d'intégration sur les adapters, alors la suite apporte une très grande fiabilité quant à notre logique métier, son orchestration, et les branchements avec le monde extérieur.
Ces tests apportent-ils pour autant la fiabilité que l'on peut mettre en prod les yeux fermés et partir en weekend l'esprit tranquille ?
Non.
Du moins, pas à 100% (ce qui n'est jamais atteignable évidemment). On est plutôt sur un solide 80% par exemple.
Si on travaille seul, ou que le projet n'est pas nécessairement complexe, et qu'un bug n'est pas susceptible d'impacter énormément d'utilisateurs, ces 80% peuvent suffire !
Quid d'une application avec beaucoup d'écrans ? Des dizaines de développeurs travaillant dessus en trunk-based development ?
Les choses peuvent vite mal tourner. Une modification d'un CSS à endroit qui cascade des effets négatifs à un autre, obstruant par exemple un élément cliquable, et bim c'est toute une fonctionnalité qui n'est pas disponible. Alors que tous nos tests sont au vert. C'est ballot.
Que faire alors ?
Celles et ceux qui suivent ma formation savent que j'adore créer des DSL pour rédiger mes tests de façon lisible, et pouvoir écrire les nouveaux très facilement, un peu comme on empilerait des Legos.
L'avantage de cette DSL, c'est qu'on peut l'utiliser aussi pour rédiger des tests Cypress.
Il y a donc une implémentation de la DSL purement en mémoire, pour piloter le code très rapidement grâce au TDD.
Et il y a une implémentation Cypress, pour que la même suite de tests s'exécute cette fois dans Cypress :) (en implémentant par exemple qu'un simple happy path et wrong path).
De fait, on peut lancer dans notre pipeline la première suite de tests pour avoir une confiance d'environ 80% en moins de 5 minutes, puis exécuter la seconde dans une étape "d'acceptation", qui elle peut prendre un peu plus longtemps :)
Je montrerai tout ça dans un futur module du cursus Craft Academy :)
Happy Coding !
PS : Ce sont les derniers jours pour profiter des soldes sur https://craftacademy.fr ! Jusqu'à -60% :)