From Good to Great: Elevate Testing with Cypress Contract Tests

Rate this content

Discover the power of Cypress Contract Tests, a cutting-edge approach that takes your testing to new heights. In this presentation, we'll explore the concept of contract testing and how it ensures seamless communication between microservices. Then, we'll delve into the game-changing capabilities of Cypress, showcasing its unmatched potential to elevate your testing practices from good to great. Join us for insights, best practices, and real-world examples on how to integrate Cypress Contract Tests into your existing workflows, and revolutionize your testing strategy.

19 min
11 Dec, 2023

AI Generated Video Summary

This Talk discusses the challenges of testing multiple services in a microservices architecture and introduces the use of Cypress and Pact to address these challenges. It explains how to use Cypress to write a contract and generate and share it with the provider. The verification process and CI workflow for the consumer and provider are also discussed. The Talk emphasizes the importance of contract testing to ensure seamless communication between microservices.

1. Introduction to Cypress and Kotra Test

Short description:

Hello, welcome to my presentation from good to great LWA testing with Cypress, Kotra Test. I'm Petros Plakogiannis, testing leader and test automation engineer at RAS Greece. Let's start with a simple REST API example. Microservices are large server projects that are broken down into smaller modules or components. The true challenge is to test all these services together under a specific testing environment as a traditional API testing. Different teams can deploy changes to different services at the same time, so the environment should have proper configuration and correct test data.

Hello, welcome to my presentation from good to great LWA testing with Cypress, Kotra Test. First of all, it's my honor to be part of TestJS Summit 2023, so thank you for the invitation. I'm Petros Plakogiannis, I have 15 years experience over testing. I am testing leader and test automation engineer at RAS Greece.

I have only 20 minutes, so I will try to give you as much as details I can for Cypress, Kotra Test. But first things first, why Kotra Test and what is Kotra Test? Let's start with a simple REST API example. On the left we have a web client that makes a call to the REST API in order to get some data. The REST API is the data provider, grabs data from the database and sends them back to the client. From a testing perspective, we can create API declaration tests and run them against a testing environment in order to verify that the client gets the correct data from the provider, from the API.

But can we apply this in microservices? Microservices are large server projects that are broken down into smaller modules or components. Different teams develop and maintain different services, and each service has its own database, its own code base, etc. The true challenge is to test all these services together under a specific testing environment as a traditional API testing. But can we do this? Think about it. Different teams can deploy changes to different services at the same time, or think that a service may be down because of server issues, of environment issues. So in order to test all these services under a specific environment, this environment should have proper configuration and correct test data. So it's not so easy.

2. Challenges of Testing Multiple Services

Short description:

If you have a hundred or thousand services, can you ensure that changing something in one service will not affect the others? The challenges arise when dealing with multiple services. Unit tests only validate internal logic and cannot guarantee real-world scenarios. Coda testing is a methodology for ensuring proper communication between services. It captures interactions and stores them in a contract, which is used to verify the services. Consumer and provider contracts specify expectations and capabilities. Contract testing involves writing tests, talking with a mock provider, recording expectations in the contract, and uploading it to the broker for the provider to fulfill.

Okay, if you have only two services, maybe you can do it. But what about if you have a hundred or thousand services like Amazon or Netflix? Can you ensure that if you change something in one service, you will not affect the other services? So the challenges are here.

And of course, we cannot use unit tests. Unit tests validate only the internal logic of the services. Think about how we can test a smoke detector. If we press the alarm button, we can hear the alarm sound. This is a unit test. But this alone doesn't guarantee that the smoke detector, the alarm, will be activated in the presence of actual smoke. And of course, we cannot set the house on fire to verify this. So what can we do?

Let's go back to our example. We can use a smoke producer to verify that the contact between the smoke detector and the condition designed to detect the smoke is upheld. While you are reading the definition of coda testing by Ian Robinson, the author of the resting practice book and the principal architect in Amazon Web Services, I will let you know that coda testing is a methodology for ensuring that two services can communicate properly and it captures the interactions that are exchanged between these two services and stores them in the contract. This contract can be used in order to verify these two services. Let's see the terminology. Consumer. Consumer is a service that consumes data from a provider. Provider is a service that provides data to a consumer. Consumer contract is a collection of interactions which describe how the consumer expects the provider to behave. Provider contract specifies the capability of the provider. It is like an OpenAPI document. A packed broker is a storage place. We store the contracts. We store the packed. How does contract testing work? So the consumer writes a test based on what it expects the provider to do. It talks with a mock provider, not a real provider. It talks with a mock provider created by a packed. We'll see later how. The test expectations are recorded in the contract. And the contract is uploaded by the consumer to the packed broker. The provider gets the contract from the packed broker and does what the consumer requested according to the contract.

3. Using Cypress to Write a Contract

Short description:

Packed checks if the provider matches the expectations recorded in the contract. Cypress is a JavaScript-based end-to-end testing framework with rich API and debugging features. A real-world example is given using the KeZer application and the Euclid database. The request is mocked using the intercept command of Cypress and the mock data is assigned to an alias. The mock data is then verified in the test. The next step is to convert the mock to a contract using the Pact Cypress Adapter plugin.

