Testing Interview Questions — Cheat Sheet

Tags: testing, unit-testing, integration-testing, e2e, tdd, mock, jest, qa

Level: intermediate

TL;DR: Core testing methodologies, pyramid distribution, double test doubles, and concise answers for technical software engineering interviews.

Key concepts

Unit tests verify single components or pure functions in total isolation.

Integration tests validate interactions, data contracts, and side effects across modules.

End-to-end (E2E) tests validate end-user journeys against running environments.

The Testing Pyramid favors many unit tests, fewer integration tests, and minimal E2E tests.

Test-Driven Development (TDD) follows the Red-Green-Refactor cycle.

Stubs provide canned answers; mocks verify behavioral expectations and interactions.

Spies wrap real implementations to record arguments and call counts.

Regression testing ensures new code modifications do not break existing behaviors.

Code coverage measures executed lines, branches, or functions during test suites.

High test coverage does not guarantee correctness of business edge cases.

Typical questions and ready answers

Q: How do you decide what to test with unit tests versus integration tests?R: I use unit tests for isolated domain logic and pure algorithms. I reserve integration tests for boundaries involving database queries, external HTTP clients, and cross-service communication.

Q: What is the difference between a mock and a stub?R: A stub provides deterministic canned data without assertions. A mock verifies expected behavior by asserting that specific calls or arguments occurred.

Q: How do you approach legacy code with zero test coverage?R: I write black-box characterization tests at the integration level first. Once behavior is captured safely, I refactor and introduce granular unit tests.

Q: Why can 100% test coverage be misleading?R: High line coverage only proves code executed, not that logic was verified. It often misses corner cases, race conditions, and incorrect requirements.

Q: What makes an automated test suite maintainable?R: Tests must avoid implementation details, test public behavior, run deterministically fast, and avoid shared mutable state between cases.

Q: What is your strategy to eliminate flaky tests?R: I replace arbitrary sleep timers with explicit condition polling, isolate external network dependencies via contracts, and ensure clean test database fixtures.

Pitfalls and common mistakes

Testing internal implementation details instead of observable external behavior.

Over-mocking domain models, leading to false positives when real schemas change.

Using fixed sleep intervals in asynchronous tests instead of polling conditions.

Sharing mutable state across test cases without proper setup and teardown cleanup.

Writing brittle assertions that break on cosmetic or non-functional modifications.

Treating test coverage metrics as targets instead of health indicators.

Snippets and commandsTypeScript

// Jest / Vitest pattern: Arrange, Act, Assert (AAA)
describe("calculateDiscount", () => {
  it("applies 10% discount for orders above 100", () => {
    // Arrange
    const order = { total: 150 };
    // Act
    const result = calculateDiscount(order);
    // Assert
    expect(result).toBe(135);
  });
});

Bash

# Execute unit tests with coverage report
npm test -- --coverage

# Run specific test file in watch mode
npx jest src/services/order.test.ts --watch

To review

[ ] Contract testing with tools like Pact

[ ] Property-based testing principles and edge discovery

[x] Test doubles distinction (dummy, stub, spy, mock, fake)

[x] Red-Green-Refactor TDD cycle

References

Martin Fowler: TestPyramid and Practical Test Pyramid

Kent Beck: Test-Driven Development by Example

Gerard Meszaros: xUnit Test Patterns