Testing & QA

Busted

• API testA test that sends requests directly to an endpoint, then checks the response, errors, and what changed behind the API.
• Arrange-Act-Assert (AAA)A common three-beat shape for readable tests: set up the world, do the one thing, check the result it produced.
• AssertionThe line inside a test that declares what must be true. If reality disagrees, the test fails and shows you what it got instead.
• Boundary value testingTesting values at, just below, and just above a limit, where off-by-one and inclusive-range bugs usually hide.
• Chaos testingDeliberately breaking part of a running system, within a small safety boundary, to prove it keeps working and recovers.
• Code coverageThe percentage of your code that actually runs while the tests run. It proves the tests touched the code, not that they checked anything.
• Component testA test that renders and uses one UI component by itself, so you can check its behavior without starting the whole application.
• Contract testBoth sides of an API test against a written agreement instead of each other, so the backend learns it broke the frontend without booting it.
• Cross-browser testingChecking the same important flows across browser engines, operating systems, and screen sizes to catch compatibility-only bugs.
• End-to-end (E2E) testA script that drives your real app in a real browser like a user would: click, type, submit, then check what appears on screen.
• Feature flag testingChecking the old and new code paths behind a feature flag, including rollout rules and the fallback when the flag service fails.
• Flaky testA test that passes and fails at random on the exact same code, usually because of timing, shared state, or the real-world clock.
• Fuzz testing / property-based testingGenerate many unexpected inputs, check a rule that should always hold, and shrink failures into small reproducible examples.
• Golden-file testing / approval testingCompare current output with a checked-in reference file, then reject the difference or bless it as the new expected result.
• Happy path vs. edge caseThe happy path is the run where everything goes right. Edge cases are the boundary inputs (empty, huge, zero, weird) that break it.
• Headless browserA real browser engine running with no visible window. Same rendering and JavaScript, driven by a script instead of a person.
• Hermetic testA self-contained test with controlled time, data, files, and services, so outside state cannot change the result.
• Integration testA test that runs several real pieces together, like your API route plus an actual database, to catch bugs that live in the seams.
• Linting vs. type checking vs. testingLint finds suspicious code, type checking rejects impossible value combinations, and tests run examples to check behavior.
• Load testFiring simulated users at your app at the traffic you actually expect, then checking latency, throughput, and error rate against your targets.
• MockA fake dependency carrying expectations about how it must be used, so the test fails unless sendEmail was called once, with this.
• Mutation testingA tool deliberately changes your code and checks whether the test suite turns red, exposing assertions that never notice wrong behavior.
• Negative testingDeliberately giving a system bad or forbidden input to prove it rejects the request cleanly and leaves state unchanged.
• Page object modelA reusable wrapper that keeps a page's selectors and common browser actions out of every individual end-to-end test.
• Parallelization / shardingSplit one slow test suite into separate slices and run them at the same time, often on several CI machines.
• Parameterized test / table-driven testOne test body run against a table of named inputs and expected outputs, giving repeated cases less copy-paste and clearer failures.
• Race conditionA failure whose outcome changes with timing because concurrent requests, jobs, or tests touch the same state in a different order.
• Red-green-refactorWrite one failing test, make the smallest change that passes it, then clean up without turning the tests red again.
• Regression testA test written from a specific bug so that exact bug can never come back unnoticed. See it fail first, then fix, then keep it forever.
• Reproduction steps / minimal reproducible example (MRE)The shortest exact steps or code that trigger the bug, plus how often it fires. What maintainers ask for before they will look at your issue.
• Scripted manual testing / exploratory testingTwo ways humans test: following a written checklist step by step, or learning, designing, and running tests at once under a charter.
• Seed dataPreloaded users, orders, and other records that give a test environment the same useful starting point on every run.
• Shift-left testingMoving checks earlier, from release week into design, coding, and pull requests, so defects are cheaper and faster to fix.
• Smoke testA tiny, fast set of checks that the app boots and its core paths work, run before anyone bothers with the slow, deep test suite.
• Snapshot testThe test records the output once, commits it, and fails whenever it changes. You then decide: real bug, or intended update?
• Soak testHolding realistic traffic for hours to catch memory leaks, exhausted connection pools, and other failures that appear slowly.
• Spike testA load test that slams the system with a sudden traffic burst, then checks whether it stays useful and returns to normal.
• SpyA wrapper that lets the real function run while recording every call it got, so you can assert it was called with the right arguments.
• Static analysisTools inspecting code without running the app, looking for suspicious patterns, type mistakes, security bugs, and broken rules.
• Stress testPushing a system beyond expected traffic to find its breaking point, see how it fails, and prove it recovers afterward.
• StubA fake that just hands back a canned answer so the test can carry on. It never checks who called it or how often.
• Test caseOne named scenario: given these inputs and these steps, this exact result must come out. The smallest unit of 'we checked that'.
• Test data factoryA helper that builds a fresh, valid test object from defaults, while each test overrides only the details that matter.
• Test doubleThe umbrella word for any fake you swap in for a real dependency in a test: stubs, spies, mocks, fakes, dummies.
• Test fixtureThe known-good data or state a test starts from, defined once and reused so every test doesn't rebuild the world.
• Test isolation / setup and teardownEvery test starts from a clean known state and leaves nothing behind, so tests cannot poison each other or depend on running order.
• Test locator / test IDHow a test finds an element: ideally by what the user sees ('the button named Save'), otherwise by a stable data-testid hook.
• Test matrixA grid of browser, environment, configuration, and input combinations showing exactly which setups must be checked.
• Test planA written agreement on what QA will cover, the biggest risks, where tests run, and what must be true before release.
• Test pyramidThe shape of a healthy test suite: many cheap unit tests at the base, fewer integration tests, a thin cap of slow end-to-end tests.
• Test quarantineMove a known flaky test into a visible non-blocking lane so it stops holding up merges while someone fixes it.
• Test retryAutomatically rerun a failed test once or twice before calling the build red, usually to contain a known intermittent failure.
• Test runnerThe tool that finds your test files, runs them, and prints the pass/fail report. 'npm test' is you calling one.
• Test suiteA group of related tests run and reported together: one describe block, one file, or your entire test command.
• Test-driven development (TDD)Write the failing test first, then just enough code to make it pass, then clean up. Red, green, refactor, repeat in tiny loops.
• Testing trophyA test-suite shape with a fat integration layer, arguing that tests across real seams often buy the most useful confidence.
• Unit testA test that runs one small piece of behavior on its own, no network or database, so a red result is usually quick to trace.
• User acceptance testing (UAT)A release check where real users or the client confirm the software supports the job and requirements they actually asked for.
• Visual regression testScreenshots your UI, compares it to an approved baseline, and fails when pixels move. Catches the CSS change that broke a different page.

