Replace the old live-default test setup with a mocked unit suite and keep the live Korapay checks as an opt-in integration suite.#3
Conversation
|
Hi @mosesadewale . I'd have to close this, not because it is bad, but because I don't want to maintain that many tests ATM, yeah it's a good idea to have as many tests as possible, but I have a project that's similar to this project, and I went overboard with mock tests, it's just much tests. I've also come across a school of thought that thinks mocking is a bad idea. This does not necessarily make it true. But the rationale is that the core is pretty much the same, that can be tested, but if there and issue with any of the client methods, it's probably an issue with the parameters, the method or the url. So mocking the API calls just doesn't offer any advantage. So it's just better to stick with live testing. I don't know if that makes any sense |
|
Hi @gray-adeyi , Thanks for the explanation. I understand the concern around maintaining additional tests. My thinking was that the mocked tests are less about re-testing the API and more about verifying core SDK behaviour (request routing, auth selection, payload transformation, encryption, error handling, etc.) without depending on a live environment. I also had CI in mind, since running tests against a live payment API on every PR can be costly and less reliable. That said, I'm not attached to exhaustive coverage. If the concern is the scope of the tests, I'd be happy to reduce or restructure them and focus only on the core SDK behaviours that provide the most value. Would that be a compromise you'd be open to? |
Changes
KorapayClientbehaviorRestClientcoverage for auth routing, payload transformation, error wrapping, and encryptiontesttest:liveHow to run
deno task testfor the default mocked suitedeno task test:livefor live Korapay checksNotes
KORAPAY_LIVE_TESTS=1.envand Korapay credentials