mcpField
T
tdd

tdd

github.com/overextendedTesting & quality208 installsUpdated 2w ago
Repository

About tdd

TDD bug fix is a skill for fixing bugs in TypeScript resources and their NUI. It recommends a focused regression check that demonstrates the failure before the smallest code fix, while allowing a practical alternative when a new test would be costly or brittle.

Key features

  1. 01Reproduce bugs with focused checks
  2. 02Write regression tests before fixes
  3. 03Verify the test fails for the bug
  4. 04Apply the smallest production change
  5. 05Use alternatives when tests are impractical

Use cases

  1. 01Fixing a TypeScript resource regression
  2. 02Testing a bug in the NUI path
  3. 03Validating a fix when a new test is impractical

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/overextended/skills --skill tdd

After installing, type/tddin Claude Code to confirm it loaded.

Bundled filesagents/openai.yamlCREDITS.md

Details

From the project README

TDD bug fix

This covers TypeScript resources and their NUI. Their tests run under the resource's test runner with the natives and @overextended/ox_lib calls the code touches mocked, so no FiveM server is needed.

When fixing a bug with a clear, cheap test path, make the broken behavior executable before changing production code. The goal is a focused regression test that fails before the fix and passes after it.

Do not force a test when it would be impractical. If the available test would require broad harness setup, brittle mocks, slow end-to-end infrastructure, production-only state, vague reproduction steps, or large unrelated fixture churn, skip adding a new test and use the closest useful verification instead.

Workflow

  1. Understand the bug. Identify the intended behavior, current behavior, affected path, and smallest observable reproduction.
  2. Choose the narrowest executable check. Prefer the closest unit, component, integration, or regression test already used for that codepath. If no practical test path is obvious, do not create one from scratch just to satisfy the workflow.
  3. Write the failing test first. Add the smallest focused test that would have caught the bug. The test should encode intended behavior, not mirror the current implementation.
  4. Run the new test before fixing. Confirm it fails for the intended reason. If it passes or fails for an unrelated reason, correct the test or reproduction before editing the implementation.
  5. Fix the bug. Make the smallest production change that satisfies the intended behavior while preserving nearby contracts.
  6. Rerun the regression test. Confirm the test now passes.

If a failing test is impractical

Use the closest executable regression check instead: a targeted script, browser automation against the NUI's dev server, a log assertion, or tsc --noEmit when the bug is a type error.

Prefer no new test over a bad test. A bad test is one that mostly tests mocks, encodes current implementation details, depends on timing or unrelated global state, needs expensive infrastructure for a small fix, or would be deleted immediately after proving the fix.

Guardrails

  • Do not change tests merely to match a wrong implementation.
  • Do not weaken existing assertions unless the expected behavior has genuinely changed and the reason is clear.
  • Keep the regression test focused on the bug. Avoid broad fixture churn or unrelated coverage expansion.
  • If the bug is flaky, make the test deterministic where possible and document the signal being locked down.
  • If the bug exposes a broader class of failures, first land the focused regression path, then consider additional sibling coverage.

Final response

Report the evidence, not just the outcome:

  • Name the failing-before test or executable check and the failure it produced.
  • Name the passing-after test run and any nearby validation performed.
  • If failing-before evidence could not be demonstrated, state why and describe the closest regression check used instead.

Comments

Markdown supported