Cypress Component Testing vs React Testing Library

Rate this content
Bookmark

CCT vs RTL talks about the similarities between the tools, the differences, compares the ways of doing the same things with the tools, and finally gives a developer experience comparison demo.

25 min
11 Dec, 2023

Video Summary and Transcription

The Talk discusses the differences between Cypress component testing and React Testing Library (RTL). It highlights the benefits of using Cypress Component Testing, such as easier handling of complex components and a more stable testing experience in CI. The comparison between SignOn and Jest focuses on low-level spying and mocking capabilities. The comparison between Cypress Intercept and Mock Service Worker (MSW) examines their network spy and mocking capabilities. The Talk also emphasizes the superior developer experience and observability provided by Cypress component testing compared to RTL.

Available in Español

1. Cypress Component Testing vs React Testing Library

Short description:

Hello, everyone. My name is Murat, and today I'll be talking about Cypress component testing versus React Testing Library. We've been using Cypress Component Testing at X10, my company, for one year, and we've been doing end-to-end tests for two years. In React, you may run into the situation where you have to wrap your component with many providers. This is a Cypress Component Test for a simple component from the book. Here's the second example, it's a text field, we're typing into it, it can also be read-only. On the left, Cypress, when we're mounting the component, we use site.stop instead and alias. Here is the third component, you're clicking on each one and ensuring that we're in a certain route and we want to make sure that the thing we click on is highlighted and the things we don't click on are not highlighted. The more complex the component gets, the more benefit you will have from the Cypress API and you will have a little less code accomplishing the same thing. But the real seller is the HTML versus browser.

Hello, everyone. My name is Murat, and today I'll be talking about Cypress component testing versus React Testing Library. You can find a copy of the presentation on Slides.com.

My name, SciCT versus RTL. Let's get started. The four topics in the presentation, Cypress component versus React Testing Library examples, low-level spying and mocking comparison, network-level spying and mocking comparison, and finally, a comparison of the developer experience. We've been using Cypress Component Testing at X10, my company, for one year, and we've been doing end-to-end tests for two years. We also have React Testing Library in there, too, so you are able to make some calculated comparisons between the two. All examples in the presentation will be from my book, Cypress Component Test Driven Design. With each component, you'll see a Cypress Component Test variant versus a React Testing Library variant, which you can compare yourselves when you produce the code.

In React, you may run into the situation where you have to wrap your component with many providers. When you are having a Cypress Component Test or a React Testing Library test, you have to mount the component the same way it's being mounted in your application, so for that you can use these custom mounts, which let you abstract away some of the complexities that you don't really have to think about when you're testing your component. The idea is from Kent Dodd's EPIC React, and you'll see pretty much the same code over here, and we'll compare how they're being used with different components. This is a Cypress Component Test for a simple component from the book, just showing you this is testing two of Heroes right over here. Let's take a look at the code, sizect on the right side, rtl on the left side, for mounting or rendering, that's the same way, in rtl we have right to left variable assignment and the assertions on that. Cytus, we have left to right chain syntax and similar assertions. We have the within API over in rtl, and it's a similar API on the Cypress site. At the end it's the same test, just slightly different APIs accomplishing the same thing. Here's the second example, it's a text field, we're typing into it, it can also be read-only. Then in the test, we want to make sure that onChange calls are being made as we're typing into the thing. The only distinction here is how we're marking the onChange, so just FN for onChange and then we're making sure that assignment is being done when we're mounting the component and then later on we make assertions on that component that it's being called so many times. On the left, Cypress, when we're mounting the component, we use site.stop instead and alias, later on we refer to the alias this way and then ensure that it's called so many times as we're typing into the field. Other than that, on the right side I also use testing library so we have find by placeholder text, over here we can compare that one on one, then we can see the API differences for ourselves. Here is the third component, you're clicking on each one and ensuring that we're in a certain route and we want to make sure that the thing we click on is highlighted and the things we don't click on are not highlighted. With Cypress, we have this jQuery convenience so we can click on something and verify that things are having a certain CSS and the things we don't click on don't have that CSS. It's possible to do the same thing on the RTL side but takes a little bit of work. And you'll see this pattern, the more complex the component gets, the more benefit you will have from the Cypress API and you will have a little less code accomplishing the same thing. But the real seller is the HTML versus browser. So on the React testing library side, you have things in the terminal, you basically have just HTML as text. And on the Cypress component testing side, you have the real browser, you have dev tools, you have network, everything that you have in your real application, but just with your component being mounted.

