The `@testing-library` family of packages helps you test UI components in a user-centric way.

You want to write maintainable tests that give you high confidence that your components are working for your users. As a part of this goal, you want your tests to avoid including implementation details so refactors of your components (changes to implementation but not functionality) don't break your tests and slow you and your team down.

Testing Library accomplish these goals so you can be confident your application will work when it gets to the end user.

testing-library

Learn Testing-library

In 2018, Kent C. Dodds wrote: "The more your tests resemble the way your software is used, the more confidence they can give you." This phrase became the guiding principle for the entire Testing Library ecosystem. 

A few years later, the React Testing Library became the de facto library for writing unit and integration tests in the React ecosystem.

Thanks to its user-centric perspective, our tests are closer to our user experience and far away from implementation details.

In this course, you will learn how to:

- render your components
- properly query your UI for elements while keeping accessibility and your users' experience in mind
- improve your testing experience with the usage of some utilities
- interact with your components to fire events
- leverage asynchronous utilities to customize your testing flow
- get rid of the annoying "not wrapped in act" warning

After this course, you should be able to write and debug any test using the React Testing Library!

An Introduction to the React Testing Library

For many years, the most annoying thing about writing tests with the React Testing Library is when the "not wrapped in act(...)" warning appears in your console. act is a React testing util that ensures all UI updates are wrapped up before proceeding with your test case. What we often miss is that we actually don't need act and that this error is there to tell us something instead, and that is: You are not testing everything!

In this lesson, we are going to understand why the "not wrapped in act(...)" shows up and how to get rid of it!

Get Rid of the "not wrapped in act(...)" Warning

Sometimes, you might need to wait for an element to disappear from your UI before proceeding with your test setup or making your assertion.

In this lesson, we will learn about a wrapper around the waitFor that allows you to wait until an element is removed from your UI: the *waitForElementToBeRemoved*.

Use the waitForElementToBeRemoved Async Util to Await Until an Element Disappears

After querying and interacting with elements come assertions. Assertions are really important to assert that your test case really works. Sometimes due to the async nature of your code, your assertion might need to wait some time until it passes.

In this lesson, we will learn how to wait for a period of time until our assertion passes by using the *waitFor* util.

Leverage the waitFor Async Util to Await for an Assertion to Pass

Whilst fireEvent helps to interact with elements, that is not how a user interacts with them. When a user interacts with an element, more than a single event is fired. This means that by using fireEvent, we might be missing some scenarios that might be triggered accidentally by other events.

In this lesson, we are going to learn about the companion library of the React Testing Library that allows you to simulate full interactions with your elements: the *user-event* library.

Simulate All User Interactions With an Element by Using the user-event Library

After querying, the next important part of testing is interacting with our UI. To do this we need to fire events.

In this lesson, we are going to learn how we can fire a single event in our elements by using the *fireEvent*!

Fire a Single Event on an Element Using fireEvent

Querying is difficult! Even if we follow the guiding principles and always start from the queries accessible to everyone, we are bound to get stuck sometimes. To help us out, the Testing Playground was created.

In this lesson, we are going to see how to use the Testing Playground to help us know which query we should use for each element on our UI.

Use the Testing Playground to Help Decide Which Query to Pick

When debugging our tests, one important part is understanding how our UI looks after our component renders or after we apply some changes to it.

In this lesson, we are going to review one util that allows us to print to our console a representation of the DOM tree of our elements: the *debug*

Check to Current Way Your Component Looks Using Debug

In the previous lessons, we always destructured our queries for render. As your test grows and you need more queries, this can become annoying very quickly. 

Ideally, we would have an object that is pre-bound to the document.body and allows us to use all the queries without any need for restructuring.

In this lesson, we are going to see how to tidy our code and save some time by using the *screen* util.

Use the Screen Object to Avoid Query Destructuring From Render

Given how web pages are built nowadays, you might find yourself with multiple instances of the same element.

To avoid querying for a list of elements and then filtering them down, you can constrain your query to a specific area.

In this lesson, we are going to learn how to leverage the *within* helper to constrain our query to a specific element.

Constrain a Query to a Specific Element Using Within

Sometimes, none of the queries above will work for you. Instead of focusing on implementation details, the React Testing Library gives you a controlled way of doing so: using data-testid!