Packed then checks if the provider matches the expectations recorded in the contract by the consumer. If there is a match then two services are on the same page. If there is a mismatch there is an issue and we have to find why and solve it.

The role of Cypress. As you may know Cypress is a very famous JavaScript based end-to-end testing framework. It has a lot of features such as rich API, automated waiting, real-time reloading, time-traveled debugging. But the real question is how Cypress can be used to write a contract. We can convert easily a Cypress MOC to a consumer contract. How? Let's see a real-world example.

My company has a client that is called European Chemical Agency and we built an application that is called KeZer in order to generate a chemical safety report. In order to generate the chemical safety report we retrieve some data through an API from another application that is called Euclid. Euclid has some substances that we need to get in order to generate the report. Euclid is something like a database. Let's see an action. Here is KeZer. I'm going to log in. Here is Euclid. I have two substances, Bethustodianne and Eka substance demo. And if I click at Import Euclid Substances via Webservice and I enter the URL of Euclid and I click Search, I can view the two substances that I can import in my application. So I have and also if you go to Network, you can view the request and the response, that's the JSON file with two chemical names. So I have mocked out this request in my end-to-end test. How? Using the intercept command of Cypress and here is my mock data. A sample station. If you go to sample station, you can view my mock data with two chemical names test.jssummit1 and test.jssummit2. And this request is assigned to alias for future reference. So I do my test here and here, I'm waiting for the deception and then I verify that I can view the test.jssummit1 in my data table. So let's run this test in Cypress. Okay, so I have here that I have, instead of Petros 2.1 and Nekasubscites demo, the two subsites I have, my mock data, test.jssummit1 and test.jssummit2. So I want to convert this mock to a contract, to a pact. How can I do this? There's a plugin that's called Pact Cypress Adapter that I'm going to install.

4. Using Cypress to Generate and Share a Contract

Short description:

To install the plugin, run npm install and configure it in CypressConfig.js, the listener, and e2e.js. Use the setup-pact command to configure the consumer and provider names. Replace the wait command with use-pact wait to generate the contract. The contract is a JSON file that specifies the consumer and provider names, interactions, and metadata. Share the contract with the provider using a dedicated packed broker server or the packed CLI tool. Follow the instructions to publish the pack with the consumer version, broker URL, and token.

Okay, so you have to do npm install. In order to install the plugin, I have already installed it in my package.json. Here's the plugin, and I have already configured the plugin in CypressConfig.js, the listener, and e2e.js, the import command. And I'm going to use two commands, only two commands.

The first command is the setup-pact in order to configure the consumer and the provider name. So I'm going to my test and have used the setup-pact command. UIConsumer is my consumer, the case application, and the APIProvider is the provider, the EUCLID application. And then I'm going to use, instead of the wait command, I'm going to use the command use-pact wait. That I'm going to wait again for the interception, but this time I'm going to generate the contract. So let's run this test.

As you can see here, again I have the mock data, testjs summit1 and testjs summit2, but here in the test write file, I have created a contract. Let's go back to the project, to the packed folder. Here is the contract. As you can see, it's a JSON file that I have the consumer name, the provider name, a list of interactions which describe how the consumer expects the provider to behave. For example, I need to have status 200, the chemical names, testjs summit1, testjs summit2, and some metadata like the version of packed Cypress adapter, etc.

Now that I have created the contract, I have to share this file with a uklet team that they have a provider. There are various ways to share a contract, but of course the best way is to have a dedicated packed broker server. If you have this server, you can use the packed CLI tool that has been created by packed, the packed CLI tool, in order to publish and verify packs and direct Packed broker. Let's see. I have a packed broker. This is my packed broker, Here is a packed CLI tool. To publish and verify packs. That's a Docker image. You can pull a Docker image. I have the image here already in my Docker desktop for Windows. If you follow the instructions, you can publish the pack. Here I say publish. I give the consumer version, I give the broker-based URL, I give the broker token that you can find it if you go here, here, API tokens. So I'm going to run this command.

5. Verifying the Contract and CI Workflow

Short description:

The contract is reviewed, and the PACT interactions are examined. The provider verifies the contract either using a local file or by pulling it from the PACT broker. Creating a webhook is necessary, which can be done through the PACT CLI tool or the PACT broker UI. The verification process involves publishing the results back to the broker. The CI workflow of the consumer includes running Cypress tests, publishing the contract to the PACT broker, and triggering the CI workflow of the provider to verify the contract. Codetests ensure seamless communication between microservices, and Cypress MOCs can be transformed into pack consumer contracts using the correct adapter and PackBroker.

And the pack successfully published to the broker. Let's go back and review here the contract. This is the contract, the PACT, okay? A few seconds ago. If you click on view PACT interactions, we can view this list of directions would describe how the consumer expects the provider to behave. Okay, with status 200, test json to one, test json two, et cetera.

Now, the next steps are from the provider side, from the utility, that they should verify the contract. How can they do this? The simplest way is to use a local file, that it means that if you don't have a broker, then the consumer write the test and they copy the contract to a share file system. But if you have a PACT broker, like we did in our example, you don't pull the PACT file from the file system, but from the broker using a URL.

