Salut,

j'ai écrit un microservice qui récupère des informations d'une API et qui calcule des prix en fonction de ces résultats et renvoit un json.
J'aimerai maintenant écrire des tests automatisés pour tester ce microservice.
Par exemple, calculer que dans mon json, le total est bien égal à la somme de mes éléments sous-totaux.

Dans ce cas-ci, je ne suis donc pas sensé mocker la réponse de l'api puisque je veux obtenir des vrais résultats et effectuer des calculs dessus.
S'agit-il d'un test unitaire ou d'un test d'intégration?

D'après ce que je lis à gauche et à droite, un test unitaire n'est pas sensé utiliser de service externe, mais la définition d'un test d'intégration ne correspond pas vraiment à ce que je veux faire...

Je cherche à savoir ça pour savoir vers quels outils me tourner. Pour info, il s'agit d'un projet PHP avec le microframework Lumen, donc de base j'utilise phpunit, mais ne l'ayant jamais utilisé, je ne sais pas s'il est adapté à faire des tests sans mocker des api externes.

Merci!

un test unitaire n'est pas sensé utiliser de service externe

Si tu veux faire des "vrais" tests unitaires, c'est effectivement ce qu'il faut faire: définir le comportement de tous les appels externes, que ce soit pour des apis, mais aussi lors de l'appel de méthodes d'autres fichiers.

Exemple qui n'a aucun rapport avec ton problème pour illustrer mon propos avec des utilisateurs et historiques:
Dans un fichier user.php, on a une méthode updateUser(), qui appelle une méthode insertHistory() du fichier history.php.
Lorsque tu vas tester updateUser(), tu vas vérifier que tu as bien appelé la méthode insertHistory() avec les bon paramètres, pas qu'une nouvelle ligne a été ajoutée en base de données.
C'est d'ailleurs la même chose pour les insertions en base: tu dois vérifier que tu appelles la méthode d'insertion avec les bon paramètres, pas vérifier en base les données insérées.

Le concept de test d'intégration indique quant à lui, le fait de lancer une instance de ton service (ici ton microservice), et de vérifier qu'il a le comportement que tu souhaites (c'est plus compliqué à mettre en place). Tu testes ainsi ton service de bout en bout et pas seulement une portion de code: du point d'entrée s'il s'agit d'une api à l'insertion en base si le service en utilise une.

Je ne connais pas trop le php (j'ai quand même fait du test phpunit à une époque), ni comment est architecturé ton projet, mais je pense que phpunit peut être une solution à ton problème: tu n'es pas obligé de mocker les appels à l'api.
C'est en revanche risqué de ne pas le faire lorsque tu utilises un service externe: si pour un même appel à l'api, les résultats peuvent différer, il faudra toujours remettre à jour ton test car ton calcul final donnera forcément un résultat différent.

Donc pour moi, phpUnit si tu souhaites seulement tester tes calculs, ou un truc du style behat (à vérifier que c'est bien utilisé en php, je sais juste que son homologue cucumber en java l'est) si tu souhaites tester de bout en bout ton application.

Par exemple, calculer que dans mon json, le total est bien égal à la somme de mes éléments sous-totaux.

En soit pour faire ça tu n'a besoin que de tester qu'une petite portion de ton code, pas besoin de simuler un appel API etc...

Le test unitaire va tester chaque portion de code unitairement en isolant les comportements extérieurs au code testé. C'est nécessaire et ça garantit que ton code fait ce qu'il est censé faire.

Le test d'intégration va permettre de tester ton programme sur un scénario donné, en lançant ton application (voire sur un serveur léger) et si possible en isolant les API externes via des stubs + démarrage de bases de données embarquées pour le test.
En java on a wiremock qui fait très bien l'affaire pour stuber (on peut capturer/renvoyer des réponses), j'imagine qu'il existe quelque chose de similaire en PHP. C'est typiquement le genre de test que tu veux faire... mais ça ne remplace pas les unit tests, c'est complémentaire.

Ensuite il y a les tests d'intégration, qui vont tester toute la chaîne sans stub. Ca permet de faire de la non reg et de tester que tout s'intègre parfaitement bien. Bien que je ne sois pas très fan de ce genre de test car ils dépendent de l'environnement sur lequel ils s'exécutent, et ne testent en réalité pas une API mais un SI.