In this lesson, we are going to look at the one query that belongs to the TestId family and should be used as a last resort only: the *byTestId* query.

Get Elements With an Associated Test id Attribute Using the byTestId Query

In this lesson, we will look at one of the queries that are part of the semantic queries family and allow you to find an element by its alt text: the *byAltText* query.



Get Elements With a Matching alt Text Attribute Using the byAltText Query

There will be times when none of the queries accessible to everyone will work out for you. When this time arrives, you can resort to the semantic queries. While these queries make use of HTML5 and ARIa-compliant selectors the user experience when using these attributes varies across assistive technology and browsers.

In this lesson, we will look at one of the queries that are part of the semantic queries family and allow you to find an element by its title attribute: the *byTitle* query.



Get Elements With a Matching Title Attribute Using the byTitle Query

Text is one of the main ways that the users of your page find what they are looking for.

In this lesson, we will look at another one of the queries that are part of the queries accessible to everyone's family and really helpful when finding non-interactive elements: the *byText* query.



Get Elements With a Given Text Match Using the byText Query

Navigating a form with a bunch of elements with filled-in values can be a way to refer to certain elements.

In this lesson, we will look at another one of the queries that are part of the queries accessible to everyone's family and helpful when querying for filled-in form values the *byDisplayValue* query.



Get Elements With a Matching Display Value Using the byDisplayValue Query

Sometimes your form might be missing a label. Whilst they are not a label replacement, placeholders can help give feedback about what that element should be for.

In this lesson, we will look at another one of the queries that are part of the queries accessible to everyone's family and also helpful when dealing with forms: the *byPlaceholderText* query.



Get Elements With a Given Placeholder Text Using the byPlaceholderText Query

When interacting with form fields, the user knows what an element is supposed to do, thanks to its label. 

In this lesson, we will look at another one of the queries that are part of the queries accessible to everyone's family and really helpful when dealing with forms: the *byLabelText* query.



Get Elements Associated With a Label Using the byLabelText Query

Following the guiding principles of the testing library, your tests should resemble how your users interact with your code. This mindset also applies to your queries. Each query can be customized from an accessibility perspective.

In this lesson, we will look at one of the queries that are part of the queries accessible to everyone's family and *the one you should always start with*: the *byRole* query.

The reason why you should always start with this query is that this query allows you to query for elements that are exposed in the accessibility tree and will help you find accessibility issues early on in your code!


Get Elements Exposed in the Accessibility Tree Using the byRole Query

Sometimes you may need to get more than just one result from your queries.

In this lesson, you are going to learn how you can leverage the AllBy variant to extend your queries to find an array of elements instead of a single one.

Use the AllBy variant to get Multiple Instances of an Element

In order for you to interact with the elements in your tests, you need to query for them. Well, sometimes, they take time to show up in your UI.

In this lesson, we will learn about one of the query variants that allows you to search for something that you expect to show up eventually in your UI: the findBy*.


Use the findBy Query to get Elements that Will Show up on the Page

In order for you to interact with the elements in your tests, you need to query for them.

In this lesson, we will learn about one of the query variants that allows you to search for something that you expect not to be in your UI: the queryBy*.


Use the queryBy Query to get Elements that Won't Always be on the Page



Discover how to harness the power of Cursor IDE's Composer Agent feature to optimize your code. In this lesson, you'll witness an AI agent doing all the work to generate test suites, implement performance benchmarks, and create optimized function variations - all without writing a single line of code. You'll learn how to validate performance improvements through data-driven benchmarking, ensuring that optimizations are backed by concrete metrics rather than speculation. This hands-on demonstration showcases a groundbreaking approach to automated function development that combines the precision of test-driven development with the efficiency of AI-powered optimization.


Agent-Driven Development in Cursor: Testing, Benchmarking, and Optimizing Functions

This course is aimed for using `zod` effectively in projects based on TypeScript (both browser and node.js). The benefits you gain with this course is not just simply coding, but also understanding when/why/how should you perform runtime validation.

`zod` is the missing piece to TypeScript's capabilities, which can guarantee type-safety only in compile-time.

`zod` can be used whenever the compiler cannot guarantee what happens in runtime. And... it's a very frequent usecase, such as HTTP calls, websockets, etc.

