Les tests tautologiques sont parfois appelés tests trop étroitement liés à l'implémentation sous-jacente, la répétant littéralement étape par étape. Ils sont régulièrement réprimandés et, en général, semble-t-il, les développeurs sont capables de les éviter et de les reconnaître. Sous la pression de la direction, ces tests se produisent parfois rétroactivement pour tenter de rattraper la couverture.
Cependant, il existe des cas complexes.
- Le premier cas est celui des tests qui reproduisent le comportement des bibliothèques. Un cas typique est un client http d'une bibliothèque où vous devez créer un client, y insérer des cookies et des en-têtes et envoyer une demande. Il n'y a aucun intérêt à tester chaque étape, il peut toujours y avoir des méthodes statiques, de nouveaux et d'autres tueurs de test-killers, donc le moyen le plus simple est de l'envelopper dans une classe wrapper mince. Les tests unitaires ne sont pas nécessaires pour une telle classe. Vous pouvez tester cette classe dans le contexte des tests de dépendance d'intégration, c'est-à-dire que nous l'appelons par rapport à un service réel et nous assurons que la bibliothèque fonctionne comme prévu. Il est important que la classe wrapper ne contienne pas de logique supplémentaire pouvant être testée dans le cadre du test unitaire.
- Le deuxième cas est celui des tests qui vérifient quelque chose qui ne retourne pas de résultat (ou renvoie un flou), respectivement, la seule façon de vérifier que quelque chose a été appelé est Spy avec un compteur. Il s'agit d'un cas valable, quoique limité. Cela peut inclure des procédures stockées invoquées, l'envoi d'e-mails.
- Le troisième cas est celui des tests de stratégies, de politiques et d'autres modèles de comportement. Par exemple, lorsque nous créons une commande, nous voulons obtenir une entrée dans la base de données, puis il apparaît sur la ligne de commande, puis quelque chose est écrit dans les journaux et les e-mails.
Il est important de comprendre que notre test dans ce cas est une spécification d'une règle, un comportement. Autrement dit, il prescrit dans quel ordre les composants sont tirés, non pas parce qu'il les suit, mais parce qu'il les suit. En ce sens, il est logique de l'écrire de manière plus abstraite: par exemple, si vous avez besoin d'appeler plusieurs services - de toute façon, en parallèle ou séquentiellement, le test devrait décrire exactement cela. Si des tests sont lancés par des objets, alors il ne devrait probablement pas enfoncer son nez dans les champs de cet objet. Par conséquent, notre test peut ressembler presque à une implémentation, ou à l'implémentation la plus simple et la plus naïve de certains comportements, mais en même temps connaître la mesure en détail et ne pas être une tautologie.
Parfois, cependant, ces cas se rejoignent. C'est-à-dire nous pouvons avoir plusieurs appels à des bibliothèques héritées qui ne renvoient pas vraiment quoi que ce soit, ou échangent de manière incompréhensible avec ce qui, dans l'ordre, n'est pas connu par quelqu'un qui a été établi, et il n'est pas très clair qui "prescrit" le comportement à qui. Le tester, c'est comme expliquer un itinéraire à un chauffeur de bus, il est donc préférable de suivre le premier scénario.