Software Engineering

A scenario where multiple edge cases occur at once, making it far rarer and harder to anticipate than any single edge case alone.

A rare but technically valid input or condition that sits at the boundary of what the system was designed to handle.

A test that drives the full application as a user would — through the UI, through the backend, against a real or near-real environment.

A known, reusable block of test data or environment state set up before a test runs, so every test starts from the same baseline.

A test whose pass/fail result varies between runs with no underlying code change, usually due to timing, ordering, or external dependencies.

The scenario where a user provides valid input and everything proceeds exactly as designed, with no errors or edge cases involved.

A test that exercises multiple components together — typically hitting a real database, message queue, or API boundary — to verify the pieces work when assembled.

A test double that stands in for a real dependency and lets you verify how it was called — e.g. that a specific method ran with the expected arguments.

Previously correct behavior that breaks as an unintended side effect of a later, unrelated change.

A test double that returns fixed, predetermined responses regardless of input, used to isolate the code under test from a real dependency.

The percentage of code lines (or branches) executed at least once by the test suite.

A practice where you write the failing test first, then write the minimum code to make it pass, then refactor — the tests drive the design.

A test that exercises a single function or class in isolation, with all dependencies replaced by fakes.