La rédaction de spécifications - assertions ou hypothèses de test - est généralement contournée dans les cours TDD car il y a peu de programmation.
Cependant, ils sont très importants.
Ils déterminent comment et quels tests seront écrits, et déterminent également la facilité avec laquelle il sera possible de corriger la panne. Ils ne nécessitent presque pas de temps pour la mise en œuvre. Ce sont les premiers qui connectent l'utilisateur de l'histoire et du code et le premier qui montre l'échec du code de test. Ils nous protègent également contre les erreurs dans le code du test lui-même.
Comment pourrions-nous améliorer nos déclarations?
Premièrement, les
spécifications doivent être liées à l'histoire de l'utilisateur en termes . Si l'utilisateur de l'article utilise le terme «se connecter», assert ne peut pas modifier ce terme pour authentifier / autoriser / valider. Si l'histoire n'est pas bien écrite, changez-la.
Deuxièmement, la
spécification doit contenir explicitement le nom du composant qu'ils décrivent. Cela indique la zone de test et signale une erreur, si soudain le balbuzard pêcheur comprend souvent des composants inattendus.
Le script valide est bien combiné avec le principe de la responsabilité unique, le nom du composant doit donc correspondre à la description du test. S'il existe de nombreux scénarios valides, le composant a probablement trop de responsabilités.
En outre, un scénario, en règle générale, décrit un événement ui ou une sorte de modèle. Les bons candidats pour le nom du composant peuvent contenir le nom du modèle: validateur, stratégie, constructeur, transformateur, contrôleur, etc. Ou nom de l'événement: Soumetteur, Login, ReadonlyOrderView, etc. C'est-à-dire selon le nom du composant, les valeurs d'entrée et de sortie de la fonction principale de la classe doivent être définies. Mauvais noms: trop abstraits (Service, Component, Helper, Utility) et doubles (ValidatorAndRenderer).
Troisièmement, les
spécifications doivent énoncer explicitement les conditions .
Mauvais:
@Test public void testValidatePassword(){}
Mieux:
@Test public void loginController_whenValidUsername_andValidPassword_shouldLogUserIn(){}
Nous n'avons pas besoin d'appeler cette fonction depuis un autre endroit, donc les noms extra-longs sont valides. Si le nombre de conditions dans le test ne tient pas sur la ligne, alors vous devriez peut-être changer la structure du composant.
Pour les tests javascript, c'est la même chose, mais vous pouvez y mettre des conditions, cela s'avère plus pratique.
describe('login UI component', () => { describe('when username provided', () => { describe('when valid password', () => { it('should log user in', () => { ... }); }); }); });
Les conditions explicites sont plus faciles à lire et à
trouver manquantes .
En outre, si la condition ne correspond pas au code de test écrit, le code est facile à corriger.
Une bonne description est, en général, un remplacement pour la documentation et les commentaires de code. Il est abstrait, il ne dépend pas du framework et du compilateur, et il doit être traité avec le même sérieux que les deux derniers.
Les conditions elles-mêmes doivent être cohérentes dans le code pour une lecture facile, par exemple GIVEN-WHEN-THEN-SHOULD, etc.
Quatrièmement, les
spécifications devraient être rationalisées . Il est utile de les écrire dans l'ordre inverse:
Erreurs en premier, null en premier, chemin heureux en dernier. Ensuite, il n'y a aucun désir de terminer les tests après un cas d'utilisateur valide. Pour les composants de l'interface utilisateur: rendu, événements. Pour les composants avec état, tous les états sont cohérents.
Ainsi, la structure d'une bonne spécification lisible ressemble à ceci: 5-10 erroné, un script valide (ou plusieurs variantes d'un script)
Lors de la rédaction d'une spécification, il est recommandé de l'écrire entièrement sous forme de texte, puis de la donner à un collègue pour lecture pour plus de clarté et les conditions manquantes. Ensuite, en fait, vous pouvez déjà commencer à écrire l'implémentation. Très souvent, sous cette forme, la tâche est aliénée, c'est-à-dire eh bien, quand quelqu'un d'autre écrit l'implémentation du test.
Cinquièmement, la
mise en œuvre du test doit correspondre à ce qui est écrit dans décrivent .
Il est recommandé de diviser en organiser-agir-affirmer pour trouver facilement une correspondance pour l'une ou l'autre partie de l'implémentation. Le texte des assertions et des exceptions, s'il est présent, doit également être corrélé avec les descriptions de test, en règle générale, nous pouvons simplement les dupliquer.
Il va sans dire que lorsque vous ajoutez des conditions ou des assertions au test, vous devez également mettre à jour les descriptions du test.
Ainsi, la séquence d'écriture de la spécification peut être la suivante.
- lire l'histoire de l'utilisateur
- composant de nom et script valide
- formuler des conditions pour un scénario valide
- compléter la spécification avec des scripts erronés en les plaçant sur le dessus
- laissez le voisin lire et corriger les disparus
- implémenter les tests et les composants un par un à l'aide d'une boucle de refactorisation rouge-vert.