So you create a webhook. In order to create a webhook, you can use either the PACT CLI tool or the PACT broker UI. So if I use the PACT CLI tool, I can go here and create a test, a sample test, I bought the library, I have the provider name, the provider base URL, the PACT broker URL, and I use the method verify provider. And I say publish verification results true. To verify a contract is a half story. You should publish the results back to the broker. You can use the docker command, verify set the way again, you have to you say give the broker token, the public verification results, et cetera. So if you run this, it's going to reject or verify the contract. Okay. But of course, you can use the PACT broker UI. If you go at settings, at the web hooks, you can create here a web hook. That's going to be triggered by your CI-CD workflow. And since I said CI-CD workflow, I'm going to show you example of CI workflow of consumer. So here's the start, the checkout, then been installed, you run the consumer test with Cypress, you publish the contract, the packed file to the pack broker, then the CI workflow provider is triggered by web hook in order to verify the pack, the contract, and sends back the results with a new web hook. And then, I can use the, can I deploy a command from the pack CLI tool that asks if we can deploy in a particular environment. So, this will be an example of, of a CI workflow of consumer.

So, summary. Codetests ensure seamless communication between microservices reducing the risk of errors and breakdowns. Cypress MOCs can be transformed into pack consumer contracts by using the correct adapter and please use PackBroker to manage your contracts and your CI, CD workflow. I hope you found useful the Cypress Codetests for your software journey from good to great.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Featured Video
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.
TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ
TestJS Summit 2021TestJS Summit 2021
31 min
Test Effective Development
Developers want to sleep tight knowing they didn't break production. Companies want to be efficient in order to meet their customer needs faster and to gain competitive advantage sooner. We ALL want to be cost effective... or shall I say... TEST EFFECTIVE!But how do we do that?Are the "unit" and "integration" terminology serves us right?Or is it time for a change? When should we use either strategy to maximize our "test effectiveness"?In this talk I'll show you a brand new way to think about cost effective testing with new strategies and new testing terms!It’s time to go DEEPER!
TestJS Summit 2023TestJS Summit 2023
21 min
Everyone Can Easily Write Tests
Let’s take a look at how Playwright can help you get your end to end tests written with tools like Codegen that generate tests on user interaction. Let’s explore UI mode for a better developer experience and then go over some tips to make sure you don’t have flakey tests. Then let’s talk about how to get your tests up and running on CI, debugging on CI and scaling using shards.

Workshops on related topic

React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
TestJS Summit 2023TestJS Summit 2023
48 min
API Testing with Postman Workshop
In the ever-evolving landscape of software development, ensuring the reliability and functionality of APIs has become paramount. "API Testing with Postman" is a comprehensive workshop designed to equip participants with the knowledge and skills needed to excel in API testing using Postman, a powerful tool widely adopted by professionals in the field. This workshop delves into the fundamentals of API testing, progresses to advanced testing techniques, and explores automation, performance testing, and multi-protocol support, providing attendees with a holistic understanding of API testing with Postman.
1. Welcome to Postman- Explaining the Postman User Interface (UI)2. Workspace and Collections Collaboration- Understanding Workspaces and their role in collaboration- Exploring the concept of Collections for organizing and executing API requests3. Introduction to API Testing- Covering the basics of API testing and its significance4. Variable Management- Managing environment, global, and collection variables- Utilizing scripting snippets for dynamic data5. Building Testing Workflows- Creating effective testing workflows for comprehensive testing- Utilizing the Collection Runner for test execution- Introduction to Postbot for automated testing6. Advanced Testing- Contract Testing for ensuring API contracts- Using Mock Servers for effective testing- Maximizing productivity with Collection/Workspace templates- Integration Testing and Regression Testing strategies7. Automation with Postman- Leveraging the Postman CLI for automation- Scheduled Runs for regular testing- Integrating Postman into CI/CD pipelines8. Performance Testing- Demonstrating performance testing capabilities (showing the desktop client)- Synchronizing tests with VS Code for streamlined development9. Exploring Advanced Features - Working with Multiple Protocols: GraphQL, gRPC, and more
Join us for this workshop to unlock the full potential of Postman for API testing, streamline your testing processes, and enhance the quality and reliability of your software. Whether you're a beginner or an experienced tester, this workshop will equip you with the skills needed to excel in API testing with Postman.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
TestJS Summit 2023TestJS Summit 2023
148 min
Best Practices for Writing and Debugging Cypress Tests
You probably know the story. You’ve created a couple of tests, and since you are using Cypress, you’ve done this pretty quickly. Seems like nothing is stopping you, but then – failed test. It wasn’t the app, wasn’t an error, the test was… flaky? Well yes. Test design is important no matter what tool you will use, Cypress included. The good news is that Cypress has a couple of tools behind its belt that can help you out. Join me on my workshop, where I’ll guide you away from the valley of anti-patterns into the fields of evergreen, stable tests. We’ll talk about common mistakes when writing your test as well as debug and unveil underlying problems. All with the goal of avoiding flakiness, and designing stable test.