La prochaine étape, après avoir fait le processus de BDD, c'est de passer à l'étape TDD : "test-driven development" !
Le TDD est l'étape suivante naturelle pour fermer la boucle de BDD que vous avez commencé dans le dernier chapitre.
Voici comment les deux fonctionnent ensemble. Vous allez :
Identifier des comportements ("behaviors" en anglais) avec BDD.
Écrire des tests pour ces comportements avec TDD.
La bonne nouvelle, c'est que vous vous êtes déjà rendu la vie plus facile parce que vous avez formulé les comportements qu'il faut coder pendant la phase de "behavior-driven development".
En TDD, vous allez écrire les solutions les plus basiques possibles pour faire passer vos tests. Une fois que vous avez écrit un bon test avec le code le plus simple possible, vous avez fini -- et vous pouvez avancer au prochain test.
Il y a trois règles de BDD à respecter, selon Robert Martin (un leader dans le monde de TDD) :
Vous devez écrire un test qui échoue avant d'écrire votre code lui-même.
Vous ne devez pas écrire un test plus compliqué que nécessaire.
Vous ne devez pas écrire plus de code que nécessaire, juste assez pour faire passer le test qui échoue.
Ces 3 règles fonctionnent ensemble et font partie d'un processus qui s'appelle le cycle rouge-vert-refactor ("red-green-refactor" en anglais).
Le cycle Rouge-vert-refactor
Le cycle rouge-vert-refactor vous guidera dans l'écriture de vos tests. Voyons d'où vient son nom.
Rouge : Vous écrivez un test simple qui échouera avant même d'avoir du code qui l'accompagne. Le test échoue, évidemment, sans le code. Du coup, le test est rouge.
Vert : Vous écrivez le code le plus simple possible pour faire passer le test, même si le code est un peu ridicule ou simplifié. Le test réussit, il est donc vert.
Refactor : le code que vous avez écrit pour faire passer le test est peut être illogique ou trop simple. Il faut faire un refactor de ce code maintenant si possible.
Écrivez votre premier test qui échoue
Si on reprend l'exemple du chapitre précédent qui parle de la longueur des commentaires, le premier test que vous écrirez confirmera qu'un commentaire de plus de 1000 caractères donne une erreur.
Un test pour ce scénario peut ressembler à celui là :
describe("Saving a comment", function() {
it("should throw an error if the comment is over 1000 characters", function() {
comment.length = 1200;
expect(function() {
comment.save();
}).toThrowError("comment is too long");
});
});Dans cet exemple, nous :
décrivons la fonctionnalité,
identifions comment elle doit se comporter,
fixons un longueur de 1200 caractères comme situation théorique,
disons que le commentaire ne doit pas être sauvegardé parce qu'il est trop long.
Prochainement, vous allez jouer le test et espérer qu'il échoue. Gardez en tête quand même que c'est juste le test. Le test va échouer parce qu'il n'y a pas de code associé avec !
Afin de faire passer le test, vous allez écrire le code qui l'accompagne dans un autre fichier qui évaluera la longueur du commentaire et renverra une erreur (ou pas).
D'une manière ou d'une autre, ce code vérifiera probablement que comment.length < 1000 (la longueur du commentaire est inférieure à 1000 caractères).
Une fois que vous avez écrit le code qui fait réussir le test, vous pouvez passer au prochain test et au prochain bout de code.
Allez de moins spécifique à plus spécifique
Vos tests deviendront de plus en plus spécifiques lorsque vous les rédigerez pour des scénarios plus spécifiques. Ironiquement, cela signifie que votre code deviendra de plus en plus général, parce que vous l'écrivez pour accueillir plus de situations.
Si vous regardez l'exemple précédent, vous pouvez également tester que les commentaires qui font exactement 1000 caractères sont sauvegardés correctement. C'est une modification qui généraliserait votre code pour mieux gérer plus de situations.
Si vous passez un commentaire avec une longueur de 1000 caractères à votre test actuel, le test échouera, parce que vous avez défini qu'un commentaire doit faire moins de 1000 caractères. 999 caracatères marcheraient, mais 1000 caractères ne marcheraient pas.
Vous pouvez donc mettre à jour votre code pour confirmer que comment.length ≤ 1000 (la longueur du commentaire est inférieure ou égale à 1000 caractères), rejouer le test, voir qu'il marche, et avancer au prochain test ! 😎
Résumé : BDD et TDD ensemble
BDD
Pour faire un petit recap, la première étape dans votre processus de testing, c'est de détailler les comportements que vous attendez d'une certaine fonctionnalité.
Détaillez ces comportements en utilisant des mots clés BDD comme Étant donné, Quand, Alors, et Et (Given, When, Then, And). Laissez ces comportements attendus guider le processus d'écriture du code.
TDD
Prochainment, vous écrirez des tests pour les comportements que vous avez définis à l'étape précédente. Les tests que vous écrivez au début échoueront certainement parce que vous n'avez pas encore écrit le code pour la fonctionnalité que vous testez !
Vous écrivez un test, et ce test échoue. Vous écrivez du code ailleurs dans votre base de code pour faire passer le test, et après vous avez fini ce test.
Il est maintenant l'heure d'appliquer ces méthodologies aux tests frontend !
