Practice: test keyboard navigation

A roving-tabindex Toolbar plus the keyboard test suite a senior interviewer expects: ArrowLeft/Right wrap, Home/End jump, Tab leaves the region.

// Component under test: a small toolbar that uses roving tabindex.
type ToolbarProps = {
  actions: Array<{ id: string; label: string; onRun: () => void }>;
};

export function Toolbar({ actions }: ToolbarProps) {
  const [activeIndex, setActiveIndex] = React.useState(0);
  const buttons = React.useRef<Array<HTMLButtonElement | null>>([]);

  function moveFocus(index: number) {
    const next = ((index % actions.length) + actions.length) % actions.length;
    setActiveIndex(next);
    buttons.current[next]?.focus();
  }

  return (
    <div role="toolbar" aria-label="Document actions">
      {actions.map((action, index) => (
        <button
          key={action.id}
          ref={(node)=> {
            buttons.current[index]= node;
          }}
          type="button"
          tabIndex={index= activeIndex ? 0 : -1}
          onClick={action.onRun}
          onKeyDown={(event)=> {
            if (event.key= 'ArrowRight') {
              event.preventDefault();
              moveFocus(index + 1);
            } else if (event.key= 'ArrowLeft') {
              event.preventDefault();
              moveFocus(index - 1);
            } else if (event.key= 'Home') {
              event.preventDefault();
              moveFocus(0);
            } else if (event.key= 'End') {
              event.preventDefault();
              moveFocus(actions.length - 1);
            }
          }}
        >
          {action.label}
        </button>
      ))}
    </div>
  );
}

UI interview practice should behave like component documentation, not a static snippet. This uses the same isolation pattern as Storybook, Sandpack, CodeSandbox, and StackBlitz: editable source on one side, a sandboxed browser preview on the other. Edit the DOM code, run it, and verify focus, keyboard, pointer, and state behavior in the preview.

Convert the answer into observable behavior. In a mid-senior interview, say which behaviors are covered by unit tests, interaction tests, accessibility checks, and one browser smoke path.

import { describe, it, expect, vi } from 'vitest';
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';

describe('Toolbar keyboard navigation', () => {
  const actions = [
    { id: 'bold', label: 'Bold', onRun: vi.fn() },
    { id: 'italic', label: 'Italic', onRun: vi.fn() },
    { id: 'link', label: 'Link', onRun: vi.fn() },
  ];

  it('only the active button is in the page tab order', () => {
    render(<Toolbar actions={actions} />);
    const bold = screen.getByRole('button', { name: 'Bold' });
    const italic = screen.getByRole('button', { name: 'Italic' });
    expect(bold).toHaveAttribute('tabindex', '0');
    expect(italic).toHaveAttribute('tabindex', '-1');
  });

  it('ArrowRight moves focus and tabindex', async () => {
    const user = userEvent.setup();
    render(<Toolbar actions={actions} />);
    screen.getByRole('button', { name: 'Bold' }).focus();
    await user.keyboard('{ArrowRight}');
    expect(screen.getByRole('button', { name: 'Italic' })).toHaveFocus();
    expect(screen.getByRole('button', { name: 'Italic' })).toHaveAttribute('tabindex', '0');
    expect(screen.getByRole('button', { name: 'Bold' })).toHaveAttribute('tabindex', '-1');
  });

  it('ArrowLeft from the first button wraps to the last', async () => {
    const user = userEvent.setup();
    render(<Toolbar actions={actions} />);
    screen.getByRole('button', { name: 'Bold' }).focus();
    await user.keyboard('{ArrowLeft}');
    expect(screen.getByRole('button', { name: 'Link' })).toHaveFocus();
  });

  it('Home and End jump to extremes', async () => {
    const user = userEvent.setup();
    render(<Toolbar actions={actions} />);
    screen.getByRole('button', { name: 'Italic' }).focus();
    await user.keyboard('{End}');
    expect(screen.getByRole('button', { name: 'Link' })).toHaveFocus();
    await user.keyboard('{Home}');
    expect(screen.getByRole('button', { name: 'Bold' })).toHaveFocus();
  });

  it('Tab leaves the toolbar entirely instead of cycling between buttons', async () => {
    const user = userEvent.setup();
    render(
      <>
        <Toolbar actions={actions} />
        <button type="button">Outside</button>
      </>
    );
    screen.getByRole('button', { name: 'Bold' }).focus();
    await user.keyboard('{Tab}');
    expect(screen.getByRole('button', { name: 'Outside' })).toHaveFocus();
  });
});

Shows whether you can prove frontend behavior instead of relying on screenshots or manual confidence.

• Choose unit, integration, E2E, visual, or performance testing deliberately.
• State the failure that the test catches.
• Avoid brittle assertions that lock implementation details.

• Start with the user-impacting behavior.
• Pick the smallest test that sees that behavior.
• Add one higher-level test only when timing, browser behavior, or integration risk requires it.

• Unit tests are fast and precise but cannot prove browser wiring.
• E2E tests are realistic but should be reserved for workflows where integration risk matters.

• Out-of-order async results.
• Environment-specific browser behavior.
• False confidence from mocks that do not match production contracts.

• Regression case for the named risk.
• Negative path or error state.
• Cleanup or retry behavior when relevant.

• What would make this test flaky?
• What would you monitor after shipping the fix?