Frontend Testing Questions

Common Testing Questions

Q: What is the testing pyramid?

The testing pyramid is a model for distributing test types:

• Unit tests (70%): Fast, isolated, test individual functions
• Integration tests (20%): Test component interactions, API integrations
• E2E tests (10%): Slow, expensive, test complete user journeys

Q: Why test from user's perspective?

React Testing Library tests from user perspective because:

1. Tests are more robust to implementation changes
2. Tests validate actual user behavior
3. Tests serve as documentation
4. Tests catch accessibility issues

Q: What is test isolation?

Each test should be independent:

• No shared state between tests
• Clean up after each test
• Mock external dependencies
• Use beforeEach/afterEach for setup/cleanup

Q: How do you test error boundaries?

describe('ErrorBoundary', () => {
  it('should catch errors', () => {
    const ErrorComponent = () => { throw new Error('Test error'); };
    
    render(
      <ErrorBoundary>
        <ErrorComponent />
      </ErrorBoundary>
    );

    expect(screen.getByText('Something went wrong')).toBeInTheDocument();
  });
});

Debugging Tests

Common Issues

1. Element not found

// Wrong: Using getBy when element doesn't exist yet
const element = screen.getByText('Loading');

// Correct: Use findBy for async
const element = await screen.findByText('Loaded');

// Correct: Use queryByText to check absence
const element = screen.queryByText('Loading');
expect(element).not.toBeInTheDocument();

2. Async issues

// Wrong: Not waiting for async
render(<AsyncComponent />);
expect(screen.getByText('Done')).toBeInTheDocument();

// Correct: Wait for assertion
render(<AsyncComponent />);
await waitFor(() => {
  expect(screen.getByText('Done')).toBeInTheDocument();
});

3. Mock not working

// Wrong: Mocking after import
import { fetchData } from './api';
jest.mock('./api');

// Correct: Mock before import
jest.mock('./api');
import { fetchData } from './api';

Debugging Tools

// screen.debug() - print DOM
render(<MyComponent />);
screen.debug();

// screen.debug(element) - print specific element
const button = screen.getByRole('button');
screen.debug(button);

// logRoles - show accessible roles
import { logRoles } from '@testing-library/dom';
const { container } = render(<MyComponent />);
logRoles(container);

Testing Library Queries

// Check what's in the DOM
screen.logTestingPlaygroundURL();

// Or use the browser extension
// Testing Playground Chrome Extension

Test Coverage

Coverage Metrics

1. Statement coverage: % of statements executed
2. Branch coverage: % of branches (if/else) taken
3. Function coverage: % of functions called
4. Line coverage: % of lines executed

Jest Coverage Config

// jest.config.js
module.exports = {
  collectCoverageFrom: [
    'src/**/*.{js,jsx,ts,tsx}',
    '!src/**/*.d.ts',
    '!src/index.tsx',
    '!src/reportWebVitals.ts',
  ],
  coverageThreshold: {
    global: {
      branches: 80,
      functions: 80,
      lines: 80,
      statements: 80,
    },
  },
};

Running with Coverage

jest --coverage

# Or in package.json
{
  "scripts": {
    "test:coverage": "jest --coverage --coverageReporters=text-lcov"
  }
}

Coverage Reports

// HTML report
jest --coverage --coverageReporters=html

// LCOV for CI
jest --coverage --coverageReporters=lcov

// Text for terminal
jest --coverage --coverageReporters=text

What Coverage Doesn't Tell You

1. Missing tests: Code without tests
2. Missing assertions: Tests that don't assert
3. Missing edge cases: Not all paths tested
4. Missing error handling: Error paths not tested

Good Coverage Targets

Metric	Target
Statements	80%+
Branches	75%+
Functions	80%+
Lines	80%+

Anti-Patterns

1. Chasing 100% coverage: Diminishing returns
2. Testing implementation details: Tests break when code changes
3. Ignoring flaky tests: Fix or delete them
4. Not testing error paths: Errors happen in production