# Test Strategy Quiz

## Question 1

In the classic test pyramid, which layer should have the most tests?

A) Integration tests
B) End-to-end tests
C) Unit tests
D) All layers should have roughly equal numbers

<!-- ANSWER: C -->
<!-- EXPLANATION: The test pyramid recommends many fast, cheap unit tests at the base; fewer integration tests in the middle; and few slow e2e tests at the top. Unit tests run quickly and give fast feedback. -->

## Question 2

What is the main difference between a stub and a mock?

A) Stubs are faster; mocks are slower
B) A stub returns canned data; a mock verifies it was called with expectations
C) Stubs are for unit tests; mocks are for integration tests
D) There is no meaningful difference

<!-- ANSWER: B -->
<!-- EXPLANATION: A stub provides fake responses so the code under test can run—you don't verify how it was used. A mock lets you assert that it was called with specific arguments. Stubs fake; mocks verify. -->

## Question 3

Which of these is generally NOT recommended to test?

A) Business logic that computes tax based on state and subtotal
B) A thin wrapper that calls axios.get and returns response.data
C) Edge cases (empty list, boundary values)
D) Error paths (invalid input, network failure)

<!-- ANSWER: B -->
<!-- EXPLANATION: Thin wrappers over third-party code add little value to test—you're mostly testing the library. Business logic, edge cases, and error paths are high-value targets. You might add one smoke test for the wrapper. -->

## Question 4

When might a team use a "diamond" or "trophy" test shape instead of the classic pyramid?

A) When they want fewer unit tests
B) When business logic lives in integration layers and they test what matters where it matters
C) When e2e tests are faster than unit tests
D) When they have no integration tests

<!-- ANSWER: B -->
<!-- EXPLANATION: The diamond/trophy inverts the pyramid: more integration tests than unit tests. Teams use it when critical logic lives in components working together (DB, API, services). The principle: test what matters, where it matters. -->

## Question 5

Why might you run e2e tests only on merge to main, not on every PR?

A) E2E tests are less important than unit tests
B) E2E tests are slow and expensive; unit + integration on every PR gives fast feedback; e2e catches integration issues less frequently
C) E2E tests require manual approval
D) E2E tests cannot run in CI

<!-- ANSWER: B -->
<!-- EXPLANATION: E2E tests are valuable but slow. Running them on every PR increases feedback time. Many teams run unit + integration on every commit/PR for fast feedback, and run e2e on merge to main or nightly to balance speed and confidence. -->

## Question 6

Which assertion is most likely testing implementation details rather than behavior?

A) Assert that the user's name appears on the screen after login
B) Assert that the API was called with the correct parameters
C) Assert that useEffect was called exactly twice
D) Assert that the response status is 200

<!-- ANSWER: C -->
<!-- EXPLANATION: useEffect count is an implementation detail—if you refactor to a different hook or pattern, the test breaks even though user-visible behavior is unchanged. Asserting rendered output, API calls, or response status tests behavior. -->

## Question 7

<!-- VISUAL: drag-order -->

Put these test pyramid layers in order from base (most tests) to top (fewest tests):

A) Integration tests
B) Unit tests
C) End-to-end tests

<!-- ANSWER: B,A,C -->
<!-- EXPLANATION: The pyramid has many unit tests at the base (B), fewer integration tests in the middle (A), and few e2e tests at the top (C). -->

## Question 8

<!-- VISUAL: matching -->

Match each test type to its primary purpose:

A) Unit test → 1) Verify the full system works together (UI + backend + DB)
B) Integration test → 2) Verify a single function or class in isolation
C) E2E test → 3) Verify components work together (API + DB, or module + service)

<!-- ANSWER: A2,B3,C1 -->
<!-- EXPLANATION: Unit tests isolate small units (2). Integration tests verify component interaction (3). E2E tests exercise the full stack (1). -->