GitHub Copilot prompt to write unit tests
Before it writes a single assertion, this prompt has GitHub Copilot inventory the open module in Chat: every exported function, the branches inside each, and the external calls worth mocking. That planning step separates real coverage from happy-path filler, and the run ends with a deliberately broken assertion to prove the new tests can actually fail.
Last updated
Write unit tests for the module I have open in the editor. First read the file and list its exported functions, the branches inside each, and any external calls that need mocking, then generate the test file next to it following the naming pattern the repo already uses. Cover each branch, not just the happy path: boundary values, empty inputs, thrown errors from mocked dependencies, and any async rejection paths. Mock at module boundaries only; do not mock the function under test or private helpers. Use the assertion style and test runner already configured in the project rather than introducing a new one. If a function is untestable without refactoring, say so and stop instead of testing implementation details. Run the new tests, confirm they pass, then deliberately break one assertion to prove the test can fail, and restore it.
Same task in other tools
Questions about this prompt
How is this different from the /tests slash command?
/tests is a shortcut that generates whatever tests seem plausible for the selection. This prompt forces a branch inventory first, bans mocking the unit under test, and requires a proven failure, none of which /tests does on its own.
Copilot mocked everything, including the logic I wanted tested. Why?
That usually happens when the module mixes IO with logic, so everything looks like a dependency. Keep the "mock at module boundaries only" line, and if it still overmocks, extract the pure logic into its own file and point the prompt there.
Can I target a single function instead of a whole module?
Highlight the function and change the first sentence to "the selected function" so Chat uses your selection as context. The branch-listing step still applies; small functions often hide the least tested error paths.