1 Overview

Tests and documentation are the two artifacts developers most consistently under-produce — not because they are hard, but because they are repetitive, and repetition is exactly what language models excel at. A model will happily write the fifteenth boundary test or the twentieth parameter description with the same care as the first. Used well, prompting turns 'we should really have tests for this' into an afternoon's reviewed reality.

Used carelessly, it produces something worse than nothing: test suites that pass while verifying nothing, and documentation that states plausible falsehoods with authority. The difference — as everywhere in this course — is the prompt's context and your review discipline.

This tutorial covers the four skills: generating NUnit unit tests that actually test behavior, systematically eliciting test cases and edge scenarios, generating API documentation from code, and — the load-bearing skill — reviewing generated tests for coverage and correctness so you can trust green.

2 Learning Objectives

After completing this tutorial, you will be able to:

• Write test-generation prompts that produce NUnit suites grounded in the behavior spec, not just the implementation.
• Elicit test cases and edge scenarios systematically — boundaries, empties, duplicates, and failure paths — before any test code exists.
• Use parameterized tests to turn boundary tables into compact [TestCase] rows.
• Generate XML documentation comments, endpoint docs, and READMEs from code, and verify their claims.
• Review generated tests for the failure modes that matter: assertion-free tests, tautological tests, and bug-enshrining characterization.
• Apply the break-the-code check (manual mutation testing) to prove a test can actually fail.
• Read code coverage numbers for what they are — execution evidence, not verification evidence.
• Keep documentation from drifting by regenerating and reviewing it alongside code changes.

3 Prerequisites

• Tutorial 4 (Prompt Engineering for Coding Tasks) — context packs, exemplars, standards profiles, and the review bar.
• Basic familiarity with a .NET test framework (NUnit examples are used; xUnit/MSTest knowledge transfers directly).
• Comfortable C#: attributes, async, exceptions; ability to run `dotnet test`.
• Optional but ideal: a real method of your own that lacks tests — the walkthrough lands best on real code.

4 Why Tests and Docs Are Ideal — and Dangerous — GenAI Tasks

Test and documentation generation share three properties that make them model-friendly: the output is highly structured (a unit test has a fixed shape; a parameter description has a fixed shape), the input is complete (the code is right there in the prompt), and the volume is high (many cases, many members — exactly where human patience fails first). This is why test generation is consistently among the highest-satisfaction uses of AI coding tools.

The danger is equally structural. A test is only as good as its test oracle — the source of truth it checks against. If your prompt offers only the implementation, the model derives expectations from the implementation, and the resulting tests verify that the code does what the code does: green today, green after you break it the same way, tautological forever. The fix is supplying the behavior specification — what the method should do, in rules and examples — so expectations derive from intent, not from code.

Documentation inherits the same split. Docs generated purely from code describe mechanism ('sets the flag to true') and can only restate what the code says; docs generated from code plus intent describe purpose ('marks the invoice ready for the nightly export'). And both artifacts share one lifecycle risk — the code changes and they silently don't — which is why generation is never once-and-done but part of the change workflow.

5 Prompts That Generate NUnit Unit Tests

A production-grade test-generation prompt packs four things: the code under test (the method plus the types it touches), the behavior spec (rules and expected outcomes in plain language — the oracle), an exemplar test (one existing test class, so naming and style match your suite), and the framework constraints (NUnit, one test fixture per class under test, naming convention like MethodName_Scenario_ExpectedResult, arrange-act-assert layout, one behavior per test).

Structure the ask in two turns for anything non-trivial: first 'list the test cases you would write — name, scenario, expected outcome — as a table; no code yet', then, after you've added the cases it missed and cut the redundant ones, 'now implement exactly this list as NUnit tests'. The case list is reviewable in a minute and turns test generation into spec review — the highest-value minute in this whole workflow.

[TestFixture]
public class DiscountCalculatorTests
{
    [Test]
    public void Calculate_OrderBelowThreshold_ReturnsZeroDiscount()
    {
        // Arrange
        var calculator = new DiscountCalculator(threshold: 100m, rate: 0.1m);

        // Act
        decimal discount = calculator.Calculate(orderTotal: 99.99m);

        // Assert
        Assert.That(discount, Is.EqualTo(0m));
    }

