Third-party API integrations are an essential part of almost every application. While they are constantly being updated, we want to be able to keep up with them without the need to manually check everything after updates. Below, we described how we introduced VCR tests on one of our projects to solve this problem.
One of our current projects is a large fintech app. No wonder it has a lot of payment integrations (Stripe, AeroPay, etc.). These integrations are usually SDKs (Stripe) or simple APIs (AeroPay). The problem was that these SDKs and APIs were constantly being updated, often leading to breaking changes. Payments and money transfers are the most important part of such kind of application. Therefore, we wanted to automate the testing of those integrations somehow.
READ A CASE STUDY ABOUT IT: Software for Legal Fintech Startup
Testing options that already existed on the project were not suitable for this task.
Regular unit tests would not help at all. SDKs and APIs are always mocked in unit tests for well-known reasons – otherwise, the CI would sometimes randomly fail, the tests would not work without an internet connection, etc. If the responses are mocked, you cannot check whether the integration works or not.
Another option is E2E (End-to-End) tests written by the QA team, but they take a long time to write, developers are not contributing to writing them, and are not able to run them locally. Therefore, E2E tests could help catch something just before a release, but identifying a problem at this stage of the game would be too late.
That’s when the idea to bring VCR tests to the project came up. We did the SPIKE and POС, and it was decided to start integrating them.
The essence of VCR is that we allow the test to make a real request using the SDK or API and get a real response. VCR records this real third-party response in a YAML file called “cassette”.
Next time this test is run, it will no longer make a real request but mock it using this cassette. From that time the test works like regular unit (or request) tests, but with a real third-party response, not the one we usually mock manually.
When you need to check the real SDK or API again, you just delete all these cassettes and let the tests make real requests again. VCR will write new cassettes, and then the tests will be mocked again using them.
The setup using VCR gem is as simple as this:
It didn’t take long to see the benefits. At that time, we had a 5-point ticket to update Stripe to the latest version and check everything manually. Normally, a task like that could take up to a week or longer, but after we integrated VCR and wrote VCR tests for all flows, the Stripe version was updated in half a day (!), and all the tests were checked by the CI. In other words, what was once a 5-point task could now be completed in a half-day task.
Now we’re able to update all third-party SDKs and APIs with every new version because their functionality testing is automated. It took some time to set everything up and update existing tests, but now it is as simple to write a VCR as to write a regular test, and the benefits of VCR tests are significantly greater.
Check out our newsletter
© 2024 Red Panda Technology (dba datarockets). All Rights Reserved.