The territory

30 core terms mapped for this field, ranked by how often builders reach for them. Each one is a future entry. Want to bust one? One entry, one file, one pull request.

• unit testtests one function in isolation, no network or database"test just this one function" · "small test"
• integration testtests several real pieces wired together, e.g. API plus database"test the parts talking to each other" · "test with a real DB"
• end-to-end (E2E) testscript drives the real app like a user would"robot that clicks through my site" · "fake user test"
• test casedefines inputs, actions, and expected result for one behavior"one thing I'm checking" · "a single test"
• test suiterelated tests grouped and executed together"all my tests" · "the whole test file"
• assertionthe line that declares what the result must be"the part that says it should equal this" · "the check"
• test runnertool that finds, executes, and reports on your tests"the thing that runs the tests" · "test command"
• arrange-act-assert (AAA)three-part structure every readable test follows"given when then" · "the three-part test layout"
• test fixturereusable known-good setup data or state for tests"the fake data my tests start with" · "test setup blob"
• test doubleumbrella term for any fake used in place of the real thing"stand-in object" · "fake version"
• mockfake dependency that also records and verifies how it was called"pretend version of the API" · "fake it so it doesn't call Stripe"
• stubfake dependency that returns canned answers, no call verification"return a fixed fake answer" · "hardcoded fake response"
• spywrapper that records calls while the real behavior still runs"check if it got called" · "watch the function"
• flaky testpasses and fails randomly without code changes"test that fails for no reason" · "sometimes-red test"
• code coveragepercentage of code lines actually run by tests"test coverage" · "how much of my code is tested"
• regression testlocks in a fixed bug so it can never come back"make sure that bug stays dead" · "test for the thing I already fixed"
• smoke testtiny fast check that the app boots and basics work"does it even start" · "quick sanity check"
• test pyramidmany unit tests, fewer integration, fewest E2E"how many of each test" · "unit vs E2E ratio"
• happy path vs. edge casethe intended flow versus weird boundary inputs"when everything goes right" · "the weird inputs nobody expects"
• test-driven development (TDD)write the failing test first, then the code"test before code" · "red green refactor"
• test isolation / setup and teardownresetting state so tests don't pollute each other"tests messing with each other" · "clean up between tests"
• test locator / test IDstable hook like data-testid for grabbing elements"selector" · "data-testid"
• headless browserreal browser engine running without a visible window"browser with no window" · "invisible Chrome"
• snapshot testsaves rendered output, fails when it changes unexpectedly"save what it looked like and compare" · "diff the output"
• visual regression testscreenshots pages and flags pixel differences between runs"did my CSS change break anything" · "screenshot diff test"
• contract testverifies a service still matches the shape its consumers expect"make sure the API didn't change shape" · "API agreement test"
• load testsimulates many users to find breaking point"what if 10,000 people hit it" · "stress test"
• acceptance criteriathe checklist that defines "this feature is done""how we know it's finished" · "the done list"
• scripted manual testing / exploratory testinghumans following steps, or hunting bugs unscripted"manual QA pass" · "just click around and try to break it"
• reproduction steps / minimal reproducible example (MRE)smallest steps or code that reliably triggers the bug"bug repro" · "tiny example that fails"