    [TestCase(-1)]
    [TestCase(-100.50)]
    public void Calculate_NegativeTotal_ThrowsArgumentOutOfRange(decimal total)
    {
        var calculator = new DiscountCalculator(threshold: 100m, rate: 0.1m);

        Assert.Throws<ArgumentOutOfRangeException>(() => calculator.Calculate(total));
    }
}

6 Generating Test Cases and Edge Scenarios

Models are superb edge-case brainstormers — they have seen every category of input that has ever broken code. The technique is to ask for scenarios before tests, systematically: 'For this method, list test cases in these categories: happy paths, boundary values for every numeric/size rule, empty/null/whitespace inputs, duplicates and ordering, culture and encoding, concurrency if applicable, and failure paths for each dependency. Table format: case name, input, expected outcome.'

Boundary value analysis deserves explicit demand. For every rule with a limit — 'age must be 18 to 65' — the cases are the values on each side of each edge: 17, 18, 65, 66 (plus the extremes: 0, negative, int.MaxValue). Prompted for a boundary table, the model produces it mechanically and completely; unprompted, it samples a few boundaries and moves on. Boundary tables then map one-to-one onto NUnit parameterized tests — one test method, one [TestCase] row per boundary — keeping the suite compact.

Notice the two 'spec decides!' cells — this is the second gift of case generation. When the model lists a case and you realize you don't know the expected outcome, you have found a hole in the specification, before the code ships. Feed the answer back into both the spec and the tests. Edge-scenario prompting is requirements discovery wearing a testing costume.

7 Generating API Documentation from Code

Documentation generation runs on the same grounding rule as everything else: code alone yields mechanical descriptions; code plus intent yields useful ones. The workable prompt shape: paste the type or endpoint, state the audience ('consumers of our NuGet package', 'frontend developers calling this API'), supply the intent context the code can't carry (units, invariants, why parameters exist), and fix the format (XML documentation comments, an OpenAPI-style endpoint description, or a README section).

• XML documentation comments: 'Write /// docs for every public member: summary (purpose, not mechanism), param (meaning, units, valid range), returns, exception (each condition), one example for non-obvious members.' These feed IntelliSense and doc generators, so they compound.
• Endpoint documentation: paste the controller action plus DTOs; ask for description, parameter table, status codes with conditions, and a realistic request/response example pair. Feed the result into your OpenAPI annotations so rendered docs and code share one source.
• README sections: give the model the public surface plus two working usage snippets and ask for a quick-start — models write excellent 'first five minutes' docs when given real, runnable examples to build around.
• Explanatory docs from tests: pasting the test suite alongside the code is a power move — well-named tests are executable examples of intended behavior, and the docs inherit their precision.

Verification for docs means checking claims, not prose quality: every stated default, unit, range, exception condition, and status code must be confirmed against the code or a run. Models fluently document what code plausibly does, including behaviors it doesn't have. And schedule for doc drift: regenerate member docs in the same pull request that changes the member — a diff-sized doc update reviews in seconds, while 'update all the docs someday' never happens.

8 Reviewing Generated Tests for Coverage and Correctness

Generated tests fail in ways human tests rarely do, because the model optimizes for looking like a test suite. The review targets three specific pathologies. Assertion-free tests: code runs, nothing meaningful is asserted (or only 'is not null') — coverage rises, verification doesn't. Tautological tests: expectations derived from the implementation, so the test proves the code equals itself — including its bugs. Bug-enshrining characterization: when generating tests for existing code, current wrong behavior gets pinned as 'expected'; that's a feature for refactoring safety but a trap when you believe the suite validates correctness.

The coverage review is a different axis: not 'are these tests honest' but 'what behavior has no test at all'. Read the test names against your case list from section 6 — every category (boundaries, empties, failure paths) should be represented. A code coverage tool then finds unexecuted branches, but read its number correctly: coverage proves execution, not verification. An assertion-free suite can hit 95% coverage while catching zero bugs. Coverage tells you where tests are missing; only the honesty check tells you whether the existing ones matter.

9 The .NET Testing and Docs Toolchain Around Your Prompts