2. Cypress Component Tests vs RTL Examples

Short description:

So in Cypress, we can easily get the window object and call the get current position method with a fake position object. However, in RTL, we need to do some extra work to achieve the same result.

So that gives you plenty of observability into what's happening with it. If you've been through Epic React, you will like this one, because when I went through it, I created a Cypress component test mirror of all of these examples that Kent covers. And I picked three over here for us to take a look at together. So here's a simple Redux example. The way we're rendering or mounting with the Redux provider and the store is exactly the same. If you want to have a custom store, the way we're making an assignment is exactly the same. So nothing is different when it comes to Redux. With Ally, there's slightly different APIs because these are custom libraries at the end. The Cypress, the inject X, and the check Ally. With RTL, we get the container out of there and then make sure that it has no violations. The API is more nuance, a little different, when you want to have custom include impacts like modern or serious, you have to do a little bit of work over on the RTL side, but it's possible to accomplish the same thing. Geolocation is interesting because with Cypress we can just get the window out of the window object and from window navigator geolocation, the get current position method can be started to be called with this fake position object, and you can see the nice abstraction over there exactly communicating what we want to do, with just an RTL there's some work over there, so first we have to just fn the geolocation, and on top of that, after doing that get current position just fn, we have to mark the implementation saying that this is going to be a promise that takes a callback, that takes that fake position as an argument. So it takes a little bit of work, but on top of that we have to have this utility function that's simulating a deferred promise, because we have to act, and then resolve, and await that promise, and then make assertion. So again, it's possible to do the same thing on the RTL side, but it takes a little bit of work to accomplish the purpose. So those are some Cypress component tests versus RTL examples.

3. Comparing SignOn and Jest

Short description:

Let's compare the low-level spying and mocking capabilities of SignOn and Jest. They have similar APIs, but SignOn provides some convenient custom matchers. Asynchronous testing is slightly different between the two, but the end result is the same. When it comes to stubs and mocks, CyStub is comparable to JestFn, but the implementation and usage differ. Cynon provides nice abstractions for dealing with promises, but Jest requires more effort. Working with Jest in the React community has built expertise and a vested interest.

Let's take a look at the low-level spying and mocking capabilities, comparing SignOn and Jest. On the left side, we have SignOn. On the right side, we have Jest. SciSpy versus JeftSpyOn have similar APIs, taking an object and a method. To have been called dot notation versus camel case syntax, similar APIs, we have some alternatives on the SignOn side, but they do the same thing.

Matching strings or expecting any, that's a one-on-one comparison also. Custom matchers, you have these conveniences on the SignOn side and they're pretty easy to use and straightforward. It's possible to do the same thing on the Jest side, but it takes a little bit of work, so you have to create those yourself if you want to have custom matchers. That's why you don't see them too often.

Asyngonist testing, being able to create the spy is pretty much the same on either side. On the Cypher side, you can wrap the promise, the side wrap, and then make an assertion on it directly. On the RTL side, you have to gather all the promises first and then do a promise all. That way, you can verify the order of them, so the first call is 4 and 5, second call is 1 and 90, by adding these things together. On the Cypher side, it's kind of inferred because we called this one first, so that should be called first, and then called this one second, that should be called second. They're slightly different in asynchronous testing but at the end, again, we accomplish the same thing.

