Test Automation Framework Vocabulary

A stub returns canned responses; a mock verifies interactions; a spy records real calls; a fake is a lightweight working implementation.

The scenario explicitly states "no need to verify how many times it was called" — this rules out a mock (which sets expectations and fails tests when they're not met) and a spy (which records calls for later assertion). A fake would be a real in-memory implementation, which is heavier than needed here. A stub is the exact fit: you pre-configure it to return a success response, use it in the test to isolate the email dependency, and never assert anything about its call history.

Key vocabulary:
• Stub — returns hard-coded/pre-configured responses; no interaction verification
• Mock — pre-programmed with expectations; test fails if expectations are not met
• Spy — wraps a real object and records calls; asserted after the fact
• Fake — a simplified but working implementation (e.g. in-memory DB, fake SMTP server)
• Test double — the umbrella term for any object replacing a real dependency in a test

beforeEach runs before every test — it's the standard way to reset state and prevent test pollution.

Option A describes beforeAll — which runs once before all tests in the block. Option B describes something like afterEach (runs after each test). Option C describes afterAll — which runs once when all tests in the block finish. beforeEach specifically runs its callback immediately before each individual it() or test() call, making it ideal for resetting mocks (e.g. jest.resetAllMocks()), recreating test fixtures, or reinitialising the system under test — so each test starts from a known, isolated state.

Key vocabulary:
• beforeEach — runs setup before every individual test in the enclosing describe block
• afterEach — runs teardown/cleanup after every individual test
• beforeAll — runs once before all tests in the block (expensive setup, e.g. DB connection)
• afterAll — runs once after all tests complete (e.g. close DB connection, delete temp files)
• Test pollution — when state from one test accidentally affects the result of another

toContain checks for inclusion — not equality, not prefix, not object keys.

Option A describes toEqual or toBe — which require the entire value to match. Option B describes a toMatch with a start-anchor regex. Option D describes a property-access assertion (e.g. toHaveProperty). toContain is specifically an inclusion check: for strings it verifies the substring is present anywhere in the value; for arrays it verifies the element exists in the array. So expect('payment success confirmed').toContain('success') passes, and expect(['error','success']).toContain('success') also passes.

Key vocabulary:
• toContain — asserts that a string includes a substring or an array includes an element
• toEqual — asserts deep equality (entire structure and value must match)
• toBe — asserts strict reference equality (===)
• toMatch — asserts a string matches a regex or substring pattern
• toHaveProperty — asserts an object has a specified key (and optionally a specific value)

The test pyramid prescribes: many unit tests → fewer integration tests → very few E2E tests.

Option A is wrong: the pyramid deliberately recommends more unit tests than anything else for speed and isolation. Option B is an architectural opinion, not the core pyramid principle. Option D is incorrect: E2E tests are slow, brittle, and cannot isolate the cause of failures — they are a poor substitute for unit tests. The classic pyramid problem is having too many E2E tests relative to the layers below them. 500 E2E vs. 150 integration tests is an inverted ratio: E2E tests are slower, more expensive, and harder to debug, so having more of them than integration tests creates a fragile, slow suite.

Key vocabulary:
• Test pyramid — a model prescribing: many unit tests, fewer integration tests, fewest E2E tests
• E2E (end-to-end) test — tests the full system from UI to database; slow and brittle
• Integration test — tests interactions between two or more components or services
• Unit test — tests a single function or class in isolation; fastest and most deterministic
• Inverted pyramid (ice cream cone) — anti-pattern with too many slow E2E tests and too few unit tests

Flaky tests fail non-deterministically — they do not indicate a code regression, but they do degrade pipeline reliability.

Option A describes a regression — a reproducible, deterministic failure caused by a code change. Option B describes a performance issue, not a flakiness report. Option C describes a configuration error, which would typically manifest as an error/skipped status, not "flaky." Flaky tests are the specific term for tests that produce inconsistent results without code changes — often due to race conditions, hardcoded timeouts, shared state, or external service dependencies. Best practice is to quarantine them (tag and skip in main), file a ticket, and investigate root causes before re-enabling.

Key vocabulary:
• Flaky test — a test that non-deterministically passes and fails without code changes
• Non-deterministic — producing different outputs from the same inputs on different runs
• Quarantine — isolating flaky tests from the main pipeline to prevent false build failures
• Race condition — a timing-dependent bug where test outcome depends on execution order
• Build red / build green — CI pipeline status: red = failing tests; green = all tests pass