Testing Collocations

Write tests — the standard collocation for authoring test code:

In software testing, different verbs describe different stages:

Write / author: Create the test code itself. "We need to write unit tests." "I wrote a test for the edge case." This is the most natural collocation — developers write code, including test code.

Run / execute: Execute the tests. "CI runs all tests on every push." "Let's run the test suite before the release."

Pass / fail: The result of running a test. "All 243 tests passed." "3 tests failed after refactoring."

Fix / repair: Fix broken tests. "The refactor broke the contract tests — I need to fix them."

Types of tests (collocations with "write"):

• write unit tests — test individual functions in isolation
• write integration tests — test interactions between components
• write end-to-end tests (E2E) — test full user flows
• write smoke tests — minimal tests to check basic functionality
• write regression tests — prevent reintroduction of fixed bugs

Test coverage — types and collocations:

"Coverage" in testing measures how much of the code is exercised by tests. Different types measure different things:

Line coverage (also: statement coverage): The percentage of source code lines that are executed by tests. "90% line coverage" means 9 out of 10 lines of code run during a test. Easiest to achieve but least informative.

Branch coverage (also: decision coverage): Whether both the "true" and "false" branches of every conditional (if/else, switch) are tested. Higher quality than line coverage — a line can be "covered" while a branch remains untested.

Function/method coverage: Whether each function was called at least once.

Path coverage: Every possible path through the code — most thorough, often impractical.

Key expressions:

• "achieve / reach / maintain 80% coverage"
• "improve coverage from 65% to 85%"
• "measure code coverage" using a coverage tool
• "the coverage report shows…"
• "uncovered lines / uncovered branches"

Common tools: Istanbul/NYC (JavaScript), pytest-cov (Python), JaCoCo (Java), SimpleCov (Ruby).

Flaky test — the essential QA collocation:

A flaky test is one of the most important and frequently used terms in software testing. It describes a test that does not produce a consistent result — it passes sometimes and fails other times under seemingly identical conditions.

What causes flaky tests:

• Race conditions — timing-dependent behaviour in async code
• External dependencies — tests that call real APIs or databases
• Shared state — tests that depend on the order they run in
• Environment differences — "works on my machine" but fails in CI
• Date/time sensitivity — tests that depend on the current time

Collocations and expressions:

• "This is a flaky test." — noun + adjective
• "The test is flaky." — predicate
• "We have test flakiness in the auth module." — noun form
• "Let's quarantine the flaky tests." — isolate them so they don't block the pipeline
• "We need to stabilise / fix / investigate this flaky test."

Compare: A broken test fails consistently (deterministic failure). A flaky test fails non-deterministically.

Run the regression suite — the standard professional expression:

Core testing collocations with verb choices:

"Run" is the dominant verb for executing tests at any scale:

• run a test
• run the test suite
• run regression tests
• run a smoke test
• run the full test pipeline

"Test suite" — the collection of tests as a whole:

• "regression test suite" — all tests that verify no regression in existing features
• "smoke test suite" — minimal set to check basic functionality

Regression testing vocabulary:

• regression (noun) — when a working feature breaks after new changes
• introduce a regression — accidentally break something that worked before
• "This PR introduces a regression in the login flow."
• catch a regression — a test detects the problem
• "Our regression suite caught the edge case before release."

Note on "execute": "Execute tests" is grammatically correct and used in formal documentation and test management tools (TestRail, etc.), but in verbal/written developer communication, "run" is more natural.

Pass/fail — the fundamental test outcome vocabulary:

In software testing, the outcome of a test is described by two complementary verbs:

Pass (verb) / passing (adj): The test ran and produced the expected result — the assertion held.

• "All 847 tests passed."
• "The smoke tests are passing in staging."
• "A passing test."

Fail (verb) / failing (adj): The test ran but the assertion did not hold — unexpected behaviour detected.

• "3 tests failed after the migration."
• "The auth tests are failing in CI."
• "A failing test." / "a test failure"

The full result vocabulary:

• pass ✓ — expected behaviour confirmed
• fail ✗ — unexpected outcome detected
• skip ⊘ — not run (marked @skip or pending)
• error ⚠ — the test itself threw an exception (distinct from a failure)

Common expressions:

• "Green build" — all tests passing in CI
• "Red build" / "broken build" — one or more tests failing
• "Build is green. Ship it." — traditional CI culture expression