Let's make a contrast and take a look at the stubs and mocks. CyStub is directly comparable to JestFn to be able to stub something, object methods similar to CySpy API, with Jest, though, slightly different. We're all used to mock implementations and how we do it, but it does come from, hey, is this a spy or is this really a mock? In Jest, this is how we do it. We've been used to it, we've been doing this all the time, so it's easy to understand. I sometimes get confused what's the difference between mock implementation versus mock return value, but when you flip it to the Cynos side, it's clear. The mock return value is an extra, making sure that you're returning a certain method from the stubbing of the method. When we deal with promises and further make things a little more sophisticated, with Cynon we have some nice abstractions. Object method being called with var return foo, it's nice and declarative. Doing the same on the Jest side, yielding the argument, conditional. Yes, it's a bit of work, but it's possible. Following a promise, again, nicely abstracted. It's possible on the RTL side, but it takes a bit of work. Rejecting a promise, again, the same approach. But in the React committee, we've been used to these difficult ways of working with Jest. We have built some expertise on this, so definitely there's going to be some vested interest over there.

4. Comparing Cypress Intercept and MSW

Short description:

But on the Cynon side, you have declarative convenience, and on the Jest side, you have imperative possibility. Let's now compare the network spy and mocking capabilities of Cypress Intercept and Mock Service worker. When mocking on the network side, you can gain more confidence in your component. Comparing the APIs, MSW requires more setup and hooks, while Cypress Intercept provides a simpler API with more flexibility. Although MSW is fantastic, Cypress Intercept does slightly better in mocking at a network level.

But it's good to know that on the Cynon side, the same things are available with simpler abstractions, being able to use less code. So there are more examples in this repository, and you can compare one on one. And I go through many of the other comparisons, but at the end, the message is that on the Cynon side, you have declarative convenience, and on the Jest side, you have imperative possibility. You can do the same thing. It takes a bit of work on the Jest side, but it's entirely possible to accomplish the same purpose.

All right. So that was low level spy and mock comparison. Let's take a look at the network spy and mocking capabilities. Of course, I'm talking about Cypress Intercept and Mock Service worker. So if you've been through CAD Dots courses, you will know you want to mock more on the network side versus your code side. So you can get more confidence out of your component. And if you also use these custom mounts or custom renders, then you're in business. We do this at X10 and it's a lot less code we have to deal with because we don't have to mock as much.

Let's compare the APIs with Cypress Intercept in the method the route we're hitting. So let's say Heroes Route, should return 400. With MSW there's some setups, so you have to define your handlers and you have to define your route and what you're returning out of it. And then you have to do setup server with those handlers. You have to listen and then you have your test code. And at the end you have to reset handlers and close. So there is a bit of work setting this up but you can tame those with some test hooks. So here's an example. So you'll see the test hooks over here and the before all server listen after each resetting handlers and closing. You don't need any of that on the Cypress Intercept side. The other difference is that we can, for instance, have some intercept in the before each block and then we can flip things around and overwrite things in the it blocks over either overwrite or add on to them. With MSW you don't have that possibility, so you have to define your handlers and all of the it blocks underneath are going to be using these handlers. So if you want to change something slightly in an it block that's not possible. You're unfortunately going to have to repeat all these hooks in a separate block just to make that slight variation. For us, that makes all the difference, because having that flexibility allows us to have less code, less noise, and it's just a simpler API to work with. At the end, you can take a look at these resources, reproduce the code yourself, and form your own opinion, but in my opinion, although MSW is fantastic, it's a whole paradigm shift in mocking, being able to mock away from your source code at a network level. Cypress Intercept, in my opinion, does slightly better, and we see this at extent in any code comparison, although we haven't used MSW.

5. Comparing Developer Experience and Debugging

Short description:

Some of these examples show that the more complex the component gets, the less code is needed with Cypress Intercept. Let's compare the developer experience by going through three simple examples, introducing artificial failures, and debugging them. In one example, we change the display from 'off' to 'on' and observe the test results. With Cypress, we can quickly identify the failure and debug it by inspecting the DOM.

Some of these examples that we can take a look at, it is obvious the more complex the component gets, the less code with Cypress Intercept.

Finally, let's compare the developer experience. So for this one, I'm going to do a live demo, because otherwise it won't be really possible. So we'll go through three simple examples, and we're going to introduce artificial failures and try to debug them.