Deeper in the field

• testing trophy modern shape favoring integration tests over unit
• mutation testing breaks your code on purpose to see if tests notice
• soak test runs load for hours to expose memory leaks
• spike test sudden traffic burst to check recovery
• chaos testing deliberately kills services to prove resilience
• feature flag testing verifying both on and off states of a flag
• shift-left testing catching defects earlier in the build cycle
• linting vs. type checking vs. testing three distinct layers of automated correctness
• static analysis tools reading code for bugs without running it
• hermetic test fully self-contained, no network or shared state
• parallelization / sharding splitting the suite across machines for speed
• test retry re-attempting flaky async steps before declaring failure
• race condition timing-dependent failure from concurrent operations
• seed data prepopulated records so a test environment isn't empty
• red-green-refactor fail, make it pass, then clean up
• page object model wraps a page's selectors in one reusable class
• test quarantine isolating unreliable tests so they stop blocking merges
• golden-file testing / approval testing compares output against a blessed reference file
• fuzz testing / property-based testing random or generated inputs hunt for broken invariants
• test plan defines testing scope, risks, environments, and exit criteria
• component test tests one UI component without running the whole application
• API test calls endpoints directly and checks responses, errors, and side effects
• user acceptance testing (UAT) confirms software meets real user or client requirements
• parameterized test / table-driven test runs one test against multiple named input-output cases
• negative testing verifies invalid inputs and failure paths behave correctly
• boundary value testing checks values at, below, and above important limits
• cross-browser testing verifies behavior across browsers, engines, and viewport sizes
• test matrix lists environment, configuration, and input combinations requiring verification
• stress test pushes beyond expected capacity to reveal failure and recovery
• test data factory generates valid test objects with overridable defaults