WEBVTT 1 00:00:00.000 --> 00:00:02.080 All right, everyone, get ready for this. We're diving deep 2 00:00:02.080 --> 00:00:05.879 today into React Testing Library RTL. If you want to 3 00:00:05.919 --> 00:00:06.759 sound cool. 4 00:00:06.639 --> 00:00:07.200 Uh huh. 5 00:00:07.280 --> 00:00:07.719 Yeah. 6 00:00:07.960 --> 00:00:10.439 When we say cool, we really mean developers who are 7 00:00:10.560 --> 00:00:13.679 you know, serious about building React apps that are like 8 00:00:13.960 --> 00:00:17.839 actually good, robust, user friendly. 9 00:00:17.600 --> 00:00:20.280 All that for sure, And we've got an awesome guide 10 00:00:20.280 --> 00:00:23.760 for this deep dive. Simplified Testing with React Testing Library 11 00:00:24.280 --> 00:00:26.559 by Scotty Crump. Really a game changer. 12 00:00:26.839 --> 00:00:29.719 Absolutely. It's not just about you know, going through the 13 00:00:29.760 --> 00:00:33.200 motions with testing. It's about making tests that matter that 14 00:00:33.399 --> 00:00:37.039 focus on how like real people are going to use 15 00:00:37.079 --> 00:00:37.920 the thing you built. 16 00:00:38.000 --> 00:00:40.000 So let's about getting lost in all the code details 17 00:00:40.000 --> 00:00:43.280 and more about thinking like a user would clicking buttons, 18 00:00:43.399 --> 00:00:44.560 using forms, that sort of thing. 19 00:00:44.679 --> 00:00:47.039 Exactly. It's like imagine you're building a car. You wouldn't 20 00:00:47.079 --> 00:00:49.320 just test that the engine turns on right, You'd want 21 00:00:49.320 --> 00:00:51.320 to actually drive it, make sure the brakes work, the 22 00:00:51.359 --> 00:00:52.159 steering wheel. 23 00:00:51.960 --> 00:00:55.240 Does its job, Yeah, the seats are comfy, the whole experience. 24 00:00:55.000 --> 00:00:58.520 Exactly, because that's what matters the driver's experience. And that's 25 00:00:58.560 --> 00:01:02.520 the philosophy behind RTL. Well testing from the user's perspective, 26 00:01:02.560 --> 00:01:05.079 making sure that your React apps aren't just functional but 27 00:01:05.280 --> 00:01:06.599 actually enjoyable to use. 28 00:01:06.760 --> 00:01:09.319 Okay, I'm with you on the philosophy, but what about 29 00:01:09.359 --> 00:01:12.799 the actual tools and techniques What makes RTL stand out. 30 00:01:13.000 --> 00:01:15.560 So one of the key parts is just it's a 31 00:01:15.640 --> 00:01:20.480 JavaScript testing framework that's become like the industry standard for React. 32 00:01:20.560 --> 00:01:23.040 It gives you a really solid environment for running those 33 00:01:23.040 --> 00:01:25.319 tests and it works perfectly with RTL. 34 00:01:25.400 --> 00:01:28.040 And then there's this thing called the screen object right, 35 00:01:28.239 --> 00:01:30.079 which is kind of like a direct link to your 36 00:01:30.120 --> 00:01:30.799 apps UI. 37 00:01:31.040 --> 00:01:33.480 Yeah, think of it like x ray vision into your app. 38 00:01:33.519 --> 00:01:36.000 You can find elements on the page the same way 39 00:01:36.040 --> 00:01:38.280 a user would by their role, the text on them, 40 00:01:38.280 --> 00:01:38.840 stuff like that. 41 00:01:38.959 --> 00:01:42.879 So no more relying on those internal IDs or classes 42 00:01:42.920 --> 00:01:45.680 that could break your tests. That the code changes exactly. 43 00:01:45.840 --> 00:01:48.400 And when it comes to user interactions, RTL takes it 44 00:01:48.439 --> 00:01:51.439 a step further. With the user event module, you can 45 00:01:51.519 --> 00:01:55.519 actually simulate real user actions type being clicking, selecting. Makes 46 00:01:55.519 --> 00:01:57.120 your test super realistic. 47 00:01:57.319 --> 00:01:59.760 So instead of just checking if a button exists, you 48 00:01:59.799 --> 00:02:02.359 can test what happens when a user clicks it, how 49 00:02:02.400 --> 00:02:05.599 the UI changes, how the app reacts, all that. It's 50 00:02:05.599 --> 00:02:06.760 like having a robot. 51 00:02:06.480 --> 00:02:10.159 User huh huh exactly. And remember that car analogy. Well, 52 00:02:10.479 --> 00:02:13.639 when you're testing components that depend on libraries like Redux, 53 00:02:14.080 --> 00:02:16.319 it's like trying to test the engine while it's still 54 00:02:16.319 --> 00:02:19.520 hooked up to the transmission. Custom render methods are how 55 00:02:19.520 --> 00:02:22.159 we get around that. They let us isolate the component 56 00:02:22.240 --> 00:02:23.240 and test it properly. 57 00:02:23.400 --> 00:02:26.000 That's a brilliant analogy. So custom render methods are like 58 00:02:26.039 --> 00:02:28.039 setting up a little test lab where you can control 59 00:02:28.039 --> 00:02:31.159 the environment and see how your components react exactly. 60 00:02:31.639 --> 00:02:35.039 And this brings us to another important concept, the difference 61 00:02:35.080 --> 00:02:38.759 between integration testing and isolation testing. 62 00:02:38.879 --> 00:02:41.919 Now, this is where things get interesting. So integration testing 63 00:02:42.120 --> 00:02:44.879 is like looking at the big picture seeing how all 64 00:02:44.919 --> 00:02:47.560 the parts of your app work together, and isolation testing 65 00:02:47.639 --> 00:02:49.520 is kind of like zooming in on a single piece. 66 00:02:49.719 --> 00:02:52.240 Yeah, exactly. The book Use is a great example a 67 00:02:52.319 --> 00:02:55.960 vote component. It's got like two buttons like and dislike. 68 00:02:56.360 --> 00:02:59.400 Instead of testing each button separately, it shows how to 69 00:02:59.439 --> 00:03:01.120 test the whole component together. 70 00:03:01.479 --> 00:03:05.080 So like simulating a user clicking on like then dislike 71 00:03:05.560 --> 00:03:07.360 and making sure the counts update right. 72 00:03:07.520 --> 00:03:10.680 Right, You're testing the entire voting system from a user's perspective, 73 00:03:10.759 --> 00:03:12.240 making sure it all flows smoothly. 74 00:03:12.520 --> 00:03:16.560 Makes sense, But doesn't that make integration tests way more complex. 75 00:03:16.800 --> 00:03:19.360 It can be. You might have to you know, mock 76 00:03:19.439 --> 00:03:23.000 some dependencies or fake some external services, but in the 77 00:03:23.120 --> 00:03:25.280 end you get a way better understanding of how your 78 00:03:25.280 --> 00:03:26.400 app actually behaves. 79 00:03:26.599 --> 00:03:29.800 So it's about finding the right balance between complexity and 80 00:03:29.840 --> 00:03:30.759 getting a full picture. 81 00:03:31.000 --> 00:03:34.080 Yep, And the right approach depends on what you're testing. 82 00:03:34.479 --> 00:03:37.879 Sometimes testing in isolation is all you need, like if 83 00:03:37.919 --> 00:03:39.800 it's just a simple button or something, But for. 84 00:03:39.800 --> 00:03:42.840 A feature with lots of moving parts, integration testing is 85 00:03:42.840 --> 00:03:43.879 the way to go totally. 86 00:03:44.080 --> 00:03:47.280 And oh, don't forget about legacy code. A lot of 87 00:03:47.280 --> 00:03:51.599 projects have old tests written with tools like enzyme. Switching 88 00:03:51.599 --> 00:03:54.719 these to RTL can seem tough, but it's so worth it. 89 00:03:54.879 --> 00:03:57.479 Kind of like restoring a classic car. You want to 90 00:03:57.520 --> 00:03:59.520 keep its charm, but give it a modern engine. 91 00:03:59.599 --> 00:04:03.039 Exactly. By moving to RTL, you bring all these advantages 92 00:04:03.120 --> 00:04:06.159 of modern testing to your older projects, making your tests 93 00:04:06.159 --> 00:04:09.639 way better, easier to maintain, and in line with like 94 00:04:10.039 --> 00:04:11.400 the best practices today. 95 00:04:11.680 --> 00:04:16.279 Okay, so we've talked philosophy, the basics, even touched on 96 00:04:16.360 --> 00:04:19.879 legacy code, but there's more right. RTL has this whole 97 00:04:20.199 --> 00:04:22.040 ecosystem of advanced tools too. 98 00:04:22.240 --> 00:04:27.680 Oh, yeah, we're just getting started es lint, plugins, testing, playground, WALLABYJS, 99 00:04:27.800 --> 00:04:29.720 things that'll seriously level up your testing. 100 00:04:29.759 --> 00:04:32.079 Well, the dive into those later those sounds super interesting. 101 00:04:32.319 --> 00:04:35.360 I'm especially curious about this time traveling debugging thing you 102 00:04:35.360 --> 00:04:35.959 mentioned before. 103 00:04:36.040 --> 00:04:38.639 Ahah. Yeah, we'll get to that. And then there's Cypress, 104 00:04:38.680 --> 00:04:41.639 which takes UI testing to like a whole other level, 105 00:04:41.680 --> 00:04:44.720 letting you simulate complete user journeys throughout your application. 106 00:04:44.839 --> 00:04:46.920 So Cypress is basically like a robot user that can 107 00:04:47.000 --> 00:04:49.439 browse your entire website, add stuff to a cart, check 108 00:04:49.480 --> 00:04:50.160 out all. 109 00:04:50.000 --> 00:04:53.120 That exactly, and it integrates seamlessly with RTL, so you 110 00:04:53.160 --> 00:04:55.519 get that user centric approach even for those end to 111 00:04:55.600 --> 00:04:58.959 end tests. And it even uses design patterns like page 112 00:04:58.959 --> 00:05:01.600 objects to help or organize and maintain your Cyprus test, 113 00:05:01.680 --> 00:05:04.000 which is super helpful for larger projects. 114 00:05:04.199 --> 00:05:07.000 All right, I'm definitely feeling the excitement building. We barely 115 00:05:07.000 --> 00:05:10.279 scratch the surface, but I can already see how RTL 116 00:05:10.360 --> 00:05:12.879 can completely transform testing for sure. 117 00:05:12.920 --> 00:05:15.519 This is just the beginning. In the next part, we'll 118 00:05:15.519 --> 00:05:18.720 get more into the practical applications of RTL, looking at 119 00:05:18.759 --> 00:05:23.120 examples and strategies for testing different things. Stay tuned, all. 120 00:05:23.160 --> 00:05:26.199 Right, Welcome back to our React testing library deep dive. 121 00:05:26.959 --> 00:05:30.240 We're learning to think like users, not just code monkeys. 122 00:05:30.319 --> 00:05:33.399 Ah huh, right, and this time we're going to get practical, 123 00:05:33.399 --> 00:05:36.839 see how this whole user centric testing thing actually works 124 00:05:36.959 --> 00:05:39.240 in you know, real projects. 125 00:05:39.399 --> 00:05:41.759 Sounds good to me. Ready to get into the code. 126 00:05:41.839 --> 00:05:43.920 Well, before we do that, let's just quickly revisit the 127 00:05:43.959 --> 00:05:48.560 whole RTL philosophy. The book really hammers this point test 128 00:05:48.639 --> 00:05:51.279 from the user's perspective. That's how you get tests that 129 00:05:51.319 --> 00:05:52.399 are actually valuable. 130 00:05:52.600 --> 00:05:54.560 Makes sense. At the end of the day, it's users 131 00:05:54.560 --> 00:05:56.079 who are going to be using our app, so the 132 00:05:56.120 --> 00:05:57.439 tests should reflect. 133 00:05:57.040 --> 00:06:00.480 That right totally. We focus on the results users, not 134 00:06:00.519 --> 00:06:01.920 just the internal code stuff. 135 00:06:02.160 --> 00:06:05.199 Okay, so what does that look like in practice? Can 136 00:06:05.240 --> 00:06:06.240 you give me an example? 137 00:06:06.560 --> 00:06:10.160 Sure, Imagine we're building an online store and we're testing 138 00:06:10.199 --> 00:06:11.199 that ad to cart. 139 00:06:11.079 --> 00:06:15.240 Button, classic e commerce feature. Gotta have that exactly now. 140 00:06:15.279 --> 00:06:18.040 The old way of testing might just be like making 141 00:06:18.040 --> 00:06:20.040 sure the ad to kurt function gets called when you 142 00:06:20.079 --> 00:06:21.399 click it right, checking. 143 00:06:21.120 --> 00:06:22.680 The code behind it is doing its thing. 144 00:06:22.800 --> 00:06:25.519 But with RTL it's different. We don't care as much 145 00:06:25.519 --> 00:06:27.800 about that function call. We care about what the user 146 00:06:27.839 --> 00:06:29.920 actually sees happening. 147 00:06:29.519 --> 00:06:31.600 So we check that the item actually shows up in 148 00:06:31.639 --> 00:06:32.680 their cart after. 149 00:06:32.439 --> 00:06:35.920 They click yep, and that the cart counter updates, maybe 150 00:06:36.000 --> 00:06:38.279 even a success message pops up. Stuff like that. 151 00:06:38.639 --> 00:06:41.920 So it's not just does the button work, it's does 152 00:06:41.959 --> 00:06:45.639 the whole adding to card experience work correctly? Right? 153 00:06:45.879 --> 00:06:48.959 And these tests are way more resistant to code changes, Like, 154 00:06:49.079 --> 00:06:51.079 as long as what the user sees is the same, 155 00:06:51.720 --> 00:06:54.839 your tests should pass even if you totally rewrite the 156 00:06:54.879 --> 00:06:55.560 code underneath. 157 00:06:55.800 --> 00:06:59.959 That's smart future proof testing. Speaking of which, the book 158 00:07:00.040 --> 00:07:03.519 also talked about integration testing versus isolation testing. Can you 159 00:07:03.560 --> 00:07:04.360 break that down for me? 160 00:07:04.680 --> 00:07:08.240 Sure? Integration testing is like seeing how all the different 161 00:07:08.279 --> 00:07:11.279 parts of your app work together, like a well oiled machine, 162 00:07:11.399 --> 00:07:12.079 like putting. 163 00:07:11.800 --> 00:07:14.879 The puzzle pieces together, making sure they all fit exactly. 164 00:07:15.480 --> 00:07:18.199 The book has a great example a vote component. It's 165 00:07:18.240 --> 00:07:21.800 got two buttons like and dislike. Instead of testing each 166 00:07:21.839 --> 00:07:23.680 button on its own, it shows how to test the 167 00:07:23.720 --> 00:07:25.680 whole component as one unit. 168 00:07:26.040 --> 00:07:29.639 So we'd be simulating a user clicking like than dislike 169 00:07:30.199 --> 00:07:32.040 and making sure the counts are right yep. 170 00:07:32.360 --> 00:07:35.199 You're testing the whole voting mechanism from the user's point 171 00:07:35.199 --> 00:07:38.000 of view, ensuring that all the pieces work well together. 172 00:07:38.279 --> 00:07:41.480 That makes sense, But doesn't that make integration tests like 173 00:07:41.879 --> 00:07:43.680 more complicated to set up? 174 00:07:43.879 --> 00:07:46.839 Yeah, sometimes you might need to mock certain things or 175 00:07:46.879 --> 00:07:50.199 simulate external services things like that, but you get a 176 00:07:50.319 --> 00:07:53.199 much better understanding of how the whole app behaves. 177 00:07:53.240 --> 00:07:56.040 So it's a trade off. More complex to set up, 178 00:07:56.079 --> 00:07:58.399 but you get a more complete picture exactly. 179 00:07:58.600 --> 00:08:01.879 And that's why choosing the right testing strategy is so important. 180 00:08:02.199 --> 00:08:05.560 Sometimes isolation testing is enough, like if you're just working 181 00:08:05.639 --> 00:08:07.680 on a button or something small, but if it's. 182 00:08:07.600 --> 00:08:11.040 A big feature with lots of components interacting, integration testing 183 00:08:11.079 --> 00:08:12.560 is probably better, right. 184 00:08:12.959 --> 00:08:16.319 And speaking of complex features, things can get even trickier 185 00:08:16.399 --> 00:08:19.560 when you're using libraries like reducts, which is often used 186 00:08:19.560 --> 00:08:21.480 for managing State and React apps. 187 00:08:21.560 --> 00:08:24.959 Oh yeah, reducs. I've definitely struggled with testing those components. 188 00:08:25.000 --> 00:08:27.560 It's like trying to test an engine while it's still 189 00:08:27.560 --> 00:08:28.399 attached to the car. 190 00:08:28.600 --> 00:08:31.920 Perfect analogy. You need a way to isolate the component 191 00:08:31.959 --> 00:08:34.799 you're testing from all that extra stuff. That's where custom 192 00:08:34.840 --> 00:08:37.519 render methods come in. They let us create a controlled 193 00:08:37.600 --> 00:08:39.600 environment for testing Redux components. 194 00:08:39.720 --> 00:08:42.240 So instead of using the real reduct store, we can 195 00:08:42.279 --> 00:08:46.120 create a fake one with like preset data makes things 196 00:08:46.159 --> 00:08:47.799 more predictable exactly. 197 00:08:48.320 --> 00:08:50.639 And this approach can be used with other libraries too. 198 00:08:50.799 --> 00:08:53.399 It's all about isolating what you're testing, right. 199 00:08:53.440 --> 00:08:55.639 I see in the book also had some good tips 200 00:08:55.639 --> 00:08:58.519 for dealing with legacy code. Right. A lot of projects 201 00:08:58.519 --> 00:09:02.240 have those older tests using things like enzyme and moving 202 00:09:02.240 --> 00:09:03.799 those to RTL seems daunting. 203 00:09:04.080 --> 00:09:06.720 It can be, but the book offers some great guidance. 204 00:09:07.000 --> 00:09:10.000 Think of it like renovating a classic car. You want 205 00:09:10.000 --> 00:09:13.159 to keep the charm, but update it with modern stuff. 206 00:09:13.240 --> 00:09:15.519 So we're not just throwing away all the old tests, 207 00:09:15.960 --> 00:09:18.720 We're updating them to use RTL's approach. 208 00:09:18.600 --> 00:09:21.480 Exactly, and that way you get all the benefits of 209 00:09:21.600 --> 00:09:25.080 RTL even in older projects. Makes your tests more robust, 210 00:09:25.399 --> 00:09:28.200 easier to work with, and align with current best practices. 211 00:09:28.320 --> 00:09:31.200 Okay, that makes sense. Now I'm really curious about those 212 00:09:31.200 --> 00:09:33.759 advanced tools you mentioned earlier. Can we get into those now? 213 00:09:33.919 --> 00:09:37.039 Sure. One of the essentials is es LNT. It's like 214 00:09:37.080 --> 00:09:40.159 a codelinter, but it can be extended with plugins specifically 215 00:09:40.159 --> 00:09:41.200 for RTL. 216 00:09:40.879 --> 00:09:43.720 And JEST, So ESLINT for those who don't know, it's 217 00:09:43.759 --> 00:09:46.320 like a grammar checker for your code helps you catch 218 00:09:46.440 --> 00:09:47.960 errors and write cleaner. 219 00:09:47.559 --> 00:09:50.519 Code exactly, And these plug ins for RTL and JEST 220 00:09:50.600 --> 00:09:53.600 they take it further, giving you rules and tips specifically 221 00:09:53.600 --> 00:09:56.279 for writing good tests. They can help you avoid common 222 00:09:56.320 --> 00:09:58.440 mistakes and generally make your test better. 223 00:09:58.799 --> 00:10:01.440 So like having a testing expert looking over your shoulder 224 00:10:01.759 --> 00:10:03.600 giving you advice as you write code. 225 00:10:03.759 --> 00:10:07.200 Ah yeah. And then there's Testing Playground. If es lint 226 00:10:07.240 --> 00:10:10.000 is the grammar checker, this is like the visual dictionary 227 00:10:10.039 --> 00:10:12.440 for your tests. You can test out different selectors and 228 00:10:12.440 --> 00:10:14.000 see how they work with your HTML. 229 00:10:14.120 --> 00:10:17.120 I love Testing Playground. It's like having X ray vision 230 00:10:17.120 --> 00:10:20.480 for your components, showing you exactly what elements you need 231 00:10:20.519 --> 00:10:21.639 to target in your tests. 232 00:10:21.840 --> 00:10:25.360 Right, no more guessing about which selectors to use. It 233 00:10:25.399 --> 00:10:27.919 helps you write tests that are more accurate and less 234 00:10:27.960 --> 00:10:30.679 likely to break when your code changes. And for folks 235 00:10:30.679 --> 00:10:34.120 who want instant feedback and some really cool debugging features, 236 00:10:34.440 --> 00:10:36.120 there's Wallaby dot js. 237 00:10:36.279 --> 00:10:39.320 Okay, Wallaby dot js. Now things are getting interesting. What's 238 00:10:39.320 --> 00:10:40.240 so special about it? 239 00:10:40.519 --> 00:10:42.679 Well, it's a paid tool, but it's worth it. It 240 00:10:42.720 --> 00:10:45.440 integrates right into your code editor and gives you real 241 00:10:45.480 --> 00:10:48.759 time feedback as you're writing tests. You see errors immediately 242 00:10:49.000 --> 00:10:51.120 you can step through your code and see what's happening. 243 00:10:51.200 --> 00:10:53.360 Time travel do bugging. That's the thing you mentioned. 244 00:10:53.159 --> 00:10:57.639 Earlier, right, Yep, it's super helpful for finding those tricky bugs. 245 00:10:58.120 --> 00:11:01.799 Wallaby can really speed up you're testing and debugging process. 246 00:11:02.200 --> 00:11:04.759 So it's like having a personal testing assistant right there 247 00:11:04.759 --> 00:11:08.039 in your code. Awesome. What about Cypress you mentioned that 248 00:11:08.039 --> 00:11:08.600 earlier too. 249 00:11:08.720 --> 00:11:11.159 Yeah, Cypress is a whole other level. It's for end 250 00:11:11.159 --> 00:11:14.679 to end UI testing. Imagine a robot user that can 251 00:11:14.720 --> 00:11:18.120 actually interact with your app, like browsing through pages, clicking 252 00:11:18.120 --> 00:11:19.480 on things, filling out forms. 253 00:11:19.480 --> 00:11:23.600 So Cypress is like testing the entire user journey from start. 254 00:11:23.399 --> 00:11:27.320 To finish exactly. It's especially powerful for testing complex workflows 255 00:11:27.320 --> 00:11:30.240 and making sure your app behaves correctly in like real 256 00:11:30.279 --> 00:11:34.799 world scenarios. And the best part is it integrates seamlessly with. 257 00:11:34.919 --> 00:11:37.720 RTL, so you get that user centric approach even for 258 00:11:37.759 --> 00:11:39.240 those big end to end tests. 259 00:11:39.519 --> 00:11:42.799 Right. And Cypress has these things called page objects, which 260 00:11:42.840 --> 00:11:45.480 are like blueprints for different parts of your app. They 261 00:11:45.519 --> 00:11:48.159 make it way easier to organize and maintain your tests, 262 00:11:48.480 --> 00:11:49.919 especially for large projects. 263 00:11:49.960 --> 00:11:52.679 So Cypress is like the ultimate test pilot, putting your 264 00:11:52.679 --> 00:11:55.120 app through as paces and making sure it can handle 265 00:11:55.200 --> 00:11:56.519 anything users throw at it. 266 00:11:56.679 --> 00:11:59.600 Ah exactly, and Cypress can do more than just simulate 267 00:11:59.639 --> 00:12:03.240 user apps. You can test APIs directly from your UI, tests, 268 00:12:03.559 --> 00:12:07.480 check network requests, even interact with databases. It's really powerful. 269 00:12:07.799 --> 00:12:10.720 Okay, so the Cypress can basically test every layer of 270 00:12:10.759 --> 00:12:14.600 your application. Pretty impressive. What about those design patterns you 271 00:12:14.639 --> 00:12:17.519 mentioned for writing better subriss tests. 272 00:12:17.440 --> 00:12:20.320 Right, One of the most useful is the page object 273 00:12:20.360 --> 00:12:22.200 model or pom POM. 274 00:12:22.480 --> 00:12:26.080 That's about making tests more organized and less likely to break. Right. 275 00:12:26.399 --> 00:12:28.639 The idea is to create separate pieces of code that 276 00:12:28.679 --> 00:12:32.039 represent different pages or sections of your app. Each page 277 00:12:32.080 --> 00:12:35.399 object like encapsulates all the logic for interacting with that 278 00:12:35.480 --> 00:12:36.799 specific part of the UI. 279 00:12:36.960 --> 00:12:39.600 So instead of having all your Cypress commands scattered throughout 280 00:12:39.600 --> 00:12:42.200 your tests, you group them logically within these page objects. 281 00:12:42.519 --> 00:12:43.879 Makes things way cleaner. 282 00:12:43.840 --> 00:12:47.000 Exactly, and it makes your tests less sensitive to changes 283 00:12:47.039 --> 00:12:50.000 in your HTML. If the layout changes, you just update 284 00:12:50.039 --> 00:12:52.240 the page object, not a bunch of different tests. 285 00:12:52.360 --> 00:12:54.919 Saves a ton of time, less fixing tests, more time 286 00:12:54.960 --> 00:12:58.679 for new features. What about those custom Cypress commands you mentioned, Oh, 287 00:12:58.720 --> 00:12:59.360 those are great. 288 00:12:59.559 --> 00:13:02.440 They let you if you extend Cypress's functionality and create 289 00:13:02.519 --> 00:13:05.600 reusable pieces of code for your tests. Think about a 290 00:13:05.600 --> 00:13:09.120 common task like logging in or creating a new user. 291 00:13:08.879 --> 00:13:10.480 Stuff we do all the time and testing. 292 00:13:10.799 --> 00:13:13.039 Instead of writing the same Cypress commands over and over, 293 00:13:13.120 --> 00:13:15.519 you can create a custom command that does that whole 294 00:13:15.559 --> 00:13:16.200 thing for you. 295 00:13:16.279 --> 00:13:18.679 So it's like creating your own little library of testing 296 00:13:18.720 --> 00:13:19.879 actions exactly. 297 00:13:20.279 --> 00:13:24.200 Makes your tests shorter, easier to read, and less prone 298 00:13:24.200 --> 00:13:27.919 to errors. And Cypress can even test APIs directly from 299 00:13:27.960 --> 00:13:30.440 your UI tests. You can make sure your front end 300 00:13:30.480 --> 00:13:33.120 and back end are talking to each other properly without 301 00:13:33.159 --> 00:13:34.240 writing separate tests. 302 00:13:34.480 --> 00:13:36.799 Wow, so I can test my UI and API in 303 00:13:36.840 --> 00:13:40.399 the same Cypress test suite. That's amazing. Saves so much 304 00:13:40.440 --> 00:13:41.159 time and effort. 305 00:13:41.360 --> 00:13:44.679 Right and by testing your API from the user's perspective, 306 00:13:44.840 --> 00:13:48.559 you're simulating real world usage more accurately. You can verify 307 00:13:48.600 --> 00:13:51.600 that data is flowing correctly and your app is responding 308 00:13:51.679 --> 00:13:52.279 as it should. 309 00:13:52.559 --> 00:13:55.559 So Cypress really is like the ultimate testing tool, can 310 00:13:55.559 --> 00:13:57.039 handle anything you throw at it. 311 00:13:57.039 --> 00:14:00.320 It's really powerful. Now let's talk about something that can 312 00:14:00.320 --> 00:14:03.200 be really helpful when you're working with like non technical 313 00:14:03.240 --> 00:14:07.320 folks writing tests in a way that anyone can understand. 314 00:14:07.639 --> 00:14:09.799 Okay, interesting, how do we do that? 315 00:14:10.159 --> 00:14:13.279 Well? Cypress works great with something called Cucumber, which uses 316 00:14:13.320 --> 00:14:17.360 this language called Girkin. It's a simple, plain English way 317 00:14:17.440 --> 00:14:21.840 to write tests. Uses keywords like given, when. 318 00:14:21.879 --> 00:14:24.600 And then, so it's like writing out the steps of 319 00:14:24.639 --> 00:14:27.279 a test as if you were explaining it to someone. 320 00:14:27.399 --> 00:14:30.519 Makes it clear what's being tested and what should happen exactly. 321 00:14:30.600 --> 00:14:34.159 It bridges the gap between developers and everyone else. Cypers 322 00:14:34.159 --> 00:14:36.720 can run these Gurkin tests automatically, so everyone's on the 323 00:14:36.720 --> 00:14:39.799 same page about what's being tested and what success looks like. 324 00:14:39.960 --> 00:14:42.480 That's awesome. A shared language for testing. I like that. 325 00:14:42.960 --> 00:14:44.919 So we've got Cypress for end to end testing. But 326 00:14:44.960 --> 00:14:48.919 what about testing those less than ideal situations, like when 327 00:14:48.960 --> 00:14:51.240 things go wrong? How do we make sure our app 328 00:14:51.279 --> 00:14:52.440 handles those gracefully? 329 00:14:52.759 --> 00:14:56.559 Ah, you're talking about edge cases, those tricky little bugs 330 00:14:56.559 --> 00:14:59.399 that pop up when you least expect them, and that's 331 00:14:59.399 --> 00:15:02.799 where error handling and boundary testing come in. The book 332 00:15:02.799 --> 00:15:05.919 has some great advice on using RTL for those situations, 333 00:15:06.000 --> 00:15:09.759 making sure your app stays stable and user friendly even 334 00:15:09.759 --> 00:15:10.919 when things go sideways. 335 00:15:11.200 --> 00:15:12.720 So how do we do that with RTL? 336 00:15:13.039 --> 00:15:16.399 One way? Is to use RTL's fire event method, you 337 00:15:16.440 --> 00:15:19.200 can simulate all sorts of events that might trigger errors 338 00:15:19.679 --> 00:15:24.159 like invalid input, network problems, unexpected data from an API. 339 00:15:24.399 --> 00:15:26.840 So we're basically trying to break our app on purpose 340 00:15:27.000 --> 00:15:29.279 in a safe environment to see how it reacts. 341 00:15:29.360 --> 00:15:32.720 Uh huh yeah, pretty much. And then using RTL's querying methods, 342 00:15:32.720 --> 00:15:35.000 we can check that the right error messages are shown 343 00:15:35.240 --> 00:15:37.200 or that the app re covers properly. 344 00:15:36.960 --> 00:15:40.080 So instead of crashing, the app can handle errors gracefully 345 00:15:40.399 --> 00:15:41.919 and guide the user back on track. 346 00:15:42.080 --> 00:15:45.120 Exactly. It's about making the user experience as robust and 347 00:15:45.200 --> 00:15:47.720 resilient as possible, and the book gives some really good 348 00:15:47.720 --> 00:15:49.440 examples of how to do that with URTL. 349 00:15:49.639 --> 00:15:51.960 I like that thinking like a user, but also thinking 350 00:15:52.000 --> 00:15:54.519 like a user who might make mistakes or run into problems. 351 00:15:54.879 --> 00:15:58.960 Exactly. It's all part of building a truly user centric application. 352 00:16:00.000 --> 00:16:01.879 Well have you ever had to make changes to your 353 00:16:01.919 --> 00:16:05.039 app but you were worried about accidentally breaking something else 354 00:16:05.080 --> 00:16:05.759 in the process. 355 00:16:05.919 --> 00:16:10.320 Oh yeah, regressions every developer's worst nightmare. You fix one 356 00:16:10.360 --> 00:16:11.799 thing and break two other things. 357 00:16:11.919 --> 00:16:15.480 Uh huh yep. That's where regression testing comes in, and 358 00:16:15.679 --> 00:16:18.840 RTL has us covered there too. How So RTL gives 359 00:16:18.840 --> 00:16:20.759 you the tools to write tests that cover all the 360 00:16:20.799 --> 00:16:23.600 important parts of your app. With a good set of tests, 361 00:16:23.679 --> 00:16:26.759 you can make changes confidently knowing that your tests will 362 00:16:26.759 --> 00:16:28.919 catch any regressions before they go live. 363 00:16:29.039 --> 00:16:30.840 So it's like having a safety net making sure you 364 00:16:30.840 --> 00:16:33.759 don't accidentally introduce new bugs when you're fixing old ones. 365 00:16:33.919 --> 00:16:36.279 Exactly. And the book even shows you how to refactor 366 00:16:36.399 --> 00:16:38.799 old tests written with enzyme so you can bring those 367 00:16:38.879 --> 00:16:40.639 up to speed with RTL's approach. 368 00:16:40.840 --> 00:16:44.000 Awesome. So RTL is great for catching regressions in general. 369 00:16:44.320 --> 00:16:46.600 But the book also had a specific example about a 370 00:16:46.639 --> 00:16:49.799 budget app, right, something that helps users track their spending. 371 00:16:49.960 --> 00:16:52.639 Yeah, it shows how to write integration tests for that app, 372 00:16:52.759 --> 00:16:55.519 verifying that all the components work together correctly. 373 00:16:55.799 --> 00:16:58.440 So we're testing the whole budget management flow, not just 374 00:16:58.519 --> 00:16:59.360 individual pieces. 375 00:17:00.000 --> 00:17:03.240 Make sense, right, And to show regression testing in action, 376 00:17:03.759 --> 00:17:07.119 the book goes through updating the material UI library that 377 00:17:07.160 --> 00:17:10.839 the app uses. That's something that can often introduce regressions 378 00:17:11.000 --> 00:17:12.000 if you're not careful. 379 00:17:12.119 --> 00:17:15.039 Oh, I've been there, updating a library and suddenly half 380 00:17:15.039 --> 00:17:15.839 your app is broken. 381 00:17:15.960 --> 00:17:18.359 By having a good set of tests like the ones 382 00:17:18.400 --> 00:17:21.359 shown in the book, you can catch those regressions early 383 00:17:21.799 --> 00:17:23.720 and fix them before they affect your users. 384 00:17:23.839 --> 00:17:28.319 That's so important. So URTL helps us catch regressions, refacture 385 00:17:28.359 --> 00:17:32.640 old tests, and even test complex workflows. Is there anything 386 00:17:32.680 --> 00:17:33.240 it can't do? 387 00:17:33.480 --> 00:17:36.440 Uh huh. Well, it's not magic, but it's pretty close. 388 00:17:36.759 --> 00:17:40.400 It definitely makes testing way easier and more effective for sure. 389 00:17:40.599 --> 00:17:43.440 And the book also talks about best practices for writing 390 00:17:43.519 --> 00:17:45.960 tests right, things like how to name them, how to 391 00:17:46.079 --> 00:17:46.720 organize them. 392 00:17:46.839 --> 00:17:50.039 Yep, no one wants to deal with a messy, confusing 393 00:17:50.119 --> 00:17:52.240 test suite. It's like trying to find a needle in 394 00:17:52.240 --> 00:17:52.839 a haystack. 395 00:17:53.279 --> 00:17:55.640 Right. So it's not just about writing tests, it's about 396 00:17:55.680 --> 00:17:59.119 writing tests that are easy to understand and maintain exactly. 397 00:17:59.440 --> 00:18:02.200 We should tests with the same care we treat our 398 00:18:02.200 --> 00:18:05.799 production code. Now there's one more challenge. I want to 399 00:18:05.799 --> 00:18:09.440 mention something. A lot of developers struggle with choosing the 400 00:18:09.519 --> 00:18:13.559 right query selectors to target specific elements in their components. 401 00:18:13.920 --> 00:18:18.000