So here I have the header bar brand component. Let's just remember what it's doing. It's called a specs, and the bar brand. So this one is just going to show two of heroes. We're going to change that off to on. Let's see what happens. Here's our component on the left side. We'll just make that on. We'll have the RTL tests run over here. The failures do take a little more time, but RTL, you are going to spend a little more time when you're working a la carte on one component at a time. It's going to be faster, slightly faster when you're running the full suite. With Cypress, you can only match that if you're using Vite. With webpack, that's not going to be compatible, but single tests are going to be a lot faster with Cypress as we'll see throughout this demo.

So here, we have the failure, it's saying it failed in this line checking tour of heroes. And if it's a simple component, it's easy to spot tour on heroes, doesn't really match tour off heroes. That's how we know. With Cypress, as soon as I say, the test will be done, but let's just simulate that again. And you can see how much faster it is to get the feedback out of one test. So we can time travel, see that in tour, it got it. So it's looking for off in a span in this line, but it's not really getting it. That's not enough, since this is the real demo, right? We can just inspect that. And then go to the spot where it failed, turn off the highlight. And then we are right in our DOM. We see the tour span, we see the on span, right? And that is now what we want in our test, we want off. So it's a easy simulation of a failure and a debugging experience. All right, so let's close that one and then take a look at our second test.

6. Cypress Component Testing Stability

Short description:

Can we close the test too? Let me jump to the input detail component to show you the test. We type 42 and want onChange to be called twice. For the read-only version, we ensure that we can't interact with it. We introduce an artificial delay to simulate a failure. The Cypress component test waits for three seconds and retries, making the test stable. Cypress component testing is more stable in CI compared to RTL.

Can we close the test too, we don't have to make a modification here. So let me just, while that is cooking, I think it's going to have to take a while to run the RTL site, so we'll just let that cook. And I will just jump to input detail component over here just to show you what the test is looking like. Close this guy, select that one. So it's just a text field and we can be typing into it. For instance if I time traveled here the guy can add out the component. So as we're typing, we type 42 and we want onChange to be called twice. When it's a read-only version of the component, we just want to make sure that we can't interact with it. So that's the component. All right. And let's try to show more. File name, input, detail, test. Of course that's going to work. So what I want to simulate here is a failure. So say we have, as usual, a very asynchronous situation, and these on-change calls are coming with a slight delay. So we're going to introduce this artificial delay. We'll have to use tsignore to make that happen. So basically this says as I'm typing, there's a slight delay where the DOM is responding. So let's see what happens when we do that. I'll save. And I'm not going to wait for RTL to cook, but I'll make this save. And then I'll just take a look at the Cypress component test. So it is waiting for three seconds. And then it keeps retrying, retrying, retrying. And Cypress has this built-in retry capability. Right? And that makes the test very stable. So we didn't have to change anything to make the test work again. And this is the reason why you'll see your Cypress component testing that's a lot more stable in CI compared to RTL whenever you have these meaningful tests that are doing little ambitious things. And it will just work, very, very stable. You can do the same.

7. RTL Test and Heroes Component

Short description:

You can make it work on the RTL side, see input detail test. The static check isn't going to work. You're not getting these calls because this is a static check and it's failing on line 28. Once you use the WaitFor API wrapping that assertion in an async function, your test is going to be working better. So that is going to be the Heroes component. We're almost there with the RTL Passing Test of Input Detail. We'll just wait for it. In this one, we're testing the error component.

