Dois-je tester toutes les valeurs d'énumération dans un contrat?

Question

J'ai un doute quant à savoir si je devrais considérer un certain type de test fonctionnel ou contrat.

Disons que j'ai une API comme/getToolType, qui accepte un {objet » "myObject"} en entrée, et retourne au type dans la forme {type: "[az] +"}

Il a été convenu entre le client et le serveur que les types retournés correspondent à un ensemble de chaînes, disons [marteau | couteau | tournevis], de sorte que le consommateur a décidé de les analyser dans une énumération, avec une valeur de repli quand le type retourné est inconnu. Si le consommateur doit inclure un test pour chaque type (marteau, couteau, tournevis) pour s'assurer que le producteur respecte toujours l'accord qu'il retournera toujours, par exemple, la chaîne en minuscules "marteau" quand/getToolType est appelée avec un marter obj ect? Ou considérez-vous qu'un tel test est fonctionnel? Et pourquoi?

Answer 1

Bonne question. Réponse courte: il n'y a pas de bonne ou de mauvaise façon, juste comment vous voulez le faire.

Deuxième réponse:

Le point de pacte (et les tests de contrat) est de tester des scénarios spécifiques et faire en sorte qu'ils correspondent. Vous pouvez simplement, dans votre contrat, créer une regex qui permet n'importe quel type de chaîne pour ces énumérations, ou peut-être null, mais seulement si votre consommateur ne se soucie pas de cette valeur. Par exemple, si le type d'outil avait une marque, je ne m'intéresserais pas à la marque, juste qu'elle est retournée sous la forme d'une chaîne puisque je viens d'afficher la marque verbatim sur le consommateur (front-end). Cependant, si cela ne tenait qu'à moi, d'après ce que je comprends de votre scénario, il semble que le type d'outil est vraiment important compte tenu du point de contact, donc j'aurais probablement des tests spécifiques et des contrats pour chaque énumération. assurez-vous que ces scénarios particuliers sur mon client sont valables (j'appelle X avec quelque chose et j'attends que Y ait le type d'outil Z).

Ces deux solutions sont valides, ce qui revient à dire: Pensez-vous que le type d'outil spécifique est important pour le consommateur? Si c'est le cas, créez des contrats spécifiques, sinon, créez simplement un contrat générique.

Espérons que ça aide.

Answer 2

IMO la réponse courte est 'non'.

Test de contrat est plus intéressé par la structure, si nous commençons à tester les limites de l'API nous passons en territoire de test fonctionnel [1], ce qui est mieux fait dans la base de code du fournisseur. Vous pouvez utiliser un comparateur pour garantir qu'une seule de ces trois valeurs est renvoyée, ce qui devrait garantir que la construction du fournisseur ne peut pas renvoyer d'autres valeurs.

Je ferais écho aux commentaires @ J_A_X - il n'y a pas de bonne ou de mauvaise réponse, juste méfiez-vous de tester toutes les permutations de données d'entrée/sortie.

[1] https://docs.pact.io/best_practices/contract_tests_not_functional_tests.html