In this course you get quickly up and running by:
1. using `zod` with primitives and objects
2. adapting `zod` quickly to existing projects thanks to automatic generators
3. changing the strategy frm type-first to schema-first
4. using error-throwing `parse` or non-error-throwing `safeParse` basing on your needs
5. applying `zod` to the most common usecase - validating API responses
6. handling errors the most convenient way (out of many!)

Take advantage of runtime validation with `zod`. Take advantage of the detailed lessons in this course 🔥

Effective Runtime Type Checks with Zod


Cursor can now automatically run commands in the terminal and walk step-by-step towards building out your entire project. You give it a goal, then it will suggest the commands you need to run and the files that you need to create and you can work with it to achieve what you're building. This lesson does a quick walkthough of using a Cursor Agent to build a project from scratch and guide it along the way. Cursor Agents definitely feel like a sneak peek at the future of programming!

Cursor Agents Initial Impressions - Allow an AI to Build Your Entire Project

Mock Service Worker is an API mocking library that allows you to write client-agnostic mocks and reuse them across any frameworks, tools, and environments.



Mocking WebSocket APIs with Mock Service Worker


While using anonymous functions might seem convenient, they can create difficulties when trying to identify performance bottlenecks during profiling. This lesson will demonstrate how named functions make it easier to pinpoint and address performance issues, ultimately leading to more efficient and debuggable code. Learning this practice will greatly improve your ability to locate and fix performance issues in complex projects.

Always Name Functions in JavaScript


When attempting to load the same module twice in JavaScript you'll hit a cache and code won't re-run. In scenarios where you actually do want to have state in your modules, you'll have to use a cache-busting technique by passing a query parameter to a dynamic import. This lesson walks through how to add a query parameter, how to add the appropriate types for loading dynamic modules in TypeScript, and when these techniques are valuable.

Import the Same JavaScript Module Multiple Times with Cache Busting



The include keyword in GitHub Actions empowers you to add custom variables to your matrix strategy, providing flexibility beyond standard configurations. In this video, we'll explore how include allows you to define specific combinations of variables, enhancing control over your workflow runs. You'll see how this feature enables you to tailor jobs for unique environments or scenarios not covered by the default matrix options. By leveraging include, you can efficiently manage complex build processes with greater precision. This technique helps you streamline your CI/CD pipeline, making it more adaptable to your project's evolving needs.

Use GitHub Actions Matrix Include for Complex Job Configurations

While running `zod` schema validation agains domain-rich objects, the error message saying that _a string is not a number_ might not be really useful.

Especially, when you need to provide a meaningful feeback to the user, e.g. after they have submitted a form with lots of data.

`zod` allows to customize messages on a very granular level. We can also extract repeatable customization to `zod` error maps.

Finally, in order to process an error message further (e.g. display it to the user), we need to handle the `zod` validation errors effectively. Especially, when a big object validation has failed and we could receive a handful of errors.

That's what we learn in this lesson. 🔥

Customize zod Error Messages and Handle zod Errors Effectively

customize zod validation messages, customize zod schema property messages, reuse error maps across different schemas, navigate through zod error objects

You might want to run `zod` schema checks in different styles.

Sometimes you prefer to conditionally throw the error - that's what `parse` does. But another time you'd prefer to receive a `boolean` property that determines whether the validation was successful or not - and perform further actions accordingly.

Additionally, the error-throwing API of `parse` works extremely well with [TypeScript assertion functions](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html#assertion-functions). Their combination is just... perfect! 👌

That's what we learn in this lesson.

Use parse and safeParse Runtime Type-checks with zod

use zod parse function to conditionally throw ZodError, use zod safeParse to get a boolean value and run typescript type guard over success property

In this lesson we learn that TypeScript cannot guarantee correct shapes of responses. That's due to TS performing checks in compile-time, while the response will be availbale in runtime - when TS doesn't exist anymore.

In some situations, such as HTTP requests, runtime type checks such as `zod` are essential for providing quick feedback around data-related errors.

Understand where are the possible mistakes to make while using TypeScript with HTTP calls. Use `fetch` and `axios` along with `zod` schema checks.

Also, note that similar mistakes or mistakes could happen while using web storage (e.g. `localStorage`)

Validate HTTP API Response with zod, fetch and axios

use zod as an HTTP response validation tool along with fetch and axios in order to make sure that the response has expected data structure

Testing Library

Search Results