You can make it work on the RTL side, see input detail test. But in order to make this test, you will have to slightly change it. Right? The static check isn't going to work. Let's see a failure here. Right? You're not getting these calls because this is a static check and it's failing on line 28. Because when you have this kind of asynchronous behavior, you will have to use the WaitFor API wrapping that assertion in an async function. This part is exactly the same, but the WaitFor API is different. And once you do that, then your test is going to be working better, right? While that's cooking, I don't want to wait for RTL more, but we can switch to the next test. And I can show you the next one in Cypress Component Test while this test is running correctly again. We're gonna have to just wait for that. So while that's cooking, I'll just switch to the next test. So that is going to be the Heroes component. We're almost there with the RTL Passing Test of Input Detail. We'll just wait for it. Okay. So, okay, so, Input Detail ... Anyway, so I'm sure we'll get it to work if we wrestle a little more, but the idea is using the WaitFor function. And we'll just go over to our next test, with Heroes, right? And let's take a look at Heroes test. So in this one, what we're doing is, let's just go to it real quick. So in the second test, let's take a look at that one, where loading it, we are seeing this spinner, we're clicking the first Delete button, and then we're seeing the model, and then in that model, we are clicking No. And then once we click No, the model goes away. And the second time around, we delete again, and this time we click Yes. After we click Yes, we want the model to go away, and we want to see at the end a network response of 500 and then the error component. So we are testing the error component over there. So here, let's run the Heroes test. I'll put the Heroes test right over here. So in this component, let's try to simulate a failure with a monitor hook. So let's say whenever we delete something in the Heroes list, we want to say, okay, there's a problem with deleting heroes, we'll just comment this line out, and this line is going to fail. And if you look at the test on the RTL side, so we're clicking button yes, and then we're making sure the model is not in the view. And then at the end, we see the error.

8. Developer Experience and Observability

Short description:

The Cypress component test intercepts the network request and provides full observability into the component. In comparison, RTL lacks visibility and debugging capabilities. The developer experience with Cypress component testing is superior, as it allows for testing in a real browser and provides full observability. On the other hand, RTL leaves you in the dark. Overall, there are many similarities between the tools, but the key differentiator is the developer experience.

So the model will go away, I believe, but then since the hook is making the call to make that delete request, we're not going to see the error. And on the Cypress component test side, we intercept. So here we have the intercept right here. We have to have it on top of the file with RTL and MSW. We make the click and then the model goes away. We also wait for this network request, we're not really capable of doing the same waiting for network calls on the MSW side.

All right, so when we see the failure, let's take a look. So it's telling us that line 93 failed. We commented out things are probably going to work, but really looking at the terminal, we're not able to see anything or get a hint about what didn't work. Is this issue with the error component? Is there something wrong with our heroes component? We don't know, we're literally in the dark trying to diagnose an issue like this.

Let's see how that looks on the Cypress component test. So let's just rerun. So we do the delete operation, we're waiting for the delete network request. But that never goes up. And here we have some deal with it, but we can also look at the network tab of DevTools, and we'll just look at the XHR. So when you look at this, you should see a delete request go out. But nothing happens, right? We don't ever get that delete request. So we're able to deduce that, okay, whatever's causing that delete, which is the custom hook, there must be something not working with it. And then we think, okay, what makes that delete happen? This function. Then we can further go ahead and try to debug if there's something wrong with our custom hook.

This is a comparison of the developer experience between the three tools, between the two tools. I have some slides over here that tries to communicate with some videos, but without a live demo, you would never get the feeling. The main message then between these three experiences on one side, you're testing in the dark. On the other side, you have the lights on, you have full observability into the component. You see exactly what's happening with the browser, with the network, with the DOM. So that's the takeaway from the developer experience. To wrap up, there are many similarities between the tools. If you know React testing library and some Cypress end to end, be very comfortable with Cypress component testing. The Cypress component test, you have the declarative convenience, with RTL and Jest you have the imperative possibility. The key differentiator is the developer experience, in my opinion. On one side, you have the real browser, your full component, just by itself. So it's just like your full application, just put that component in isolation. On the other side, you have the HTML in the terminal. So that makes all the difference. You have full observability on one side versus you're in the dark with RTL. Here are all the links and references in this blog post, is what caused the presentation to start with. And a few others, you can look for Cypress component tests versus RTL comparisons. That's all I wanted to share. Thank you.

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
Top Content
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
Top Content
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
Top Content
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
Top Content
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
Top Content
WorkshopFree
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
WorkshopFree
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
WorkshopFree
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
Workshop
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.