ChatGPT Settings for Test-Driven Development Prompts

Why TDD Prompts Need Different Settings

Test-driven development flips normal coding order: you write the test before the code, watch it fail, then make it pass. When you ask ChatGPT to help, a “just build the feature” prompt fights the whole method. The model will happily ship implementation and skip the failing test, which defeats TDD. The fix is prompt settings that force red-green-refactor discipline and keep the model from over-engineering.

This is a settings-selection guide for TDD workflows. The table matches each TDD phase to a ChatGPT setup, explains when to use it, and gives a snippet. For the general coding-Settings picture, see best ChatGPT settings for coding, and for why vague “build me an app” prompts fail, coding prompt examples shows the contrast.

TDD Settings Decision Table

When to Use Each Setting

Red — write failing test. Use at the very start of a feature. The model must output only the test and confirm it should fail against current code. Blocking implementation here is the point: you define the contract before the code exists.

Green — minimal pass. Use right after the test is red. Instruct the model to write the smallest change that turns the test green. This stops it from gold-plating a feature you have not proven you need.

Refactor — clean up. Use once tests pass. The model may restructure for readability but must not alter behavior. Re-run tests after to prove nothing broke.

Edge-case expansion. Use when happy-path tests pass but you fear real input. The model adds boundary and negative tests (nulls, empties, extremes) without touching passing code.

Explain the suite. Use for review or onboarding. The model reads the tests and explains what is covered and what is not, in plain language a teammate can scan.

Prompt Snippets by Phase

Red — write failing test

You are a TDD test author. Do NOT write implementation.
Feature: [DESCRIPTION].
Write a failing unit test for [FUNCTION / METHOD] using [FRAMEWORK, e.g. pytest].
Rules:
- Cover the expected behavior only.
- Output the test file content, nothing else.
- Add a comment: "This test should FAIL against current code."
Return the test code.

Green — minimal pass

You are a minimalist implementer following TDD.
Given this failing test: [PASTE TEST]
Write the SMALLEST code change that makes it pass.
Rules:
- No extra features, no premature refactoring.
- Do not modify the test.
- If the test is wrong, say so instead of hacking a pass.
Return only the implementation diff or function.

Refactor — clean up

You are a refactor guard. The tests below are GREEN and must stay green.
Code: [PASTE CODE]  Tests: [PASTE TESTS]
Improve readability and structure only.
Rules:
- Do not change observable behavior.
- Do not add features.
- After changes, list which tests still cover the behavior.
Return refactored code.

Edge-case expansion

You are a negative-test writer.
Existing tests: [PASTE TESTS]  Current code: [PASTE CODE]
Add boundary and negative tests for [FUNCTION]:
- Empty / null input
- Out-of-range values
- Duplicate or malformed input
Rules:
- Use the same framework.
- Do not alter passing tests.
- Label each new test with the case it covers.
Return added test code.

Explain the suite

You are a test reviewer. Read this test suite: [PASTE TESTS].
Summarize in plain language:
- What behavior is covered.
- What is NOT covered (gaps).
- Any brittle or redundant tests.
Keep it under 250 words, no code changes.

Common Mistakes With TDD Prompts

1. Letting the model skip Red. The biggest failure is asking for a feature and getting implementation with a token test tacked on. Forbid implementation in the Red prompt so the contract comes first.

2. Over-building at Green. Once a test is red, the job is the smallest pass, not a polished module. Tell the model “smallest change” or it will gold-plate.

3. Refactoring without re-running. The Refactor guard re-lists coverage, but you must actually execute the suite. AI confidence is not a test run.

4. Ignoring negative tests. Happy-path green is not robustness. Use the edge-case snippet before you call a feature done.

Quick Reference Card

The Trade-Offs

TDD prompts cost more turns than “build it once,” but they produce code with a safety net. The main risk is the model skipping Red and jumping to a full implementation — guard against it by explicitly forbidding implementation in the Red prompt, as shown. Another risk is over-refactor breaking tests; the Refactor guard snippet forces the model to re-list coverage so you can verify. Pair these with a tight coding setup from ChatGPT coding settings for temperature and verbosity that suit your stack. Used together, the model becomes a disciplined TDD partner rather than a feature-spitting machine.

Sources & Notes

Prompts tested with ChatGPT (GPT-4o and GPT-4.1) on free and Plus tiers in October 2026, using representative frameworks (pytest, Jest). The red-green-refactor framing follows standard TDD practice and is model-agnostic. No code was executed and no live APIs were called; snippets are copy-paste text the reader runs in their own environment. Slug and category mapping follow the guunn.com AI Prompts plan (Coding = 957).