Firing Events | Testing Library

Excerpt

Note

Note

Most projects have a few use cases for fireEvent, but the majority of the time you should probably use [@testing-library/user-event](https: //testing-library.com/docs/ecosystem-user-event).

fireEvent

Fire DOM events.

fireEvent[eventName]

Convenience methods for firing DOM events. Check out [src/event-map.js](https: //github.com/testing-library/dom-testing-library/blob/master/src/event-map.js) for a full list as well as default eventProperties.

target: When an event is dispatched on an element, the event has the subjected element on a property called target. As a convenience, if you provide a target property in the eventProperties (second argument), then those properties will be assigned to the node which is receiving the event.

This is particularly useful for a change event:

dataTransfer: Drag events have a dataTransfer property that contains data transferred during the operation. As a convenience, if you provide a dataTransfer property in the eventProperties (second argument), then those properties will be added to the event.

This should predominantly be used for testing drag and drop interactions.

Keyboard events: There are three event types related to keyboard input - keyPress, keyDown, and keyUp. When firing these you need to reference an element in the DOM and the key you want to fire.

You can find out which key code to use at [https: //keycode.info/](https: //keycode.info).

createEvent[eventName]

Convenience methods for creating DOM events that can then be fired by fireEvent, allowing you to have a reference to the event created: this might be useful if you need to access event properties that cannot be initiated programmatically (such as timeStamp).

You can also create generic events:

Using Jest Function Mocks

[Jest's Mock functions](https: //jestjs.io/docs/en/mock-functions) can be used to test that a callback passed to the function was called, or what it was called when the event that should trigger the callback function does trigger the bound callback.

• React

About Queries | Testing Library

Excerpt

Overview

Overview

Queries are the methods that Testing Library gives you to find elements on the page. There are several ("get", "find", "query"); the difference between them is whether the query will throw an error if no element is found or if it will return a Promise and retry. Depending on what page content you are selecting, different queries may be more or less appropriate. See the for recommendations on how to make use of semantic queries to test your page in the most accessible way.

After selecting an element, you can use the or to fire events and simulate user interactions with the page, or use Jest and to make assertions about the element.

There are Testing Library helper methods that work with queries. As elements appear and disappear in response to actions, like or can be used to await the changes in the DOM. To find only elements that are children of a specific element, you can use . If necessary, there are also a few options you can , like the timeout for retries and the default testID attribute.

Example

Types of Queries

• Single Elements

  • getBy...: Returns the matching node for a query, and throw a descriptive error if no elements match or if more than one match is found (use getAllBy instead if more than one element is expected).

Summary Table

Priority

Based on , your test should resemble how users interact with your code (component, page, etc.) as much as possible. With this in mind, we recommend this order of priority:

1. Queries Accessible to Everyone Queries that reflect the experience of visual/mouse users as well as those that use assistive technology.

   1. getByRole: This can be used to query every element that is exposed in the . With the name option you can filter the returned elements by their . This should be your top preference for just about everything. There's not much you can't get with this (if you can't, it's possible your UI is inaccessible). Most often, this will be used with the name option like so:

Using Queries

The base queries from DOM Testing Library require you to pass a container as the first argument. Most framework-implementations of Testing Library provide a pre-bound version of these queries when you render your components with them which means you do not have to provide a container. In addition, if you just want to query document.body then you can use the export as demonstrated below (using screen is recommended).

The primary argument to a query can be a string, regular expression, or function. There are also options to adjust how node text is parsed. See for documentation on what can be passed to a query.

Given the following DOM elements (which can be rendered by React, Vue, Angular, or plain HTML code):

You can use a query to find an element (byLabelText, in this case):

screen

All of the queries exported by DOM Testing Library accept a container as the first argument. Because querying the entire document.body is very common, DOM Testing Library also exports a screen object which has every query that is pre-bound to document.body (using the functionality). Wrappers such as React Testing Library re-export screen so you can use it the same way.

Here's how you use it:

• Native

• React

• Cypress

Note

You need a global DOM environment to use screen. If you're using jest, with the set to jsdom, a global DOM environment will be available for you.

If you're loading your test with a script tag, make sure it comes after the body. An example can be seen .

TextMatch

Most of the query APIs take a TextMatch as an argument, which means the argument can be either a string, regex, or a function which returns true for a match and false for a mismatch.

TextMatch Examples

Given the following HTML:

Will** find the div:**

Will not** find the div:**

Precision

Queries that take a TextMatch also accept an object as the final argument that can contain options that affect the precision of string matching:

• exact: Defaults to true; matches full strings, case-sensitive. When false, matches substrings and is not case-sensitive.

  • exact has no effect on regex or function arguments.

Normalization

Before running any matching logic against text in the DOM, DOM Testing Library automatically normalizes that text. By default, normalization consists of trimming whitespace from the start and end of text, and collapsing multiple adjacent whitespace characters into a single space.

If you want to prevent that normalization, or provide alternative normalization (e.g. to remove Unicode control characters), you can provide a normalizer function in the options object. This function will be given a string and is expected to return a normalized version of that string.

Note

Specifying a value for normalizer replaces the built-in normalization, but you can call getDefaultNormalizer to obtain a built-in normalizer, either to adjust that normalization or to call it from your own normalizer.

getDefaultNormalizer takes an options object which allows the selection of behaviour:

• trim: Defaults to true. Trims leading and trailing whitespace

• collapseWhitespace: Defaults to true. Collapses inner whitespace (newlines, tabs, repeated spaces) into a single space.

Normalization Examples

To perform a match against text without trimming:

To override normalization to remove some Unicode characters whilst keeping some (but not all) of the built-in normalization behavior:

Debugging

screen.debug()

For convenience screen also exposes a debug method in addition to the queries. This method is essentially a shortcut for console.log(prettyDOM()). It supports debugging the document, a single element, or an array of elements.

screen.logTestingPlaygroundURL()

For debugging using , screen exposes this convenient method which logs a URL that can be opened in a browser.

Manual Queries

On top of the queries provided by the testing library, you can use the regular to query elements. Note that using this as an escape hatch to query by class or id is not recommended because they are invisible to the user. Use a testid if you have to, to make your intention to fall back to non-semantic queries clear and establish a stable API contract in the HTML.

Browser extension

Do you still have problems knowing how to use Testing Library queries?

There is a very cool Browser extension for and named Testing Playground, and it helps you find the best queries to select elements. It allows you to inspect the element hierarchies in the Browser's Developer Tools, and provides you with suggestions on how to select them, while encouraging good testing practices.

Playground

If you want to get more familiar with these queries, you can try them out on . Testing Playground is an interactive sandbox where you can run different queries against your own html, and get visual feedback matching the rules mentioned above.