Comment testeriez-vous une fonction qui appelle une API de paiement tierce ?

Isolez la frontière. Placez l'appel HTTP derrière un client léger, puis dans les tests remplacez-le par un faux objet ou patchez-le là où il est utilisé, pas là où il est défini. Utilisez les fixtures pytest pour la préparation et parametrize pour les cas succès, échec et timeout. Ajoutez un petit ensemble de tests de contrat contre le vrai bac à sable pour que les mocks ne dérivent pas.

La testabilité est d'abord une question de conception. Si l'appel de paiement est enfoui dans la logique métier, je l'extrais dans une classe client avec deux ou trois méthodes, et la logique prend ensuite ce client en argument. À partir de là, la plupart des tests n'ont besoin d'aucune bibliothèque de mocks, parce que je passe un petit faux client qui renvoie des réponses préparées, plus lisible qu'un empilement de décorateurs patch. Là où je patche vraiment, je patche le nom dans le module testé, pas dans le module de la bibliothèque, parce que patcher là où c'est défini ne fait rien une fois que le nom a été importé ailleurs. Les fixtures construisent les objets, et parametrize couvre les cas intéressants : accepté, refusé, timeout, et une charge utile malformée, puisque ce sont les branches d'échec qui cassent en production. Je garde aussi une poignée de tests contre le bac à sable du fournisseur, marqués pour tourner la nuit plutôt qu'à chaque commit. Cela a attrapé un changement où le fournisseur s'est mis à renvoyer un code d'erreur que nous n'avions jamais mocké.