• Test frameworks: NUnit (used here — [TestFixture], [Test], [TestCase], Assert.That), xUnit, MSTest. Every prompt shape in this tutorial transfers; only attributes and assertion syntax change — say which framework in every prompt.
• Runner: `dotnet test` executes the generated suite; it is the first honesty gate (does it compile, does it pass) and the sabotage-check runner.
• Coverage: Coverlet + report generators produce the line/branch numbers — the where-are-tests-missing map, never the quality score.
• GitHub Copilot: generates tests inline from open code (tutorials 8–9); the review discipline here applies unchanged to its output.
• XML docs pipeline: /// comments → compiler XML file → IntelliSense, DocFX sites, and NuGet package docs — one generated artifact, three surfaces.
• OpenAPI pipeline: ASP.NET Core annotations + Swashbuckle render endpoint docs; generated endpoint descriptions belong in the annotations so docs live with code.
• CI: run tests and (optionally) coverage thresholds on every PR — generated tests enter the same gate as human ones.

The toolchain's role mirrors tutorial 4's: prompts produce candidates; deterministic tools judge them. `dotnet test` proves the suite runs; your sabotage check proves it verifies; coverage maps the gaps; CI keeps all three honest over time.

10 The Testing & Docs Task Catalog

One composite workflow ties the catalog together: when fixing a bug, generate the regression test first from the bug report (it must fail), fix the code (test goes green), then regenerate the affected member's docs — three generated artifacts, each verified by the one before it.

11 Code Examples in C#

The test-generation prompt template, packing oracle, style, and framework constraints:

public static class TestPrompts
{
    // Turn 1: cases only — reviewed before any code exists.
    public static string BuildCaseListPrompt(string codeUnderTest, string behaviorSpec) => $"""
        List the test cases you would write for the method below.
        Categories: happy paths, boundary values (both sides of every limit),
        empty/null/whitespace, format edge cases, failure paths per dependency.
        Output a table: CaseName | Input | ExpectedOutcome. NO test code yet.

        Behavior specification (source of truth for expectations):
        {behaviorSpec}

        Code under test:
        ```csharp
        {codeUnderTest}
        ```
        """;

    // Turn 2: implement the human-approved list.
    public static string BuildTestImplPrompt(string approvedCases, string exemplarTest) => $"""
        Implement EXACTLY these approved test cases as NUnit tests:
        {approvedCases}

        Rules: [TestFixture] class; MethodName_Scenario_ExpectedResult names;
        arrange-act-assert with comments; one behavior per [Test];
        use [TestCase] rows for the boundary table; Assert.That syntax.
        Match the style of this existing test class:
        ```csharp
        {exemplarTest}
        ```
        """;
}

The documentation prompt for a public member, with intent the code cannot carry:

public static string BuildXmlDocPrompt(string publicMembers, string intentNotes) => $"""
    Write XML documentation comments (///) for each public member below.
    - <summary>: the PURPOSE (why callers use it), not the mechanism.
    - <param>: meaning, units, valid range.
    - <returns> and <exception> for every documented throw condition.
    - <example> for any member whose use is not obvious.
    Document ONLY behavior visible in the code or stated in the notes —
    do not invent defaults, limits, or thread-safety claims.

    Intent notes (context the code cannot express):
    {intentNotes}

    Members:
    ```csharp
    {publicMembers}
    ```
    """;

12 Step-by-Step: Test-Covering a Real Method

This walkthrough covers an untested `ParseQuantity(string input) → int` (valid range 1–999) with a trustworthy NUnit suite. Replay it on any method you own.

1. Write the behavior spec in five lines: valid range 1–999; leading/trailing whitespace tolerated; null/empty/non-numeric throws ArgumentException; out-of-range throws ArgumentOutOfRangeException; no culture-specific digits accepted.
2. Turn 1 — request the case list (template from section 11): the model returns ~18 cases across the categories. Review it: it missed the mixed-digit case ('1٢') and duplicated two happy paths. Add one, cut one.
3. Notice the spec holes the list exposed: what about '+12'? The spec didn't say. Decide (reject it), update the spec, add the case — requirements discovery, on schedule.
4. Turn 2 — request implementation of the approved list with your exemplar test class pasted; receive the [TestFixture] with parameterized boundary rows.
5. Run `dotnet test`: 17 pass, 1 fails — the whitespace case. Investigate: the test is right, the CODE never trimmed input. You just found a real bug with a generated test; fix the code, not the test.
6. Honesty check: sabotage the range check (999 → 998) — boundary tests go red ✓; remove the null guard — null test goes red ✓. Restore. The suite has earned its green.
7. Coverage pass: Coverlet shows the culture-digit branch unexecuted — the model implemented the case but a copy-paste error asserted on the wrong input. One targeted Improve turn fixes it.
8. Finish the artifact set: generate XML documentation comments for ParseQuantity from the now-verified spec — the docs and tests now tell the same story.

