Testing Third-Party payment services

Hi everyone,

I have a question regarding testing third party service like CASHNet (payment processing solution for Higher Education). What is consider a good starting point (using VCR, creating a Fake, stubs and mocks) for this situation and how to test the callback when the results are returned.

So far, this service requires the application to generate a GET request where parameters are pass through the URL and after the user finishes payment, it returns the results back as a POST request.

Thanks for your help!

Hello @jeffects,

This post here in the forum might help: Suggestions for learning how to wrap external gems? - #2 by pedrosmmoreira - Testing - thoughtbot

Also, taking a look around the Learn source code on github is a good idea to see how thoughtbot implements fakes and the strategy pattern for talking to payment services.

Hope this helps :slight_smile:

1 Like

Unlike many at thoughtbot, Iā€™m actually not a fan of fakes. Itā€™s a ton of overhead to mock the API, and itā€™s too easy to get something wrong and discover it on Staging/Production. If the service is one that can be reset between test runs (e.g. Youā€™re scraping Google/Twitter/whatever, or itā€™s something like S3), I prefer to use VCR. Thereā€™s a couple of caveats to doing this effectively.

  • Set your cassettes to expire after a few days. I usually do 3. You want to hit the actual API at a reasonable frequency.
  • Add your cassettes to .gitignore. They exist only to make your tests run faster. You should be able to delete the entire directory and have your specs pass.
  • If integration with the service requires an API key, consider wrapping specs that hit the API in if ENV['FOO_API_KEY'].present?. If too many keys are required to run the test suite, it can be frustrating for new developers rolling onto the project.
  • The only things that should require VCR are the unit tests for the class that interacts directly with that API, and integration tests. Make sure you use a stub instead of the class that hits the service in unit tests for collaborating objects.

Always keep in mind that youā€™re attempting to test your real integration with the API. Do not think of VCR as a mocking service, and donā€™t try and use it as a replacement for Web Mocks. If you only use it as a helper to make your tests run faster and/or avoid hitting API limits, it can work beautifully.

For cases where you cannot reasonably reset or setup test data for an API, then itā€™s definitely worthwhile to look at setting up a fake or just using WebMock. In this case, however, Iā€™d look to see if CASHNet has a sandbox mode of some kind you can use in tests.

5 Likes

@pedromoreira @seangriffin thanks for the response!

I will look into VCR and I will see if it is a good alternative

1 Like