testing-library / testing-library/react-testing-library

React-Aria Component Combobox is not Fully rendering in Consuming Application Tests

Open
#1,339 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
JavaScript
Stars
19.7k
Forks
1.2k
Avg merge
3d 16h
Merged PRs (30d)
1

Description

Our Various Versions of Things
  • Testing Framework and version:
    "@testing-library/jest-dom": "^5.16.5",
    "@testing-library/react": "^14.0.0",
    "@testing-library/user-event": "^14.4.3",
    "vitest": "^1.5.3"

  • DOM Environment:
    "jsdom": "^21.1.0",

  • React & Node Versions:
    "@types/node": "18.14.6",
    "@types/react": "^18.2.45",
    "@types/react-dom": "18.0.11",

Relevant code or config:
it('should call to "MYAPI" when I enter values into my input', async () => {
		const user = userEvent.setup();
		const searchTerm = 'racc';
		const myContext = {...mockContext};
		renderContext(myContext)

		// click radio button for input to appear
		const showInputRadio = await screen.findAllByRole('radio', { name: 'Yes' });
		showInputRadio[0].click();
		// type our search in here
		// Here's the ISSUE spot: the input here is not being fully rendered / doesn't have all of the aria values & roles
		const input = screen.getByPlaceholderText('Type to Start Searching...');
		input.click();
		await user.type(input, searchTerm);

		await waitFor(() => {
			expect(fetchMock).toHaveBeenCalledWith(
				`/api/MYAPI?term=${searchTerm}`,
				buildRequestBody({}, 'GET')
			)
			expect(fetchMock).toHaveBeenCalledTimes(2);
		})
	})
What you did:

We built a component library for internal use at our company using React-Aria components. We ingest / consume the library in a separate application.

What happened / Problem Description:

Our components will render fully within the component library and can be tested to their full functionality: clicking, typing, searching, hit's api... etc. We confirmed that it works on our local & dev branches when running normally.

However, when we run our tests in the consuming application the input box that get's rendered in the testing dom is not fully filled out and the interactions do not properly execute. In this particular instance, we cannot type into the input to trigger the API call.

Example of Input rendered within our component tests...

Screenshot 2024-07-01 at 12 11 40 PM

Example of Input rendered within our consuming application using the same component...

Screenshot 2024-07-01 at 12 13 12 PM

Reproduction:

Unfortunately it is not possible in this situation to setup an example.

Suggested solution, sorry, we don't really have one

We have tried a mix of userEvent.type and fireEvent.change to alter the input's value.
we have tried firing those events at different levels of the component.
We have tried selecting using different methodologies (find, query, get) on different values (test-id, placeholder, role... etc).

Ultimately, we are confused and do not know why it is not rendering fully in the tests even though it works within the application itself. It's a definite turning point for us because if we can't test the components that we create outside of the library we're gonna have to scrap it and start over.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the consuming-application test shown in the issue, including the radio-button selection, placeholder lookup, and userEvent typing. Compare its rendered input with the component-library test output and investigate why the consuming test lacks the expected ARIA values and roles. Done means the input renders fully and typing triggers the expected API request.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, react
Domain
frontend, testing-qa
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.