Integration testing with Testing Library in Remix - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What does this Remix component render after user interaction?

Consider this Remix component tested with Testing Library. What will be the visible text after clicking the button?

Remix

import { useState } from 'react';

export default function Counter() {
  const [count, setCount] = useState(0);
  return (
    <>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </>
  );
}

A Count: NaN

B Count: 0

C Count: undefined

D Count: 1

💡 Hint

Think about what happens when the button's onClick handler runs.

Clicking the button calls setCount with count + 1, increasing count from 0 to 1, so the text updates to 'Count: 1'.

📝 Syntax

intermediate

Which Testing Library query correctly selects a button with label 'Submit'?

In a Remix integration test, which query correctly selects the button with the text 'Submit'?

A screen.getByRole('button', { name: /Submit/i })

B screen.getByText('button', { name: 'Submit' })

C screen.queryByPlaceholderText('Submit')

D screen.getByLabelText('Submit')

💡 Hint

Buttons have a role of 'button' and accessible name is the visible text.

getByRole with role 'button' and name matching 'Submit' correctly finds the button. getByText does not take a name option. getByLabelText is for form labels. queryByPlaceholderText is for input placeholders.

❓ state_output

advanced

What is the final text content after this Remix form submission test?

Given this test snippet, what text will be visible after the form submission completes?

Remix

import { render, screen, fireEvent, waitFor } from '@testing-library/react';
import ContactForm from '~/components/ContactForm';

render(<ContactForm />);

fireEvent.change(screen.getByLabelText(/email/i), { target: { value: '[e-mail]' } });
fireEvent.click(screen.getByRole('button', { name: /send/i }));

await waitFor(() => screen.getByText(/thank you/i));

A "Error: Email is required"

B "Send"

C "Thank you for contacting us!"

D "Loading..."

💡 Hint

Think about what the form shows after successful submission.

The test waits for the text containing 'thank you', which appears after successful submission, so the final visible text is 'Thank you for contacting us!'.

🔧 Debug

advanced

Why does this Remix integration test fail with a timeout error?

Review this test code snippet. Why does it fail with a timeout waiting for the success message?

Remix

import { render, screen, fireEvent } from '@testing-library/react';
import Login from '~/components/Login';

render(<Login />);

fireEvent.click(screen.getByRole('button', { name: /login/i }));

screen.getByText(/welcome back/i);

A The button role is incorrect and cannot be found.

B The test does not wait asynchronously for the success message to appear.

C The component does not render any text after clicking the button.

D The test uses fireEvent instead of userEvent, causing failure.

💡 Hint

Think about how Testing Library handles async UI updates.

The success message appears asynchronously after clicking login, so the test must wait (e.g., with waitFor or findByText). Without waiting, getByText throws a timeout error.

🧠 Conceptual

expert

Which Testing Library approach best ensures accessibility in Remix integration tests?

When writing integration tests for Remix apps, which approach best supports accessibility testing?

A Selecting elements by their accessible roles and names using <code>getByRole</code> with name options.

B Selecting elements by their CSS class names for precise targeting.

C Using <code>getByTestId</code> attributes to find elements quickly.

D Selecting elements by their text content only with <code>getByText</code>.

💡 Hint

Accessibility means using roles and names that assistive tech relies on.

Using getByRole with accessible names mimics how users with assistive technologies interact with the UI, ensuring tests reflect real accessibility. Selecting by class or test IDs does not guarantee accessibility. getByText alone may miss semantic roles.