## Engineering terms: testing

From Vibe Coding 101 (https://vibe-coding-101.brighteng.org/). When a request describes one of these problems, use the named technique, say its name, and run its check. Each term's page has the full entry and a prompt.

- **end-to-end test**: Check a user journey through the running application. Use when: Unit tests pass but users cannot finish a real workflow. Do: Choose one critical journey, use realistic data, and assert the user-visible outcome. State which external services are substituted. Avoid: Mocking the entire backend removes the integration the test claims to cover.
- **test isolation**: Each test controls its own state and can run independently. Use when: A test passes alone but fails in the full suite or in parallel. Do: Give each test independent state and cleanup. Run the affected tests alone, together, and in parallel. Avoid: A fresh browser still points at database records shared by every test. Worked example: https://vibe-coding-101.brighteng.org/examples/test-isolation.md
- **test fixture**: Reusable setup gives a test a known starting state and owns cleanup. Use when: Tests repeat setup or leave records behind after a failure. Do: Extract the repeated resource lifecycle. Pick its scope deliberately and ensure teardown runs after failures. Avoid: A suite-wide fixture shares mutable state that should belong to one test.
- **auto-waiting**: Wait for an observable condition instead of a fixed delay. Use when: A browser test needs sleeps to pass on slower machines. Do: Replace fixed sleeps with locators and assertions for the state that makes the next step valid. Avoid: A visible button is not proof that the preceding save has completed.
- **semantic locator**: Find an element by its role, label, or other user-facing meaning. Use when: A small markup change breaks many browser tests. Do: Use role and accessible name first, scope to the relevant region, and require an unambiguous match. Avoid: Using the first match hides ambiguous or duplicated controls.
- **test double**: A controlled substitute makes a dependency predictable in a test. Use when: You need to exercise a timeout or rejection that is hard to trigger reliably. Do: Substitute the smallest boundary needed for the scenario. Keep separate coverage of the real integration. Avoid: The substitute returns a response the real service would never produce. Worked example: https://vibe-coding-101.brighteng.org/examples/test-double.md
- **visual regression test**: Compare rendered output with an intentionally reviewed baseline. Use when: Behavioral tests pass while spacing, clipping, or typography breaks. Do: Fix viewport, fonts, and data; capture important states; inspect differences before accepting a new baseline. Avoid: Automatically accepting new snapshots turns regressions into expected output.
- **static analysis**: Static analysis inspects code without exercising the application. Use when: A generated patch contains type errors or suspicious patterns. Do: Run the relevant analyzer, understand its diagnostic, and check the affected behavior after fixing it. Avoid: Treating a clean analyzer result as proof that the application works.
- **snapshot test**: Compare serialized output with a reviewed expected snapshot. Use when: Stable structured output is easier to review as a whole than through many individual assertions. Do: Keep snapshots focused and deterministic; pair them with assertions for essential behavior. Avoid: Updating every baseline to make a failing suite green.
- **property-based testing**: Generate inputs to test a general property rather than only handpicked examples. Use when: A parser or transformation has many combinations and boundary cases. Do: Define a useful invariant, generate representative inputs, and keep discovered regressions. Avoid: Choosing a property so weak that a broken implementation satisfies it.
- **flaky test**: A test produces inconsistent outcomes without an intentional relevant change. Use when: A check intermittently fails under the same expected conditions. Do: Capture the failure conditions, control suspected inputs, and verify the underlying cause before changing expectations. Avoid: Deleting the assertion or increasing retries while leaving the cause unexplained.
- **network panel**: The browser network panel shows requests and responses made by the page. Use when: Clicking Save appears to do nothing and the failing boundary is unknown. Do: Reproduce the action and inspect the relevant request, status, timing, and safely redacted data. Avoid: Filtering out fetch requests and concluding that the page sent nothing.