Wie würdest du eine Funktion testen, die eine Drittanbieter-Zahlungs-API aufruft?

Isolier die Grenze. Pack den HTTP-Aufruf hinter einen dünnen Client und ersetz ihn in Tests durch ein Fake oder patch ihn dort, wo er benutzt wird, nicht dort, wo er definiert ist. Nutz pytest-Fixtures fürs Setup und parametrize für Erfolg, Fehler und Timeout. Ergänze ein paar Contract-Tests gegen die echte Sandbox, damit die Mocks nicht wegdriften.

Testbarkeit ist zuerst eine Designfrage. Steckt der Zahlungsaufruf in der Geschäftslogik, ziehe ich ihn in eine Client-Klasse mit ein paar Methoden heraus, und die Logik nimmt diesen Client als Argument. Ab da brauchen die meisten Tests gar keine Mocking-Library, weil ich ein kleines Fake übergebe, das feste Antworten liefert, was sich leichter liest als ein Stapel patch-Decorators. Wo ich patche, patche ich den Namen im getesteten Modul, nicht im Library-Modul, denn dort zu patchen, wo er definiert ist, bringt nichts, sobald er anderswo importiert wurde. Fixtures bauen die Objekte, und parametrize deckt die interessanten Fälle ab: genehmigt, abgelehnt, Timeout und ein fehlerhafter Payload, denn die Fehlerzweige sind das, was in Produktion tatsächlich bricht. Ich halte außerdem eine Handvoll Tests gegen die Sandbox des Anbieters, getaggt, damit sie nachts laufen statt bei jedem Commit. Das hat eine Änderung gefangen, bei der der Anbieter plötzlich einen Fehlercode zurückgab, den wir nie gemockt hatten.