Why Are Financial Organizations Embracing API Contract Testing?
Financial services extensively use both internal and external APIs. For example, a fintech startup might use open banking APIs to initiate funds transfers or monitor transactions. Or, a bank may have internal microservices, web applications, and mobile applications that use APIs to communicate. And in both cases, failure is not an option.
Let's take a closer look at why you should use contract testing over integration tests, how Pactflow's bi-directional support makes contract testing scalable, and success stories in the financial services industry.
API contract testing eliminates many problems with integration and E2E tests, making it easier to ensure a robust experience for internal and external API consumers.
Why API Contract Testing?
Many financial organizations use integration tests to validate that microservices, web applications, and mobile applications can communicate. While there are several integration tests, the most common are end-to-end tests (E2E) that involve deploying everything in a production-like environment and running a battery of test scenarios against it.
Unfortunately, integration tests are notoriously slow and hard to maintain. For example, test engineers must ensure that every system is in the correct state before running any tests. Even worse, debugging failed tests in distributed and remote systems can be nearly impossible. And finally, these problems tend to compound at scale.
Contract testing solves these problems by capturing interactions between two services and storing them in a contract. While similar to schema testing and other methodologies, contract testing doesn't require both parties to reach a consensus. Instead, you can test each system on its own, and automation ensures that the contract is up to date.
How Pact Can Help
Pact is a code-first consumer-driven contract testing tool that requires access to code on both sides of an integration point. A consumer writes a unit test that can manipulate the state on the provider's server. That way, consumers can ensure that their apps work with a provider's infrastructure well before reaching the final stages of E2E testing.
- The consumer unit tests its behavior against provider mock
- A contract that documents required interactions between the systems.
- The contract is shared among teams to enable collaboration.
- Requests in the contract are replayed against the provider API and verified against the consumer expectations.
- The provider tests mock out any other systems to test them in isolation.
Unlike provider-driven contract testing tools, Pact contracts are generated during the execution of automated consumer tests. As a result, the test only covers the parts of an API that consumers actually use, and the tests automatically evolve over time. There’s no need to keep a static contract testing specification up to date to be effective.
Adding Bi-Directional Support
Pactflow, a contract testing tool that extends the capabilities of Pact, supports bi-directional contracts providing even more flexibility. The tool allows consumers and providers to publish their own versions of an integration. Then, they can use cross-contract verification to ensure that they're compatible with each other.
Cross-contract validation workflow in Pactflow. Source: Pactflow
By decoupling provider and consumer contracts, bi-directional support enables consumers to make changes and instantly determine if they're okay to deploy. At the same time, providers don't have to worry about managing provider states or maintaining a lot of examples. Distributed teams, multiple services, and various integration points are no problem!
Pactflow provides several other capabilities designed to support teams and enterprises to start and scale their contract testing initiatives, such as teams and role-based access, secure authentication and audit trails. It also provides hosted stubs for simplified local development, pull request status checks, webhooks, testing insights, encrypted secrets, and support for Terraform to avoid configuration drift and ensure CI/CD pipelines run smoothly.
Working with OpenAPI Specs
Pactflow's bi-directional contract testing also works hand-in-hand with OpenAPI – an API specification and documentation tool. In fact, many API test suites begin as schema-based tests using OAS other protocols. The need for contract testing tends to arise over time as organizations deal with larger systems and greater levels of complexity.
Of course, SwaggerHub/OAS also comes with a lot of other benefits beyond tests. For instance, API mocking tools make it easy to virtualize operations without any code; SDK generation tools help create up-to-date libraries for developers; style validators help ensure consistency across your APIs from a developer's IDE.
Customer Success Stories
Many large financial service organizations are leveraging contract testing to ensure the stability of their APIs.
M1 Finance, a Chicago-based personal finance app with hundreds of thousands of users, had robust backend tests, but its frontend API gateway had a few integration and E2E tests. In addition, while TypeScript and GraphQL provided some level of safety, they didn't have a robust set of test automation tools to ensure stability.
By adopting contract testing with Pactflow, the company has improved communication and collaboration between engineering and product and eliminated time-consuming manual testing processes. The process took less than six months, from proof of concept with OSS Pact Broker to bringing key stakeholders into the fold, thanks to Pactflow's streamlined complete contract testing capabilities.
Mastercard's Loyalty Rewards applications also extensively use Pact's contract testing capabilities. The apps rely on REST APIs to configure rebate promotions that cardholders can use depending on their credit card. Of course, any unexpected change to the REST APIs could potentially break the app, creating a significant risk.
The company implemented Pact contracts into their continuous integration and deployment (CI/CD) processes to generate contracts and publish them to a broker to make available to the provider. Providers would then retrieve the contracts and run automated contract tests against them as part of their own CI/CD pipelines.
The Bottom Line
Contract testing can eliminate many of the most problematic aspects of integration and E2E testing for APIs by giving a developer fast and reliable feedback on the API endpoints early in the software development lifecycle. By establishing a contract between consumers and providers, both parties can minimize the risk of API specification changes or other issues causing crashes or disruptions. And if there is a problem, they can address it earlier in the development process where it is faster and simpler to resolve.
Try Pactflow for free and see how easy it is to level up your API tests and minimize the risk of problems reaching production users.