Component testing with Testing Library in Svelte - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What is the rendered output after clicking the button?

Given this Svelte component test using Testing Library, what will be the text content of the button after the click event?

Svelte

import { render, fireEvent } from '@testing-library/svelte';
import ToggleButton from './ToggleButton.svelte';

test('button toggles text on click', async () => {
  const { getByText } = render(ToggleButton);
  const button = getByText('Off');
  await fireEvent.click(button);
  expect(button.textContent).toBe('On');
});

A "On"

B "Off"

C "Clicked"

D "Error: button not found"

💡 Hint

Think about what the component does when the button is clicked.

The button initially shows "Off". After clicking, the component toggles the text to "On".

📝 Syntax

intermediate

Which option correctly imports Testing Library for Svelte?

Choose the correct import statement to use Testing Library in a Svelte test file.

A import { render, fireEvent } from 'testing-library-svelte';

B import { render, fireEvent } from 'svelte-testing-library';

C import { render, fireEvent } from '@testing-library/svelte';

D import { render, fireEvent } from '@testing-library/react';

💡 Hint

Check the official package name for Testing Library with Svelte.

The official Testing Library package for Svelte is '@testing-library/svelte'. Other options are incorrect or for different frameworks.

🔧 Debug

advanced

Why does this test fail with 'Unable to find an element with the text: Submit'?

Examine the test code below. Why does the test fail with the error 'Unable to find an element with the text: Submit'?

Svelte

import { render } from '@testing-library/svelte';
import FormButton from './FormButton.svelte';

test('renders submit button', () => {
  const { getByText } = render(FormButton, { props: { label: 'Submit' } });
  getByText('Submit');
});

A The getByText method is misspelled and causes an error.

B The FormButton component does not use the 'label' prop to set button text.

C The test forgot to await an async render call.

D The component file path is incorrect, so it renders nothing.

💡 Hint

Check how the component uses props to render text.

If the component does not use the 'label' prop to set the button text, the text 'Submit' won't appear, causing getByText to fail.

❓ state_output

advanced

What is the final count displayed after these interactions?

Given this Svelte counter component test, what is the final number displayed after the clicks?

Svelte

import { render, fireEvent } from '@testing-library/svelte';
import Counter from './Counter.svelte';

test('increments and decrements counter', async () => {
  const { getByText } = render(Counter);
  const incrementBtn = getByText('+');
  const decrementBtn = getByText('-');
  const countDisplay = getByText('0');

  await fireEvent.click(incrementBtn);
  await fireEvent.click(incrementBtn);
  await fireEvent.click(decrementBtn);

  expect(countDisplay.textContent).toBe('1');
});

A 1

B 0

C 2

D -1

💡 Hint

Count how many times the increment and decrement buttons are clicked.

Two increments add 2, one decrement subtracts 1, so final count is 1.

🧠 Conceptual

expert

Which Testing Library query is best for selecting a button by its accessible name?

In Testing Library for Svelte, which query method best selects a button element by its accessible name for accessibility compliance?

A getByLabelText('Submit')

B getByText('Submit')

C getByTestId('submit-button')

D getByRole('button', { name: 'Submit' })

💡 Hint

Consider ARIA roles and accessible names for best practice.

Using getByRole with the 'button' role and accessible name ensures the element is a button and matches the visible accessible accessible label, improving accessibility testing.

Practice

1. What is the main goal of component testing in Svelte using Testing Library?

easy

A. To check if the component behaves correctly from a user's perspective

B. To test the internal variables and functions of the component

C. To measure the performance speed of the component

D. To verify the component's file size and bundle output

Solution

1. Step 1: Understand component testing purpose

   Component testing focuses on how the component behaves and appears to users, not internal code details.

2. Step 2: Match Testing Library's approach

   Testing Library encourages testing visible output and user interactions, aligning with user perspective testing.

3. Final Answer:

   To check if the component behaves correctly from a user's perspective -> Option A

4. Quick Check:

   User-focused testing = To check if the component behaves correctly from a user's perspective [OK]

Hint: Focus on user-visible behavior, not internal code [OK]

Common Mistakes:

• Testing internal variables instead of user output
• Confusing performance testing with component testing
• Checking file size instead of behavior

2. Which of the following is the correct way to import the render function from Testing Library for Svelte?

easy

A. import { render } from 'svelte';

B. import render from 'svelte-testing-library';

C. import { render } from '@testing-library/svelte';

D. import { renderComponent } from '@testing-library/svelte';