13 Limitations and Caveats

• Implementation-derived expectations are the root failure: given only code, the model writes tests proving code == code. Always supply a behavior spec; when generating from legacy code deliberately (characterization), label the suite as stability protection, not correctness validation.
• Assertion quality varies: watch for 'Is.Not.Null' where a value check belongs, and for asserting on the mock instead of the outcome. The sabotage check catches both.
• Coverage numbers flatter generated suites: high execution with weak assertions is the signature pathology. Coverage locates missing tests; it cannot score existing ones.
• Async, time, and randomness need explicit prompting: demand deterministic tests — injected clocks, seeded randomness, awaited assertions — or you'll inherit flaky tests that erode suite trust.
• Mocking depth is a design signal: if generated tests need five mocks per test, the model is faithfully reflecting your coupling — fix the design, don't blame the tests.
• Docs hallucinate specifics: invented defaults, ranges, and thread-safety claims read exactly like real ones. Verify every stated fact; keep the 'do not invent' clause in doc prompts.
• Doc drift resumes the moment you stop: regenerate member docs in the same PR that changes the member, or accept that your docs describe a previous version.

14 Best Practices and Common Mistakes

Practices that make generated tests and docs trustworthy:

• Spec before suite: the behavior specification is the test oracle — write it first, even five lines of it.
• Two turns, always: case list → human review → implementation. The list review is requirements discovery.
• Demand the boundary table for every limit, and implement it as [TestCase] rows.
• Sabotage twice before trusting: a test earns green the day you watch it fail.
• Name tests MethodName_Scenario_ExpectedResult so the name list doubles as the coverage review.
• Docs state purpose, not mechanism; every claimed default/range/exception is verified; 'do not invent' stays in the prompt.
• Regenerate docs and add regression tests in the same PR as the change they concern.

Mistakes that produce theatrical green:

• Generating tests from implementation only — the suite becomes a mirror, bugs included.
• Accepting a 40-test suite wholesale because it's long — volume is the model's cheapest trick.
• Reading 95% coverage as 95% verified — coverage measures execution.
• Keeping a test that never goes red under sabotage 'because it documents intent' — it documents nothing.
• Letting characterization tests of legacy bugs masquerade as correctness validation.
• Publishing generated docs without fact-checking the specifics.
• Treating tests and docs as generation targets once, instead of regeneration targets on every change.

20 Summary & Key Takeaways

• Tests and docs are the model-friendliest artifacts in development — structured, grounded, voluminous — and the easiest to generate convincingly wrong.
• The oracle decides everything: supply a behavior spec, or the model derives expectations from the implementation and certifies its bugs.
• Two turns always: case list → human review (which doubles as requirements discovery) → implementation of the approved list.
• Demand boundary tables for every limit and implement them as [TestCase] rows; ask for edge scenarios by category, not by vibe.
• Green is earned, not observed: read assertions against the spec and sabotage the code until the right tests go red.
• Coverage maps missing tests; it cannot score existing ones — an assertion-free suite posts 95% while verifying nothing.
• Docs need intent the code can't carry, a 'do not invent' clause, fact-checking of every specific, and regeneration bound to the changing PR.
• Regression tests must fail before the fix; characterization suites must be labeled for what they are; flakiness constraints go in the prompt.

You can now direct a model to produce the two artifacts teams chronically lack — and, more importantly, you know exactly how to make their green trustworthy. Next, the course turns to reliability and safety in prompting itself: defending against injection, managing failure modes, and building prompting practices that hold up in production.

21 Next Steps

Continue with the next tutorial in the path: Reliability, Safety & Best Practices in Prompting — prompt injection and defenses, failure-mode handling, output validation at scale, and the operational discipline that makes prompting production-grade.

• Practice: pick one untested method you own and run the full section-12 walkthrough — spec, case list, implementation, sabotage. Count what the workflow catches.
• Practice: take an existing generated (or inherited) test suite and run the 15-minute review — names, assertions, sabotage, coverage. Report to yourself how much of its green was earned.
• Practice: generate XML documentation comments for one public class using the intent-notes template, then fact-check every specific claim it made.
• Practice: on your next bug fix, generate the regression test first and verify it fails before fixing.
• Reading: the NUnit documentation ([TestCase], Assert.That), Coverlet for coverage, and Stryker.NET if you want automated mutation testing.