Cypress Component Testing vs React Testing Library

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.

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.

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.

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.

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.

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.

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.

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.