Solution

1. Step 1: Identify the official Testing Library package for Svelte

   The official package is '@testing-library/svelte' which exports the render function.

2. Step 2: Check correct import syntax

   The render function is a named export, so it must be imported with curly braces.

3. Final Answer:

   import { render } from '@testing-library/svelte'; -> Option C

4. Quick Check:

   Named import from '@testing-library/svelte' = import { render } from '@testing-library/svelte'; [OK]

Hint: Use named import from '@testing-library/svelte' for render [OK]

Common Mistakes:

• Using default import instead of named import
• Importing from wrong package name
• Using incorrect function name like renderComponent

3. Given this test code snippet, what will be the output of the assertion?

import { render } from '@testing-library/svelte';
import Button from './Button.svelte';

test('button shows correct label', () => {
  const { getByText } = render(Button, { props: { label: 'Click me' } });
  const button = getByText('Click me');
  expect(button).toBeInTheDocument();
});

medium

A. The test fails because the label prop is not passed correctly

B. The test passes because the button with label 'Click me' is rendered

C. The test throws a syntax error due to wrong render usage

D. The test fails because getByText cannot find the button

Solution

1. Step 1: Analyze render usage with props

   The Button component is rendered with prop label set to 'Click me', which should display that text.

2. Step 2: Check getByText and assertion

   getByText('Click me') finds the button element with that text, so expect(button).toBeInTheDocument() passes.

3. Final Answer:

   The test passes because the button with label 'Click me' is rendered -> Option B

4. Quick Check:

   Rendered label found by getByText = The test passes because the button with label 'Click me' is rendered [OK]

Hint: Check if rendered text matches getByText query [OK]

Common Mistakes:

• Assuming getByText fails when text is passed as prop
• Confusing render syntax with props
• Thinking toBeInTheDocument fails without explicit import

4. Identify the error in this test code for a Svelte component using Testing Library:

import { render } from '@testing-library/svelte';
import Counter from './Counter.svelte';

test('increments count on button click', () => {
  const { getByText } = render(Counter);
  const button = getByText('Increment');
  button.click();
  expect(getByText('Count: 1')).toBeInTheDocument();
});

medium

A. Missing import of the Counter component

B. Not passing initial count prop to Counter component

C. Incorrect query getByText for the button label

D. Using button.click() instead of fireEvent.click(button)

Solution

1. Step 1: Check how user events are simulated

   Testing Library requires using fireEvent or userEvent to simulate clicks, not direct button.click() calls.

2. Step 2: Verify other parts of the test

   Counter is imported, getByText queries are correct, and initial props are optional here.

3. Final Answer:

   Using button.click() instead of fireEvent.click(button) -> Option D

4. Quick Check:

   Use fireEvent for clicks, not button.click() [OK]

Hint: Use fireEvent or userEvent for clicks, not element.click() [OK]

Common Mistakes:

• Calling element.click() directly instead of fireEvent
• Forgetting to import the component
• Using wrong text in getByText query

5. You want to test a Svelte component that conditionally shows a message only after a button click. Which Testing Library approach correctly waits for the message to appear before asserting?

import { render, fireEvent, waitFor } from '@testing-library/svelte';
import MessageToggle from './MessageToggle.svelte';

test('shows message after click', async () => {
  const { getByText, queryByText } = render(MessageToggle);
  expect(queryByText('Hello!')).toBeNull();
  const button = getByText('Show Message');
  await fireEvent.click(button);
  await waitFor(() => getByText('Hello!'));
  expect(getByText('Hello!')).toBeInTheDocument();
});

hard

A. This test correctly waits for the message to appear after the click

B. The test fails because waitFor is not needed here

C. The test should use setTimeout instead of waitFor

D. The test is incorrect because queryByText should be replaced with getByText

Solution

1. Step 1: Understand conditional rendering after event

   The message appears only after clicking the button, so the test must wait for it asynchronously.

2. Step 2: Check usage of waitFor and fireEvent

   fireEvent.click simulates the click, and waitFor waits until getByText('Hello!') finds the message, ensuring correct timing.

3. Final Answer:

   This test correctly waits for the message to appear after the click -> Option A

4. Quick Check:

   Use waitFor to await async UI changes = This test correctly waits for the message to appear after the click [OK]

Hint: Use waitFor to handle UI changes after events [OK]

Common Mistakes:

• Not waiting for async UI updates before asserting
• Using setTimeout instead of waitFor
• Confusing queryByText and getByText usage