Dans le
dernier texte sur les affirmations , quelque chose d'important manquait et n'était pas accepté.
Quelle est la différence entre donné et quand et comment est-ce lié aux affirmations?
L'idée sous-jacente est simple - nous voulons limiter le nombre d'assertions.
Prenons un petit exemple.
Passons un objet valide dans la méthode, appelons le service supplémentaire et enrichissons ses propriétés.
Je n'ai pas à écrire de code avant le test, nous supposerons donc que ce n'est que pour donner une vue d'ensemble.
public User enrichUser(User validUser){ user.setDetails(enrichmentService.getUserDetails(validUser.getId())); return user; }
Nous ne sommes pas intéressés par les variations valides de l'utilisateur. Il n'est pas nul, il a toujours un identifiant, alors il est valide. C'est une condition préalable, c'est-à-dire donné.
En fait, nous devons considérer deux conditions: l'échec de enrichmentService et le succès. C'est une condition, c'est-à-dire quand.
Comment distinguer l'un de l'autre?
Étant donné ne nécessite pas de vérification d'autres cas, lorsque - l'exige. C'est-à-dire whenValidUser nécessite whenInvalidUser, et givenValidUser non.
Et enrichmentservice == null? Si nous avons injecté une dépendance, alors nous pouvons considérer cette partie de la configuration et ne pas y penser dans les tests. Absolument. Il y a des conditions préalables qu'il n'est pas logique d'énumérer.
Si la méthode accepte uniquement l'utilisateur, le nombre de scripts vérifiés augmente. Le donné devient quand.
Une autre question - mais, à proprement parler, par accident ou intentionnellement, une méthode peut ruiner un utilisateur pour nous? Ne devrions-nous pas le vérifier?
Si nous répondons - oui, nous devons, nous devons admettre que cela peut être un lourd fardeau. Un utilisateur peut avoir cinquante propriétés et les vérifier dans chaque méthode peut être coûteux. Il y a des vérifications en masse à l'aide de bibliothèques, mais en faisant cela, nous perdons la fonction importante du test - prescrire la fonctionnalité souhaitée, et ne pas ramasser la saleté derrière la courbe d'implémentation.
Cela peut être comparé à la sécurité de l'aéroport - quelqu'un vérifie le billet, les bagages de quelqu'un, les poches de quelqu'un et les chèques ne sont pas dupliqués à chaque étape. C'est-à-dire Les actifs font confiance à ce que l'implémentation fera et ne vérifient que ce qu'ils prescrivent.
Ainsi, une condition préalable correctement construite réduit le nombre de scripts et d'assertions. Nous ne faisons des affirmations qu'à condition.
Malheureusement, les cadres comme Cucumber ne font pas beaucoup de différence, car les conditions préalables elles-mêmes ne vérifient pas pour eux que Given, que When est le même terme purement descriptif.
Dans les cas plus complexes, il est difficile de distinguer l'un de l'autre, qui en lui-même sent. Par exemple, de nombreux tests consécutifs vérifient la même chose, ou certaines des conditions des tests sont oubliées ou ignorées comme inappropriées.
C'est une bonne raison de restructurer les spécifications et de les repenser.