comment exprimer le résultat d'une action dans BDD/TDD

Le titre n'est probablement pas très clair. J'ai l'exemple suivant à l'esprit:comment exprimer le résultat d'une action dans BDD/TDD

Un objet Authenticator authentifie un utilisateur en utilisant des informations d'identification. Il retourne un objet AuthResult. Cet objet AuthResult indique que l'authentification a réussi, ou qu'elle a échoué (et si oui, pourquoi elle a échoué, par exemple, le nom d'utilisateur n'a pas été trouvé).

Comment puis-je exprimer cela dans un test? 'testShouldReturnAuthObjectWithStatusSuccessOnValidLogin'?

Source

2009-08-11 koen

testValidLoginIsSuccessful ou testIsSuccessfulOnValidLogin semble assez bon pour moi.

Pour les tests d'erreur, vous pouvez utiliser quelque chose comme testGetsCustomMessageOnUserNotFound

Vous devriez éviter de mettre les détails de mise en œuvre au nom de la méthode.

Source

2009-08-11 00:11:49

Entre Nous disons que l'Authenticator utilise d'autres classes avec des responsabilités spécifiées pour effectuer un certain travail (par exemple se connecter à une base de données). Si j'écris des tests pour ces classes, cela signifie-t-il que je donne des détails sur l'implémentation de 'complete-authentication-package'? – koen

Non, je parle juste du nom de la méthode. Et vous devriez probablement vous moquer de ces autres classes si vous voulez le tester unitaire. Ensuite, vous testez ces autres classes isolément et voyez si elles fonctionnent isolément –

Un 'package d'authentification complet' serait un test d'intégration. Vous testeriez si ces classes sont bien câblées et si le processus dans son ensemble fonctionne. Dans ce cas, il est encore plus recommandé que son nom ne soit pas spécifique à l'implémentation. –

Sans voir comment ces tests sont implémentés, il semble que les observations soient surchargées. Si ce test échoue, vous devrez creuser pour savoir si (a) aucun objet AuthResult n'a été retourné, ou (b) si l'état n'a pas été "réussi", et de plus, est-ce qu'il n'y a pas d'AuthResult? parce que l'authentificateur ne s'est jamais connecté à la base de données ou ne fait aucune autre action requise?

Je nommerai l'appareil When_told_to_authenticate_with_valid_credentials puis séparer les affirmations en deux observations différentes: 1.
should_return_an_AuthResult
2. should_be_successful

Si vous moquer des ces autres classes comme Samuel suggéré à juste titre, vous pouvez encore stipulent que le Authenticator se comporte comme prévu:
3. should_connect_to_the_database
4. etc.

Source

2009-08-13 04:45:49 Jay

Est-ce que should_return_an_AuthResult n'est pas un détail d'implémentation? – koen

Oui, il s'agit d'un détail d'implémentation. Je ne suis pas d'accord avec la prémisse que les détails de mise en œuvre ne doivent pas être inclus dans les noms des méthodes TEST, parce que (1) c'est précisément la mise en œuvre qui vous intéresse et qui sont testés (2) le nom de la méthode doit donc refléter exactement ce qui passe ou échoue, et (3) les assemblages de test ne sont pas publiés ou déployés. – Jay

Je ne suis pas d'accord avec le point 1. Si mon test confirme que ma méthode fonctionne correctement, je me fiche de la mise en œuvre. Et si mon test fait des suppositions sur la mise en œuvre, alors je peux rompre les tests si je décide plus tard de refactoriser la mise en œuvre. – JeffH

comment exprimer le résultat d'une action dans BDD/TDD

Répondre

Questions connexes