Speaker 1: All right, everyone, get ready for this. We're diving deep
Speaker 1: today into React Testing Library RTL. If you want to
Speaker 1: sound cool.
Speaker 2: Uh huh.
Speaker 1: Yeah.
Speaker 2: When we say cool, we really mean developers who are
Speaker 2: you know, serious about building React apps that are like
Speaker 2: actually good, robust, user friendly.
Speaker 1: All that for sure, And we've got an awesome guide
Speaker 1: for this deep dive. Simplified Testing with React Testing Library
Speaker 1: by Scotty Crump. Really a game changer.
Speaker 2: Absolutely. It's not just about you know, going through the
Speaker 2: motions with testing. It's about making tests that matter that
Speaker 2: focus on how like real people are going to use
Speaker 2: the thing you built.
Speaker 1: So let's about getting lost in all the code details
Speaker 1: and more about thinking like a user would clicking buttons,
Speaker 1: using forms, that sort of thing.
Speaker 2: Exactly. It's like imagine you're building a car. You wouldn't
Speaker 2: just test that the engine turns on right, You'd want
Speaker 2: to actually drive it, make sure the brakes work, the
Speaker 2: steering wheel.
Speaker 1: Does its job, Yeah, the seats are comfy, the whole experience.
Speaker 2: Exactly, because that's what matters the driver's experience. And that's
Speaker 2: the philosophy behind RTL. Well testing from the user's perspective,
Speaker 2: making sure that your React apps aren't just functional but
Speaker 2: actually enjoyable to use.
Speaker 1: Okay, I'm with you on the philosophy, but what about
Speaker 1: the actual tools and techniques What makes RTL stand out.
Speaker 2: So one of the key parts is just it's a
Speaker 2: JavaScript testing framework that's become like the industry standard for React.
Speaker 2: It gives you a really solid environment for running those
Speaker 2: tests and it works perfectly with RTL.
Speaker 1: And then there's this thing called the screen object right,
Speaker 1: which is kind of like a direct link to your
Speaker 1: apps UI.
Speaker 2: Yeah, think of it like x ray vision into your app.
Speaker 2: You can find elements on the page the same way
Speaker 2: a user would by their role, the text on them,
Speaker 2: stuff like that.
Speaker 1: So no more relying on those internal IDs or classes
Speaker 1: that could break your tests. That the code changes exactly.
Speaker 2: And when it comes to user interactions, RTL takes it
Speaker 2: a step further. With the user event module, you can
Speaker 2: actually simulate real user actions type being clicking, selecting. Makes
Speaker 2: your test super realistic.
Speaker 1: So instead of just checking if a button exists, you
Speaker 1: can test what happens when a user clicks it, how
Speaker 1: the UI changes, how the app reacts, all that. It's
Speaker 1: like having a robot.
Speaker 2: User huh huh exactly. And remember that car analogy. Well,
Speaker 2: when you're testing components that depend on libraries like Redux,
Speaker 2: it's like trying to test the engine while it's still
Speaker 2: hooked up to the transmission. Custom render methods are how
Speaker 2: we get around that. They let us isolate the component
Speaker 2: and test it properly.
Speaker 1: That's a brilliant analogy. So custom render methods are like
Speaker 1: setting up a little test lab where you can control
Speaker 1: the environment and see how your components react exactly.
Speaker 2: And this brings us to another important concept, the difference
Speaker 2: between integration testing and isolation testing.
Speaker 1: Now, this is where things get interesting. So integration testing
Speaker 1: is like looking at the big picture seeing how all
Speaker 1: the parts of your app work together, and isolation testing
Speaker 1: is kind of like zooming in on a single piece.
Speaker 2: Yeah, exactly. The book Use is a great example a
Speaker 2: vote component. It's got like two buttons like and dislike.
Speaker 2: Instead of testing each button separately, it shows how to
Speaker 2: test the whole component together.
Speaker 1: So like simulating a user clicking on like then dislike
Speaker 1: and making sure the counts update right.
Speaker 2: Right, You're testing the entire voting system from a user's perspective,
Speaker 2: making sure it all flows smoothly.
Speaker 1: Makes sense, But doesn't that make integration tests way more complex.
Speaker 2: It can be. You might have to you know, mock
Speaker 2: some dependencies or fake some external services, but in the
Speaker 2: end you get a way better understanding of how your
Speaker 2: app actually behaves.
Speaker 1: So it's about finding the right balance between complexity and
Speaker 1: getting a full picture.
Speaker 2: Yep, And the right approach depends on what you're testing.
Speaker 2: Sometimes testing in isolation is all you need, like if
Speaker 2: it's just a simple button or something, But for.
Speaker 1: A feature with lots of moving parts, integration testing is
Speaker 1: the way to go totally.
Speaker 2: And oh, don't forget about legacy code. A lot of
Speaker 2: projects have old tests written with tools like enzyme. Switching
Speaker 2: these to RTL can seem tough, but it's so worth it.
Speaker 1: Kind of like restoring a classic car. You want to
Speaker 1: keep its charm, but give it a modern engine.
Speaker 2: Exactly. By moving to RTL, you bring all these advantages
Speaker 2: of modern testing to your older projects, making your tests
Speaker 2: way better, easier to maintain, and in line with like
Speaker 2: the best practices today.
Speaker 1: Okay, so we've talked philosophy, the basics, even touched on
Speaker 1: legacy code, but there's more right. RTL has this whole
Speaker 1: ecosystem of advanced tools too.
Speaker 2: Oh, yeah, we're just getting started es lint, plugins, testing, playground, WALLABYJS,
Speaker 2: things that'll seriously level up your testing.
Speaker 1: Well, the dive into those later those sounds super interesting.
Speaker 1: I'm especially curious about this time traveling debugging thing you
Speaker 1: mentioned before.
Speaker 2: Ahah. Yeah, we'll get to that. And then there's Cypress,
Speaker 2: which takes UI testing to like a whole other level,
Speaker 2: letting you simulate complete user journeys throughout your application.
Speaker 1: So Cypress is basically like a robot user that can
Speaker 1: browse your entire website, add stuff to a cart, check
Speaker 1: out all.
Speaker 2: That exactly, and it integrates seamlessly with RTL, so you
Speaker 2: get that user centric approach even for those end to
Speaker 2: end tests. And it even uses design patterns like page
Speaker 2: objects to help or organize and maintain your Cyprus test,
Speaker 2: which is super helpful for larger projects.
Speaker 1: All right, I'm definitely feeling the excitement building. We barely
Speaker 1: scratch the surface, but I can already see how RTL
Speaker 1: can completely transform testing for sure.
Speaker 2: This is just the beginning. In the next part, we'll
Speaker 2: get more into the practical applications of RTL, looking at
Speaker 2: examples and strategies for testing different things. Stay tuned, all.
Speaker 1: Right, Welcome back to our React testing library deep dive.
Speaker 1: We're learning to think like users, not just code monkeys.
Speaker 2: Ah huh, right, and this time we're going to get practical,
Speaker 2: see how this whole user centric testing thing actually works
Speaker 2: in you know, real projects.
Speaker 1: Sounds good to me. Ready to get into the code.
Speaker 2: Well, before we do that, let's just quickly revisit the
Speaker 2: whole RTL philosophy. The book really hammers this point test
Speaker 2: from the user's perspective. That's how you get tests that
Speaker 2: are actually valuable.
Speaker 1: Makes sense. At the end of the day, it's users
Speaker 1: who are going to be using our app, so the
Speaker 1: tests should reflect.
Speaker 2: That right totally. We focus on the results users, not
Speaker 2: just the internal code stuff.
Speaker 1: Okay, so what does that look like in practice? Can
Speaker 1: you give me an example?
Speaker 2: Sure, Imagine we're building an online store and we're testing
Speaker 2: that ad to cart.
Speaker 1: Button, classic e commerce feature. Gotta have that exactly now.
Speaker 2: The old way of testing might just be like making
Speaker 2: sure the ad to kurt function gets called when you
Speaker 2: click it right, checking.
Speaker 1: The code behind it is doing its thing.
Speaker 2: But with RTL it's different. We don't care as much
Speaker 2: about that function call. We care about what the user
Speaker 2: actually sees happening.
Speaker 1: So we check that the item actually shows up in
Speaker 1: their cart after.
Speaker 2: They click yep, and that the cart counter updates, maybe
Speaker 2: even a success message pops up. Stuff like that.
Speaker 1: So it's not just does the button work, it's does
Speaker 1: the whole adding to card experience work correctly? Right?
Speaker 2: And these tests are way more resistant to code changes, Like,
Speaker 2: as long as what the user sees is the same,
Speaker 2: your tests should pass even if you totally rewrite the
Speaker 2: code underneath.
Speaker 1: That's smart future proof testing. Speaking of which, the book
Speaker 1: also talked about integration testing versus isolation testing. Can you
Speaker 1: break that down for me?
Speaker 2: Sure? Integration testing is like seeing how all the different
Speaker 2: parts of your app work together, like a well oiled machine,
Speaker 2: like putting.
Speaker 1: The puzzle pieces together, making sure they all fit exactly.
Speaker 2: The book has a great example a vote component. It's
Speaker 2: got two buttons like and dislike. Instead of testing each
Speaker 2: button on its own, it shows how to test the
Speaker 2: whole component as one unit.
Speaker 1: So we'd be simulating a user clicking like than dislike
Speaker 1: and making sure the counts are right yep.
Speaker 2: You're testing the whole voting mechanism from the user's point
Speaker 2: of view, ensuring that all the pieces work well together.
Speaker 1: That makes sense, But doesn't that make integration tests like
Speaker 1: more complicated to set up?
Speaker 2: Yeah, sometimes you might need to mock certain things or
Speaker 2: simulate external services things like that, but you get a
Speaker 2: much better understanding of how the whole app behaves.
Speaker 1: So it's a trade off. More complex to set up,
Speaker 1: but you get a more complete picture exactly.
Speaker 2: And that's why choosing the right testing strategy is so important.
Speaker 2: Sometimes isolation testing is enough, like if you're just working
Speaker 2: on a button or something small, but if it's.
Speaker 1: A big feature with lots of components interacting, integration testing
Speaker 1: is probably better, right.
Speaker 2: And speaking of complex features, things can get even trickier
Speaker 2: when you're using libraries like reducts, which is often used
Speaker 2: for managing State and React apps.
Speaker 1: Oh yeah, reducs. I've definitely struggled with testing those components.
Speaker 1: It's like trying to test an engine while it's still
Speaker 1: attached to the car.
Speaker 2: Perfect analogy. You need a way to isolate the component
Speaker 2: you're testing from all that extra stuff. That's where custom
Speaker 2: render methods come in. They let us create a controlled
Speaker 2: environment for testing Redux components.
Speaker 1: So instead of using the real reduct store, we can
Speaker 1: create a fake one with like preset data makes things
Speaker 1: more predictable exactly.
Speaker 2: And this approach can be used with other libraries too.
Speaker 2: It's all about isolating what you're testing, right.
Speaker 1: I see in the book also had some good tips
Speaker 1: for dealing with legacy code. Right. A lot of projects
Speaker 1: have those older tests using things like enzyme and moving
Speaker 1: those to RTL seems daunting.
Speaker 2: It can be, but the book offers some great guidance.
Speaker 2: Think of it like renovating a classic car. You want
Speaker 2: to keep the charm, but update it with modern stuff.
Speaker 1: So we're not just throwing away all the old tests,
Speaker 1: We're updating them to use RTL's approach.
Speaker 2: Exactly, and that way you get all the benefits of
Speaker 2: RTL even in older projects. Makes your tests more robust,
Speaker 2: easier to work with, and align with current best practices.
Speaker 1: Okay, that makes sense. Now I'm really curious about those
Speaker 1: advanced tools you mentioned earlier. Can we get into those now?
Speaker 2: Sure. One of the essentials is es LNT. It's like
Speaker 2: a codelinter, but it can be extended with plugins specifically
Speaker 2: for RTL.
Speaker 1: And JEST, So ESLINT for those who don't know, it's
Speaker 1: like a grammar checker for your code helps you catch
Speaker 1: errors and write cleaner.
Speaker 2: Code exactly, And these plug ins for RTL and JEST
Speaker 2: they take it further, giving you rules and tips specifically
Speaker 2: for writing good tests. They can help you avoid common
Speaker 2: mistakes and generally make your test better.
Speaker 1: So like having a testing expert looking over your shoulder
Speaker 1: giving you advice as you write code.
Speaker 2: Ah yeah. And then there's Testing Playground. If es lint
Speaker 2: is the grammar checker, this is like the visual dictionary
Speaker 2: for your tests. You can test out different selectors and
Speaker 2: see how they work with your HTML.
Speaker 1: I love Testing Playground. It's like having X ray vision
Speaker 1: for your components, showing you exactly what elements you need
Speaker 1: to target in your tests.
Speaker 2: Right, no more guessing about which selectors to use. It
Speaker 2: helps you write tests that are more accurate and less
Speaker 2: likely to break when your code changes. And for folks
Speaker 2: who want instant feedback and some really cool debugging features,
Speaker 2: there's Wallaby dot js.
Speaker 1: Okay, Wallaby dot js. Now things are getting interesting. What's
Speaker 1: so special about it?
Speaker 2: Well, it's a paid tool, but it's worth it. It
Speaker 2: integrates right into your code editor and gives you real
Speaker 2: time feedback as you're writing tests. You see errors immediately
Speaker 2: you can step through your code and see what's happening.
Speaker 1: Time travel do bugging. That's the thing you mentioned.
Speaker 2: Earlier, right, Yep, it's super helpful for finding those tricky bugs.
Speaker 2: Wallaby can really speed up you're testing and debugging process.
Speaker 1: So it's like having a personal testing assistant right there
Speaker 1: in your code. Awesome. What about Cypress you mentioned that
Speaker 1: earlier too.
Speaker 2: Yeah, Cypress is a whole other level. It's for end
Speaker 2: to end UI testing. Imagine a robot user that can
Speaker 2: actually interact with your app, like browsing through pages, clicking
Speaker 2: on things, filling out forms.
Speaker 1: So Cypress is like testing the entire user journey from start.
Speaker 2: To finish exactly. It's especially powerful for testing complex workflows
Speaker 2: and making sure your app behaves correctly in like real
Speaker 2: world scenarios. And the best part is it integrates seamlessly with.
Speaker 1: RTL, so you get that user centric approach even for
Speaker 1: those big end to end tests.
Speaker 2: Right. And Cypress has these things called page objects, which
Speaker 2: are like blueprints for different parts of your app. They
Speaker 2: make it way easier to organize and maintain your tests,
Speaker 2: especially for large projects.
Speaker 1: So Cypress is like the ultimate test pilot, putting your
Speaker 1: app through as paces and making sure it can handle
Speaker 1: anything users throw at it.
Speaker 2: Ah exactly, and Cypress can do more than just simulate
Speaker 2: user apps. You can test APIs directly from your UI, tests,
Speaker 2: check network requests, even interact with databases. It's really powerful.
Speaker 1: Okay, so the Cypress can basically test every layer of
Speaker 1: your application. Pretty impressive. What about those design patterns you
Speaker 1: mentioned for writing better subriss tests.
Speaker 2: Right, One of the most useful is the page object
Speaker 2: model or pom POM.
Speaker 1: That's about making tests more organized and less likely to break. Right.
Speaker 2: The idea is to create separate pieces of code that
Speaker 2: represent different pages or sections of your app. Each page
Speaker 2: object like encapsulates all the logic for interacting with that
Speaker 2: specific part of the UI.
Speaker 1: So instead of having all your Cypress commands scattered throughout
Speaker 1: your tests, you group them logically within these page objects.
Speaker 1: Makes things way cleaner.
Speaker 2: Exactly, and it makes your tests less sensitive to changes
Speaker 2: in your HTML. If the layout changes, you just update
Speaker 2: the page object, not a bunch of different tests.
Speaker 1: Saves a ton of time, less fixing tests, more time
Speaker 1: for new features. What about those custom Cypress commands you mentioned, Oh,
Speaker 1: those are great.
Speaker 2: They let you if you extend Cypress's functionality and create
Speaker 2: reusable pieces of code for your tests. Think about a
Speaker 2: common task like logging in or creating a new user.
Speaker 1: Stuff we do all the time and testing.
Speaker 2: Instead of writing the same Cypress commands over and over,
Speaker 2: you can create a custom command that does that whole
Speaker 2: thing for you.
Speaker 1: So it's like creating your own little library of testing
Speaker 1: actions exactly.
Speaker 2: Makes your tests shorter, easier to read, and less prone
Speaker 2: to errors. And Cypress can even test APIs directly from
Speaker 2: your UI tests. You can make sure your front end
Speaker 2: and back end are talking to each other properly without
Speaker 2: writing separate tests.
Speaker 1: Wow, so I can test my UI and API in
Speaker 1: the same Cypress test suite. That's amazing. Saves so much
Speaker 1: time and effort.
Speaker 2: Right and by testing your API from the user's perspective,
Speaker 2: you're simulating real world usage more accurately. You can verify
Speaker 2: that data is flowing correctly and your app is responding
Speaker 2: as it should.
Speaker 1: So Cypress really is like the ultimate testing tool, can
Speaker 1: handle anything you throw at it.
Speaker 2: It's really powerful. Now let's talk about something that can
Speaker 2: be really helpful when you're working with like non technical
Speaker 2: folks writing tests in a way that anyone can understand.
Speaker 1: Okay, interesting, how do we do that?
Speaker 2: Well? Cypress works great with something called Cucumber, which uses
Speaker 2: this language called Girkin. It's a simple, plain English way
Speaker 2: to write tests. Uses keywords like given, when.
Speaker 1: And then, so it's like writing out the steps of
Speaker 1: a test as if you were explaining it to someone.
Speaker 1: Makes it clear what's being tested and what should happen exactly.
Speaker 2: It bridges the gap between developers and everyone else. Cypers
Speaker 2: can run these Gurkin tests automatically, so everyone's on the
Speaker 2: same page about what's being tested and what success looks like.
Speaker 1: That's awesome. A shared language for testing. I like that.
Speaker 1: So we've got Cypress for end to end testing. But
Speaker 1: what about testing those less than ideal situations, like when
Speaker 1: things go wrong? How do we make sure our app
Speaker 1: handles those gracefully?
Speaker 2: Ah, you're talking about edge cases, those tricky little bugs
Speaker 2: that pop up when you least expect them, and that's
Speaker 2: where error handling and boundary testing come in. The book
Speaker 2: has some great advice on using RTL for those situations,
Speaker 2: making sure your app stays stable and user friendly even
Speaker 2: when things go sideways.
Speaker 1: So how do we do that with RTL?
Speaker 2: One way? Is to use RTL's fire event method, you
Speaker 2: can simulate all sorts of events that might trigger errors
Speaker 2: like invalid input, network problems, unexpected data from an API.
Speaker 1: So we're basically trying to break our app on purpose
Speaker 1: in a safe environment to see how it reacts.
Speaker 2: Uh huh yeah, pretty much. And then using RTL's querying methods,
Speaker 2: we can check that the right error messages are shown
Speaker 2: or that the app re covers properly.
Speaker 1: So instead of crashing, the app can handle errors gracefully
Speaker 1: and guide the user back on track.
Speaker 2: Exactly. It's about making the user experience as robust and
Speaker 2: resilient as possible, and the book gives some really good
Speaker 2: examples of how to do that with URTL.
Speaker 1: I like that thinking like a user, but also thinking
Speaker 1: like a user who might make mistakes or run into problems.
Speaker 2: Exactly. It's all part of building a truly user centric application.
Speaker 2: Well have you ever had to make changes to your
Speaker 2: app but you were worried about accidentally breaking something else
Speaker 2: in the process.
Speaker 1: Oh yeah, regressions every developer's worst nightmare. You fix one
Speaker 1: thing and break two other things.
Speaker 2: Uh huh yep. That's where regression testing comes in, and
Speaker 2: RTL has us covered there too. How So RTL gives
Speaker 2: you the tools to write tests that cover all the
Speaker 2: important parts of your app. With a good set of tests,
Speaker 2: you can make changes confidently knowing that your tests will
Speaker 2: catch any regressions before they go live.
Speaker 1: So it's like having a safety net making sure you
Speaker 1: don't accidentally introduce new bugs when you're fixing old ones.
Speaker 2: Exactly. And the book even shows you how to refactor
Speaker 2: old tests written with enzyme so you can bring those
Speaker 2: up to speed with RTL's approach.
Speaker 1: Awesome. So RTL is great for catching regressions in general.
Speaker 1: But the book also had a specific example about a
Speaker 1: budget app, right, something that helps users track their spending.
Speaker 2: Yeah, it shows how to write integration tests for that app,
Speaker 2: verifying that all the components work together correctly.
Speaker 1: So we're testing the whole budget management flow, not just
Speaker 1: individual pieces.
Speaker 2: Make sense, right, And to show regression testing in action,
Speaker 2: the book goes through updating the material UI library that
Speaker 2: the app uses. That's something that can often introduce regressions
Speaker 2: if you're not careful.
Speaker 1: Oh, I've been there, updating a library and suddenly half
Speaker 1: your app is broken.
Speaker 2: By having a good set of tests like the ones
Speaker 2: shown in the book, you can catch those regressions early
Speaker 2: and fix them before they affect your users.
Speaker 1: That's so important. So URTL helps us catch regressions, refacture
Speaker 1: old tests, and even test complex workflows. Is there anything
Speaker 1: it can't do?
Speaker 2: Uh huh. Well, it's not magic, but it's pretty close.
Speaker 2: It definitely makes testing way easier and more effective for sure.
Speaker 1: And the book also talks about best practices for writing
Speaker 1: tests right, things like how to name them, how to
Speaker 1: organize them.
Speaker 2: Yep, no one wants to deal with a messy, confusing
Speaker 2: test suite. It's like trying to find a needle in
Speaker 2: a haystack.
Speaker 1: Right. So it's not just about writing tests, it's about
Speaker 1: writing tests that are easy to understand and maintain exactly.
Speaker 2: We should tests with the same care we treat our
Speaker 2: production code. Now there's one more challenge. I want to
Speaker 2: mention something. A lot of developers struggle with choosing the
Speaker 2: right query selectors to target specific elements in their components.
Speaker 2: It can be a real pain, especially with complex HTML structures.
Speaker 1: Oh tell me about it. I've spent way too much
Speaker 1: time trying to figure out the perfect selector.
Speaker 2: Well, thankfully, there's this awesome tool called testing Playground. It's interactive.
Speaker 2: You can paste in your components HTML and visually see
Speaker 2: how different selectors work.
Speaker 1: Like a treasure map that leads you right to the
Speaker 1: element you're looking for.
Speaker 2: Uh huh, yeah, exactly. It takes all the guesswork out
Speaker 2: of it, and Testing Playground doesn't just find any selector.
Speaker 2: It tries to find the best one, following RTL's best practices.
Speaker 1: So it's not just about finding a selector that works,
Speaker 1: it's about finding the one that's going to be the
Speaker 1: most robust and reliable in the long run. I love that.
Speaker 2: Now, for those who really want to take their testing
Speaker 2: workflow to the next level, there's Wallaby dot js gobytjs.
Speaker 1: That's one with the time traveling debugging right. Yeah, yep.
Speaker 2: It's a paid tool, but it's amazing. It integrates directly
Speaker 2: into your code editor and gives you instant feedback as
Speaker 2: you write tests. You see errors pop up right away.
Speaker 2: You can step through your code execution and even rewind
Speaker 2: time to see exactly when something went wrong.
Speaker 1: That's incredible, like having a testing superpower.
Speaker 2: Uh huh. It really does feel that way. Sometimes. It
Speaker 2: can make writing and debugging tests so much faster and
Speaker 2: more enjoyable.
Speaker 1: So Wallaby dad js is definitely something to check out
Speaker 1: if you're serious about testing.
Speaker 2: Absolutely. Now, let's shift gears and talk about end to
Speaker 2: end testing with Cypress.
Speaker 1: Cypress, that's the framework that simulates real user interactions.
Speaker 2: Right exactly. Imagine a robot user that can browse your website,
Speaker 2: click buttons, fill out forms, and do everything a real
Speaker 2: user would do.
Speaker 1: So it's like testing the entire user journey from start
Speaker 1: to finish.
Speaker 2: Right, And Cypress makes it surprisingly easy to write these
Speaker 2: kinds of tests and has a really nice visual test
Speaker 2: runner that shows you exactly what's happening as your tests
Speaker 2: are running, so you.
Speaker 1: Can actually watch the about user interact with your app.
Speaker 1: That's awesome.
Speaker 2: Yeah, it's really cool and it's super helpful for finding
Speaker 2: and fixing problems. But Cypress can do more than just
Speaker 2: simulate user interactions. You can also use it to test APIs,
Speaker 2: verify network requests, and even interact with databases. It's a
Speaker 2: really comprehensive testing solution.
Speaker 1: Sounds like Cypress has it all.
Speaker 2: It's pretty amazing. But even with a tool as powerful
Speaker 2: as Cypress, it's important to write your tests in a
Speaker 2: way that's organized and easy to maintain. That's where design
Speaker 2: patterns come in.
Speaker 1: Design patterns those are like looprints for structuring your code
Speaker 1: right exactly.
Speaker 2: One of the most useful patterns for Cypress tests is
Speaker 2: the page object model or POM for short.
Speaker 1: POM that sound similiar. It's about making your tests less
Speaker 1: likely to break when your code changes.
Speaker 2: Right, you got it. The idea is to create separate
Speaker 2: classes or modules that represent each page or section of
Speaker 2: your app. These page objects contain all the logic for
Speaker 2: interacting with that specific part of the UI.
Speaker 1: Well. Instead of having your Cypress command and scattered all
Speaker 1: over the place, you group them logically within these page objects.
Speaker 2: Exactly, and by abstracting away the UI interactions, your tests
Speaker 2: become less brittle. If the layout of a page changes,
Speaker 2: you only need to update the page object, not a
Speaker 2: ton of different tests.
Speaker 1: Makes sense, less maintenance, more time for building new stuff right.
Speaker 2: The book also mentions the power of using custom Cypress commands.
Speaker 1: Custom commands what are those?
Speaker 2: They let you create reusable chunks of code for common
Speaker 2: actions in your tests. For example, imagine you have a
Speaker 2: common workflow in your app, like logging in or creating
Speaker 2: a new.
Speaker 1: Account, stuff we do all the time in testing exactly.
Speaker 2: Instead of writing those same Cypress commands over and over
Speaker 2: in different tests, you can create a custom command that
Speaker 2: encapsulates that entire workflow.
Speaker 1: So it's like building your own library of testing actions.
Speaker 1: Makes your test more concise and less repetitive.
Speaker 2: Exactly, and less repetition means fewer errors and inconsistencies in
Speaker 2: your tests.
Speaker 1: I could see how that would be super helpful.
Speaker 2: Cypress also lets you test your apid directly from your
Speaker 2: UI tests, so you can make sure the front end
Speaker 2: and back end are talking to each other correctly without
Speaker 2: writing separate API tests.
Speaker 1: Wow. So I can test both my UI and API
Speaker 1: from the same Cypress test suite. That's pretty amazing. It
Speaker 1: saves a ton of time.
Speaker 2: It really does, and it's a more realistic way to
Speaker 2: test because in the real world, your front end and
Speaker 2: back end are always interacting.
Speaker 1: Okay, I'm sold on Cypress. It sounds like an incredibly
Speaker 1: powerful and versatile tool.
Speaker 2: It really is. And you know, even though Cypress is
Speaker 2: great for technical folks, sometimes we need to involve people
Speaker 2: who aren't as familiar with code. That's where Cucumber comes in.
Speaker 1: Cucumber that's one that uses plain English to write tests.
Speaker 2: Right exactly. It uses a language called Girkin, which is
Speaker 2: super readable and easy to understand even for non technical folks.
Speaker 2: You write your tests using keywords like given, when, and then,
Speaker 2: so it almost reads like a story.
Speaker 1: So instead of writing code, you're basically writing out the
Speaker 1: steps of the test in plain English. Right.
Speaker 2: It's a great way to bridge the communication gap between
Speaker 2: developers and stakeholders and to make sure everyone's on the
Speaker 2: same page about what's being tested and what the expected
Speaker 2: outcome should be.
Speaker 1: So Cucumber is like a universal language for testing that
Speaker 1: everyone can understand exactly.
Speaker 2: And the best part is Cypress has built in support
Speaker 2: for Cucumber, so you can write your tests in this
Speaker 2: plain English format and Cypress will run them automatically.
Speaker 1: That's awesome. It makes testing more collaborative and accessible to everyone.
Speaker 2: Now, while all these testing tools and techniques are incredibly valuable,
Speaker 2: it's important to remember that testing is ultimately about creating
Speaker 2: software that meets the needs of our users.
Speaker 1: Right. That's the core of the user centric.
Speaker 2: Approach, and a big part of that is making sure
Speaker 2: our apps are accessible to everyone, regardless of their abilities.
Speaker 1: Accessibility is so important. I have a friend who uses
Speaker 1: a screen reader and she's constantly running into websites and
Speaker 1: apps that are just impossible to use.
Speaker 2: It's a real shame, it is, But luckily RTL can
Speaker 2: help us address these accessibility challenges by encouraging us to
Speaker 2: test from the user's perspective. RTL naturally leads us to
Speaker 2: consider how people with different needs and abilities will experience
Speaker 2: our applications.
Speaker 1: So if we're testing a form, for example, we might
Speaker 1: make sure it can be navigated using only the keyboard,
Speaker 1: or that it provides clear instructions for screen.
Speaker 2: Readers exactly, And there are tools that can help us
Speaker 2: with this. The book mentions just Acts, a library that
Speaker 2: can run automated accessibility audits on your React components.
Speaker 1: So it's like having an accessibility expert built right into
Speaker 1: your testing process exactly.
Speaker 2: By integrating just Acts into our workflow, we can catch
Speaker 2: and fix accessibility issues early on before they impact our users.
Speaker 1: This is all great stuff. It really feels like RTL
Speaker 1: is a game changer for testing, especially for building user
Speaker 1: centric and accessible applications.
Speaker 2: I agree. It's a powerful approach that can really improve
Speaker 2: the quality of the software we build.
Speaker 1: Right. So we've covered a lot of ground in this
Speaker 1: deep dies as we wrap things up, What are some
Speaker 1: of the key takeaways you'd like our listeners to remember.
Speaker 2: I think the biggest one is that RTL is more
Speaker 2: than just a collection of tools and techniques. It's a
Speaker 2: mindset shift towards user centric testing. It's about building software
Speaker 2: that's not just functional, but also delightful, accessible, and truly
Speaker 2: valuable to the people who use it. And remember, the
Speaker 2: tools we talked about today are just the starting point.
Speaker 2: The real power of RTL lies in its ability to
Speaker 2: help us think differently about testing and build a culture
Speaker 2: of quality in our development process.
Speaker 1: I love that it's not just about the code, it's
Speaker 1: about the people exactly.
Speaker 2: So as you continue your journey with React Testing Library,
Speaker 2: always remember to keep the user at the center of
Speaker 2: your thinking. Ask yourself, how can my tests reflect the
Speaker 2: real world experiences of my users and strive to create
Speaker 2: software that not only works, but also makes a positive
Speaker 2: impact on the world.
Speaker 1: That's a fantastic message. Thanks for sharing your expertise with
Speaker 1: us today. It's been a really eye opening conversation.
Speaker 2: The pleasure was online. It's been great chatting about testing
Speaker 2: all right.
Speaker 1: Welcome back to our React Testing Library deep dive. I
Speaker 1: feel like we've covered so much already, but I'm sure
Speaker 1: there's even more to uncover.
Speaker 2: Oh absolutely, We've gone deep on the tools and the
Speaker 2: how to, But now I think it's time to like
Speaker 2: zoom out a bit see the bigger picture of what
Speaker 2: we've learned.
Speaker 1: Okay, I like that. Yeah, So beyond just you know,
Speaker 1: writing better tests, what's the bigger takeaway here?
Speaker 2: Well, I think this whole shift toward user centric testing
Speaker 2: it really changes how we think about software quality. It's
Speaker 2: not just does the code work anymore? It's more about, like,
Speaker 2: does this actually serve the people using it?
Speaker 1: Right? Because at the end of the day, we're building
Speaker 1: stuff for humans, not for computers exactly.
Speaker 2: And this user centric idea it goes way beyond just software.
Speaker 2: Think about any product you use, your car, your phone, website.
Speaker 1: Yeah, they've all been designed with the user in mind,
Speaker 1: haven't they.
Speaker 2: For sure, the best products are the ones that just
Speaker 2: like fit seamlessly into your life. They anticipate what you need,
Speaker 2: they make the experience enjoyable.
Speaker 1: And that's what RTL helps us do with software. By
Speaker 1: focusing on the user, we can build apps that are
Speaker 1: not just functional, but also intuitive and fun to use,
Speaker 1: things that people actually want.
Speaker 2: To use You nailed it, And there's another piece to
Speaker 2: this user centric approach accessibility, making sure our apps work
Speaker 2: for everyone, regardless of their abilities. That's not just about
Speaker 2: being ethically responsible, it's about creating a truly user friendly
Speaker 2: experience for everyone.
Speaker 1: Yeah, that's a really good point. I've got a friend
Speaker 1: who uses a screen reader and she's always running into
Speaker 1: websites and apps that are just impossible to navigate. It's
Speaker 1: a huge problem.
Speaker 2: It really is, and thankfully URTL can help a lot
Speaker 2: with that. When we're testing from the user's point of view,
Speaker 2: we naturally start thinking about how people with different abilities
Speaker 2: might use our app.
Speaker 1: So like if we're testing a form, we might make
Speaker 1: sure it works well with just the keyboard, or that
Speaker 1: it gives clear instructions for screen reader users exactly.
Speaker 2: And there are even tools to help with this. The
Speaker 2: book talked about jest acts, which is a library that
Speaker 2: can run automated accessibility checks on your React components.
Speaker 1: So it's like having an accessibility the expert built right
Speaker 1: into your testing process.
Speaker 2: Pretty much, and by using just x you can catch
Speaker 2: those accessibility issues early on before they become a problem
Speaker 2: for your users.
Speaker 1: That's awesome. Okay, So as we wrap up our deep
Speaker 1: dive into React Testing Library, What are some of the
Speaker 1: key takeaways you want our listeners to walk away with.
Speaker 2: Well, first off, I want to emphasize again that RTL
Speaker 2: isn't just a testing library. It's a whole philosophy, a
Speaker 2: way of thinking about quality from the user's point of view.
Speaker 1: It's about building software that's not just functional, but delightful
Speaker 1: to use. Yeah, accessible to everyone, and something that genuinely
Speaker 1: brings value to people exactly.
Speaker 2: And all these tools and techniques we talked about, they're
Speaker 2: just the beginning. The real magic of RTL is how
Speaker 2: it changes our mindset about testing and helps us build
Speaker 2: a culture of quality in our teams.
Speaker 1: Yeah, it's not just about the code, it's about the
Speaker 1: people for sure.
Speaker 2: So to everyone listening as you start exploring React Testing Library,
Speaker 2: keep the user at the heart of everything you do.
Speaker 2: Think about how your tests can reflect real world use cases,
Speaker 2: and always try to build software that not only works,
Speaker 2: but also makes a positive difference in the world.
Speaker 1: That's a great message to end on. Thanks so much
Speaker 1: for joining us on this deep dive into a React
Speaker 1: testing library. It's been an awesome and inspiring conversation.
Speaker 2: My pleasure I always love talking about testing.
Speaker 1: And to our listeners, thanks for tuning in to this
Speaker 1: deep dive. We hope you learned a lot about React testing,
Speaker 1: Keep learning, keep exploring, and keep building amazing software.