Skip to content

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

Open
mosesadewale wants to merge 2 commits into
gray-adeyi:mainfrom
mosesadewale:tests
Open

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
mosesadewale wants to merge 2 commits into
gray-adeyi:mainfrom
mosesadewale:tests

Conversation

@mosesadewale

Copy link
Copy Markdown
Contributor

Changes

  • Add mocked tests for KorapayClient behavior
  • Add RestClient coverage for auth routing, payload transformation, error wrapping, and encryption
  • Move live Korapay checks into a separate opt-in test file
  • Add Deno tasks for:
    • test
    • test:live

How to run

  • deno task test for the default mocked suite
  • deno task test:live for live Korapay checks

Notes

  • Live tests are gated behind KORAPAY_LIVE_TESTS=1
  • Live tests require .env and Korapay credentials

@gray-adeyi

Copy link
Copy Markdown
Owner

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

@mosesadewale

Copy link
Copy Markdown
Contributor Author

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants