ChatGPT for Unit Testing: Best Prompts

Write unit tests for this function:

def calculate_shipping(weight, distance):
    if weight <= 0 or distance <= 0:
        return None
    return weight * 0.5 + distance * 0.1

Before: The Weak Prompt

Why do AI-generated unit tests so often pass immediately without actually catching anything meaningful? It's a common complaint developers raise, and it usually traces back to a prompt that asks for tests in the abstract, which tends to produce tests that mirror the happy path the function was obviously designed for, and nothing beyond it.

Write unit tests for this function: def calculate_shipping(weight, distance): if weight <= 0 or distance <= 0: return None return weight * 0.5 + distance * 0.1

What this does: produces a handful of tests using reasonable, valid inputs that confirm the function does roughly what it looks like it's supposed to do -- which provides a false sense of test coverage, since it doesn't probe the boundary conditions or unusual inputs where bugs actually tend to hide.

Why It Fails

Tests that only exercise the obvious happy path validate that a function works when everything goes right, which is almost never where real bugs show up. Real bugs cluster at boundaries -- zero, negative numbers, empty inputs, unusually large values -- and a prompt that doesn't explicitly ask for those specific cases usually won't get them, since the model defaults to typical, unremarkable inputs unless told otherwise clearly.

⚠️ Common mistake: Asking for "unit tests" generically without specifying that edge cases, boundary conditions, and invalid inputs should be included. This produces tests that pass immediately and look complete, but only validate the function's most obvious, least bug-prone behavior.

After: The Improved Prompt

Write unit tests for this function, specifically including: boundary values (weight or distance exactly at 0), negative values, very large values that might cause overflow or unexpected behavior, and at least one test that verifies the None return path is triggered correctly. def calculate_shipping(weight, distance): if weight <= 0 or distance <= 0: return None return weight * 0.5 + distance * 0.1

What this does: explicitly naming the categories of edge cases to cover -- boundaries, negatives, large values, and the early-return path -- forces the test suite to actually probe where bugs are statistically most likely to hide, rather than just confirming the function works for typical, unremarkable inputs.

⚡ Pro tip: Always explicitly list the categories of edge cases you want covered -- boundaries, negative numbers, empty inputs, very large or very small values, and any explicit early-return or error paths in the function. A generic "include edge cases" instruction gets interpreted less thoroughly than a named list.

Breaking Down Each Element

Naming boundary values specifically (weight or distance at exactly 0) targets the exact line where the function's behavior actually changes -- these are consistently the highest-value tests for a conditional-heavy function like this one. Testing negative and unusually large values checks for behavior the original developer might not have explicitly considered when writing the function. And explicitly testing the None return path ensures the early-exit condition itself gets verified, not just the main calculation logic that happens after it.

A backend developer testing a more complex function with external dependencies uses a related but distinct technique: specifying what should be mocked versus tested directly.

Write unit tests for this function that calls an external payment API. Mock the API call so tests don't make real network requests, and include tests for: successful payment, API timeout, and API returning an error response. Use unittest.mock for the mocking.

What this does: specifying the exact mocking approach and the three distinct API response scenarios (success, timeout, error) ensures the test suite covers how the function behaves across the realistic range of what an external API call can actually do in production, not just the case where everything works perfectly every time.

⚠️ Common mistake: Writing tests that make real network calls to external services, resulting in tests that are slow, flaky, and dependent on the external service actually being available and returning consistent results. Always specify mocking for any external dependency in your test request.

Variations for Different Contexts

For testing functions with complex internal state, a data engineer uses ChatGPT to generate tests that specifically verify state changes across multiple calls, not just single-call outputs:

Write tests for this class that manages a connection pool. Test that: calling get_connection() twice returns different connections, returning a connection to the pool makes it available again for the next get_connection() call, and the pool respects its maximum size limit when connections aren't returned.

What this does: focusing tests on state transitions across multiple method calls, rather than testing each method in complete isolation, catches the class of bugs specific to stateful objects -- where each individual method might work correctly on its own but the interactions between successive calls reveal the actual underlying bug.

⚡ Pro tip: For any class or function that maintains internal state across calls, always request tests that verify behavior across multiple sequential calls, not just single-call correctness. State-related bugs almost never show up in single-call tests.

A QA engineer writing tests for a data validation function used across the signup flow uses ChatGPT to generate a comprehensive table of input-output pairs before writing any actual test code, as a review step with the rest of the team before implementation begins:

For this email validation function, generate a table of 15 test inputs covering valid emails, invalid formats, edge cases like very long domains, and unusual but technically valid formats (plus signs, subdomains). Don't write the test code yet -- just the input/expected output table for the team to review first.

What this does: separating the test case enumeration from the actual test code implementation lets the team review and catch gaps in coverage before any code gets written, which is a much cheaper point to catch a missing edge case than after the tests are already implemented.

Testing for Regression Prevention

A different but related use case is writing a test specifically to prevent a bug that already happened once from ever silently returning again. A developer who just fixed a production bug uses ChatGPT to write a regression test tied directly to the original failure and the exact conditions that caused it:

We just fixed a bug where this function returned incorrect results when the input list contained exactly one item (it was assuming at least 2 items for a comparison). Write a regression test specifically for this one-item case, with a comment explaining what bug this test is guarding against.

What this does: writing the test explicitly tied to the original bug, with a comment explaining the history, means the next developer who touches this code understands why this specific, seemingly minor test case exists, rather than potentially removing it during a later cleanup pass because it looks redundant or overly specific without that historical context attached.

⚡ Pro tip: Whenever you fix a bug in production or staging, write a regression test that specifically targets the exact failing case, with a comment explaining what bug it guards against. This is one of the highest-value testing habits, since it directly prevents the same bug from silently reappearing after a future code change.

⚠️ Common mistake: Fixing a bug without adding a test that specifically covers the exact failing case that caused it in the first place. Without a targeted regression test, the same bug can silently reappear months later after a seemingly unrelated code change, and nobody notices until it causes a problem all over again.

A team lead reviewing test coverage across an entire codebase uses ChatGPT to identify gaps by comparing existing tests against a function's actual behavior, rather than just counting lines of test code as a rough coverage proxy:

Here's a function and its existing test suite: [paste both]. Identify which specific behaviors or code paths in the function are NOT currently covered by any existing test, rather than telling me the overall test count is sufficient.

What this does: asking for a gap analysis against actual code paths, rather than a general assessment, surfaces the specific untested branches or conditions that a simple test count would miss -- a function can have ten passing tests and still leave a critical error-handling branch completely uncovered by any of them.

Save and Reuse This

The pattern across every prompt here: explicitly name the edge case categories, specify mocking for external dependencies, and test state transitions for stateful objects, not just single-call correctness. A test suite built this way actually catches bugs; one built from a generic "write tests" prompt mostly just confirms the obvious.

If you're writing unit tests regularly across similar types of functions, it's worth saving these edge-case checklists as reusable prompt templates rather than reconstructing the category list from memory each time. PromptABCD works well for keeping this kind of testing checklist ready to apply to the next function that needs coverage, whether it's a simple calculation or a stateful class with external dependencies.