From Good to Great: Elevate Testing with Cypress Contract Tests

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.

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.

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.

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, motathen.packedflow.io. 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.

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.