Copilot Unit Tests: Generate Tests That Check Real Behavior

Copilot unit tests are useful when you provide the intended behavior and review whether each generated test would catch a real mistake. Ask GitHub Copilot for a small set of cases, run them, and prove that important failures are detected. fenbs can keep the reusable test prompt and lessons from missed bugs, so your next assistant starts with a better testing brief.

What steps produce useful tests with Copilot?

1. Choose one function or small behavior and write down its expected inputs, outputs, and failures.
2. Show Copilot the production code, the current test framework, and a nearby example test.
3. Ask for proposed cases first, resolve unclear requirements, then request the test code.
4. Inspect the assertions and test setup before running the targeted tests.
5. Introduce a small temporary fault in a local copy, confirm the relevant test fails, restore the code, and rerun.

A unit test checks a small piece of code in isolation. Start there when the question is whether a calculation, validation rule, or transformation behaves correctly. A test that needs a real database, payment service, and browser may answer a useful question, but it belongs to a broader kind of testing.

GitHub’s testing tutorial↗ (opens in a new tab) shows Copilot generating tests and using existing test files as context. You still need to decide what correct behavior means. A generated test can reproduce a bug in the implementation and then pass consistently.

What requirements should you provide before generating tests?

Describe behavior in terms a user or caller cares about. Say a function converts minutes into whole billing units. Specify whether it rounds up, how it handles zero, and whether negative input is rejected. Without those rules, the assistant must guess, and different guesses can all produce passing tests.

Agree on the contract before asking Copilot to write assertions. If existing behavior conflicts with the requirement, make that conflict explicit instead of quietly updating the expected result. Keep approved behavior rules in fenbs Decisions and rules, where another assistant can read them before generating a fresh suite.

How should you ask Copilot to write the test file?

Name the target file and function, identify the existing framework, and request a limited change. Include one working test from the repository so the assistant sees the imports, naming, and setup. Avoid asking it to introduce a new test library merely because it recognizes that library better.

Test the selected title-validation function.
Use our existing test framework and neighboring test style.
First list cases from the approved behavior requirements.
Include ordinary input, empty input, and both length boundaries.
Assert exact results or the specified error.
Keep tests independent. Mock only external dependencies.
Do not change production behavior to make a test pass.
Report the command run and any cases still unverified.

GitHub provides a unit-test prompt-file example↗ (opens in a new tab) that emphasizes behavior, project conventions, and independent cases. You can borrow the idea of a consistent checklist while writing your own request for the actual project. Keep the prompt short enough that someone reviewing it can spot an incorrect assumption.

You do not need a special command to describe the test you want in chat. For choosing a workspace, see the Copilot app guide; for a terminal workflow, see the Copilot CLI guide. The testing contract should remain the same across those choices. For context that carries between sessions, see the separate Copilot memory guide.

Which weak assertions should you reject?

An assertion is the part of a test that decides whether the result is correct. A check that a result merely exists may pass even when its value is wrong. If the requirement says the function returns a trimmed title, compare the complete expected title with the actual return value.

• Reject assertions that compare a value with itself or repeat the implementation’s calculation as the expected answer.
• Reject error tests that pass when any unrelated exception is thrown.
• Reject mocks that replace the very behavior the test is meant to verify.
• Check that asynchronous work finishes before the assertion or test ends.
• Check that the test runner discovers the new file and reports real executed tests.

Read the test names alongside the assertions. A name claiming that blank input is rejected must actually check the rejected result. GitHub’s generated-code review guidance↗ (opens in a new tab) also warns about tests that are skipped or removed instead of fixed. Review the whole change, including configuration edits.

How can you tell whether a passing test catches a bug?

Make a deliberate temporary mistake in a local copy of the code. For the title example, remove trimming or allow a title one character beyond the stated limit. Run the relevant test and confirm it fails for the expected reason. Restore the original implementation before continuing.

This small experiment checks whether the assertion can distinguish correct behavior from a plausible defect. Do not leave the deliberate fault in shared code. If the test stays green, inspect the setup and expected value; adding more similar tests will not repair the missing check.

Run the targeted suite first, then the broader checks required by the repository. Note failures that already existed and dependencies you could not exercise. After an escaped bug, save the missing scenario as a lesson in fenbs, rather than storing only a vague instruction to test more carefully. More examples belong in the AI at work hub.

How to improve repeated test work with fenbs?

1. Create a free account and add the project whose tests you are improving.
2. Add a task with the intended behavior, relevant files, and the specific missing test cases.
3. Save the reviewed test-generation request in Skills and prompts, and record approved testing rules in Decisions and rules.
4. Connect your assistant through the integration guides, then ask it to read the rules, prompt, and relevant lessons before working.
5. After review, record actual test results and save progress, including any unverified dependency or scenario.

fenbs does not execute tests, measure code coverage, or verify assertions. Your test runner and code review remain necessary. If you are checking one disposable function, saving a shared prompt may be unnecessary; it becomes useful when the same testing expectations need to survive another task, assistant, or teammate. Changing Copilot models should not erase those expectations.