As a front end engineer like me, you may find that end-to-end tests might not give you the confidence you need. The team and I at Pactflow are no strangers to this and have seen such disastrous tales in the past.
In this blog, I am going to introduce you to a new way to test your user interface—resulting in more confidence to deploy, less time maintaining test suites and less time scratching your heading when figuring out unknown errors—an improved way to use contract testing along with your end-to-end UI tests.
We’re always exploring ways to make testing easier—in 2020 we launched hosted stubs enabling you to start contract testing within Cypress; now with Pact Cypress Adapter you can get the extra layer easily using existing mocks you’ve created with Cypress.
The current state: how most UIs are tested
One of the most common ways to test UIs is using end-to-end tests. A UI end-to-end test tests the functionality and performance of the application through an end-to-end user journey, making sure the user interface behaves as expected.
But, how many times have you:
- Not having the confidence to deploy a new feature because of not trusting current testing processes?
- Seemingly wasting time on unreliable end-to-end tests?
- Not being able to move as quickly as you (or the business) would like?
- Write duplicated tests?
- Experience difficulties to debug failed end-to-end tests?
A potential solution: can contract testing be used in UI tests?
For some time, there’s been a lot of discussion about whether contract testing is a technique that can be used for UI testing. Specifically, over in the Pact OSS community, frontend developers and QAs had asked the question time and time again. A lesson learned the hard way, we currently advise that contract testing with Pact isn’t a good fit for UI testing.
Re-imagining contract testing for UIs—how to use your favourite existing tools such as Cypress
The main barriers to using contract testing for UIs are the flakiness in browser environments and the high cost of maintaining, debugging and executing.
Pactflow’s latest game-changing feature— Bi-Directional Contract Testing—is an avenue to overcome this, not locking developers and QAs alike into generating consumer contracts with Pact only. The new reality is that you can now use your favourite, existing tools for aspects of contract testing. For example, Cypress.
Cypress is one of my favourite UI test libraries that runs in browser environments for end-to-end UI tests. The library itself comes with handy features and accessible APIs that enables developers and QAs to write tests and debug their UIs with less worry about deployments.
I bet you’re now wondering “wouldn’t it be great if the ease of Cypress’ setup could be combined with the reliability and power contract testing?”.
We echo that sentiment and indeed it is a popular topic—see one of our hottest roadmap tickets!
We’ll you’re in luck! We’ve listened to our community and have developed a Cypress adapter for Pact contract testing enabling developers and QAs to test the compatibility between consumers and providers whilst testing their end-to-end user experiences. This means less duplication of tests, more lean test stacks, and beautiful developer experiences.
How to use the Pact Cypress adapter
The new Pact Cypress Adaptor allows you to turn the Cypress networking stubs you’ve already created into a Pact file on the fly, all made possible by the Pactflow-exclusive Bi-Directional Contract Testing feature; therefore there’s no longer a need to write Pact tests from scratch—just repurpose your existing Cypress tests with the adapter to minimise the time it takes to get up and running with contract testing or scaling up your project.
Using the consumer Pact file generated from your Cypress test, Pactflow can complete cross-contract verification via a provider OpenAPI specification and prevent breaking changes before you deploy. It’s really that simple!
If you’re curious about starting contract testing with your Cypress tests visit our docs and Cypress consumer example project to learn more.
More ways to do contract testing
You’ll be pleased to know we’re exploring additional API specifications and adapters for tools you know and love to use in contract testing.
See our roadmap here and give an upvote for the adapters you fancy or post in the #pactflow channel in the Pact Slack workspace to begin a discussion.
