AI Prompts for Unit Testing

Write a complete unit test suite for this function: [PASTE FUNCTION]. Use [JEST/PYTEST/MOCHA/OTHER]. Include tests for: the happy path with typical inputs, boundary values (empty, null, zero, maximum), invalid inputs, and any error conditions the function should handle. Each test name should describe the expected behavior, not the implementation.

Here is a test suite for this code: [PASTE CODE AND TESTS]. What test cases are missing? Specifically look for: untested edge cases, error paths that have no test, conditions where the function could silently return wrong results, and any input combinations that interact in non-obvious ways.

Write unit tests for this asynchronous function: [PASTE FUNCTION]. Include tests for: successful completion, rejection/failure scenarios, timeout handling, and any race conditions if applicable. Show how to correctly test async code in [JEST/PYTEST] including proper use of async/await and mocking asynchronous dependencies.

I want to test this function with many different inputs: [PASTE FUNCTION]. The test cases are: [LIST INPUT/EXPECTED OUTPUT PAIRS]. Write parameterized tests using [JEST test.each/pytest parametrize/other] that test all cases without duplicating test code. Explain the benefits of parameterized tests for this scenario.

Write unit tests for this class: [PASTE CLASS]. Test each public method. For each method, test: expected behavior with valid input, behavior with invalid or unexpected input, any state changes the method should produce, and interactions between methods (if method A depends on method B having been called first, test that dependency explicitly).

This function makes an external API call: [PASTE FUNCTION]. Write tests that mock the API call so the tests: do not make real network requests, test the function's behavior when the API succeeds, test the behavior when the API returns an error, and test the behavior when the API times out. Use [JEST/PYTEST/OTHER] mocking.

This code depends on a database: [PASTE CODE]. Write unit tests that mock the database layer so tests run without a real database. Show how to: mock the database module, set up different return values for different test cases, verify that the code calls the database with the correct parameters, and test error handling when the database fails.

I am writing tests for this code: [PASTE CODE]. The dependencies are: [LIST DEPENDENCIES]. Help me decide what to mock and what to test directly. What are the criteria for mocking versus using real implementations? Where would over-mocking make my tests pass even when the real integration would fail?

I want to test that this code calls [DEPENDENCY] with the correct arguments: [PASTE CODE]. Write a test that uses a spy or mock to: verify the dependency was called, verify it was called the correct number of times, verify it was called with the correct arguments, and still test the output of the function under test.

This code reads from and writes to the file system: [PASTE CODE]. Write unit tests that do not touch the real file system. Show how to: mock file system operations, test behavior when files exist versus do not exist, test error handling for permission errors or missing directories, and clean up any state between tests.

Reorganize these tests into a well-structured hierarchy using describe blocks: [PASTE TESTS]. Group related tests logically, use describe for the class or module, nested describes for method groups or scenarios, and it/test for individual cases. Each level should add meaning to the test name without being redundant.

Several of my tests share common setup: [DESCRIBE SETUP NEEDS]. Write the setup and teardown code using beforeEach, afterEach, beforeAll, and afterAll as appropriate. Explain which hook to use in which case and how to avoid test pollution through shared state between tests.

My tests create a lot of similar test data: [DESCRIBE DATA NEEDED]. Write test fixtures or factory functions that make it easy to create test data with sensible defaults that can be overridden per-test. The fixtures should produce the minimum data needed to make each test pass without obscuring what is actually being tested.

These tests keep breaking even when the code is correct: [PASTE TESTS AND DESCRIBE WHAT BREAKS THEM]. Identify why the tests are brittle: are they testing implementation details, depending on order, sharing mutable state, or making assumptions about external systems? Rewrite them to be more resilient.

My code has [X]% test coverage but I still have bugs reaching production. Here is a coverage report: [DESCRIBE OR PASTE]. Explain why coverage percentage can be misleading. What are the code paths that are most important to test but coverage tools do not highlight? How do I prioritize improving tests beyond just increasing the percentage?

This function validates user input: [PASTE FUNCTION]. Write tests that cover: valid inputs of various types, invalid inputs that should be rejected (wrong type, out of range, wrong format), edge cases at the boundary of valid input, and injection attempts or malicious input. The tests should confirm both that valid input is accepted and that invalid input produces the correct error.

Write tests that verify errors are properly propagated and handled in this call stack: [PASTE CODE]. Test that: errors from deep in the stack surface with useful messages, errors are not swallowed silently, the system ends up in a consistent state after an error, and logging/monitoring receives the right information when an error occurs.

Write an integration test that tests the boundary between [MODULE A] and [MODULE B]: [PASTE RELEVANT CODE]. The test should use real implementations of both modules rather than mocks, but still isolate the pair from external systems like databases and APIs. Test the most important interaction scenarios.

My unit tests pass but bugs appear with real production data. Here is a sample of production data that caused a bug: [PASTE DATA SAMPLE]. Write tests using this real data pattern. What characteristics of this data are different from my test data? Write a process for ensuring my test data stays representative of production.

I just fixed this bug: [DESCRIBE BUG AND FIX]. Write a regression test that: would have caught this bug before the fix, fails on the original code and passes on the fixed code, and is specific about what the bug was so someone reading the test understands what it is protecting against.