Aujourd’hui, j’aimerais vous démontrer que le TDD est applicable aussi pour driver l’implémentation de requêtes HTTP vers des apis externes, et le parsing de leur réponse. Évidemment, pour des soucis de vitesse d’exécution de test, et donc de qualité du feedback, je ne vais pas faire de vraies appels à l’API.
Merci, ce serait plus clair d'écrire dans cet ordre
assert
act
arrange.
Faire échouer un test>le faire passer>clean (c'est l'ordre chronologique)
De plus mais bon ça c'est selon les goûts. Personnellement je n'aime pas être dépendant de librairies extérieures si je peux facilement m'en passer. Et mocker soi-même les requêtes sans nock et axios est aussi possible. Mais bon c'est mon côté psychorigide peut-être.
Oui j'écris dans cet ordre justement :) Mais le déroulé du test se doit d'être dans le sens inverse, sinon ça n'a pas de sens.
Ici je suis dans le cas de l'implémentation d'un "adapter", donc je ne dois pas mocker car je veux justement tester que le protocole HTTP est respecté, en entrée (la requête), comme la sortie (le parsing de la réponse).
Merci, ce serait plus clair d'écrire dans cet ordre
assert
act
arrange.
Faire échouer un test>le faire passer>clean (c'est l'ordre chronologique)
De plus mais bon ça c'est selon les goûts. Personnellement je n'aime pas être dépendant de librairies extérieures si je peux facilement m'en passer. Et mocker soi-même les requêtes sans nock et axios est aussi possible. Mais bon c'est mon côté psychorigide peut-être.
Hello Laurent,
Oui j'écris dans cet ordre justement :) Mais le déroulé du test se doit d'être dans le sens inverse, sinon ça n'a pas de sens.
Ici je suis dans le cas de l'implémentation d'un "adapter", donc je ne dois pas mocker car je veux justement tester que le protocole HTTP est respecté, en entrée (la requête), comme la sortie (le parsing de la réponse).