Software Engineering with AI Assistance

Testing, Review, and Documentation with AI


Learning Objectives

  • You understand where AI assistance can be useful in testing, review, and documentation.
  • You know common weaknesses of AI-generated tests and review comments.
  • You can use AI support while still keeping verification under human control.

AI-assisted testing

Large language models are often good at proposing test cases quickly. This is especially helpful when you want help enumerating successful paths, missing-input cases, malformed-input cases, and output-format edge cases.

However, AI-generated tests are often weaker than they first appear. They may test only the happy path, repeat the implementation logic instead of checking behavior, or use vague assertions that would pass even if the program were wrong.

For example, a weak test might only check that “some output exists”. A stronger test checks the exact value or exact structure of the output.

Consider the function:

const isPassing = (grade) => grade >= 90;

A very weak test would be:

assert(typeof isPassing(80) === "boolean");

A stronger test is:

assertEquals(isPassing(90), true);
assertEquals(isPassing(89), false);

The stronger test says what the function should actually do.

Good tests reduce room for interpretation

When a test only checks that something happened, it leaves too much room for incorrect behavior. Good tests reduce ambiguity by making expectations explicit.


Strong and weak tests

0 / 5 points

A function normalizeName(name) should trim whitespace and convert text to lowercase. Which test is stronger?

A useful testing prompt therefore needs to say what kind of tests are wanted. For example:

Read the specification below and propose concrete test cases.
Include successful cases, invalid-input cases, and boundary cases.
State the expected behavior for each test.
Avoid vague checks such as "some output exists".

This kind of prompt encourages the model to connect its suggestions to the specification instead of producing generic testing advice.

Test cases from a specification

0 / 10 points

Write a prompt that asks a large language model to propose concrete test cases from a short software specification.

During grading, the specification will be appended after your prompt.

Keep your prompt under 75 words.

Ask the model to return at most four test cases in this compact format:

  • case: ... => expected: ...

The test cases should be derived from the specification, include exact expected behavior where possible, and cover both successful and failing or boundary inputs.

At the same time, the engineer still has to decide whether the proposed tests are good enough to keep. A test that looks technical can still be too weak to protect the real behavior.

Reviewing AI-generated tests

0 / 10 points

You ask an LLM to suggest tests for a function sum(a, b) that should return the numeric sum of its two inputs. It suggests these three tests:

assert(typeof sum(2, 3) === "number");
assertEquals(sum(2, 3), 5);
assertEquals(sum(-1, 1), 0);

Briefly explain which test you would reject first and why. Your answer should mention what kind of check would be stronger instead.

Respond with at most four sentences and start with I would reject....

Code review support

AI tools can also help review code by pointing out possible issues such as:

  • missing validation,
  • duplicated logic,
  • unclear names,
  • or error cases that seem unhandled.

This can be useful as a second pair of eyes. But review suggestions still need review themselves. A model may claim that something is a bug when it is actually an intentional design choice, or it may miss the most important problem entirely.

Early security-focused research on LLMs — at least the early ones — reinforces the same point. See Do Users Write More Insecure Code with AI Assistants?, the later empirical study Security Weaknesses of Copilot-Generated Code in GitHub Projects: An Empirical Study, and the mitigation-oriented paper Large Language Models for Code: Security Hardening and Adversarial Testing.

Limits of review assistance

0 / 5 points

Why should AI-generated review comments still be reviewed by a human?

Documentation support

Documentation is another area where AI assistance can be helpful. It can:

  • summarize a function,
  • draft a README section,
  • explain command-line flags,
  • or propose a changelog entry.

Still, documentation should reflect the actual behavior of the program, not only what the code appears to do at a quick glance. If the implementation changed during debugging or refactoring, old descriptions may become inaccurate.

Early examples of using LLMs for helping with documentation included also tasks like automatically creating Git commit messages.

Documentation should name boundaries and assumptions

Documentation is especially useful when it makes the boundaries of a program clear. For instance, a command-line tool may need to document required environment variables, expected input files, output formats, or cases where the program deliberately rejects weak input.

These details matter because later LLM-powered programs often depend on small explicit contracts. If a module expects JSON with two keys, the documentation should say so. If a CLI tool needs --allow-read and --allow-env, the usage notes should say so. AI can help draft that text, but the engineer still has to decide whether the draft matches the actual behavior.

The same review habit matters for documentation too. A generated README section may look polished while still omitting required permissions, environment variables, or cases where a feature is optional rather than automatic.

Reviewing AI-generated documentation

0 / 10 points

You ask an LLM to draft usage notes for a command-line tool. It suggests this README section:

Run the tool with deno run main.js input.txt.
The program reads the file, contacts the model API, and writes a transcript automatically.

In reality, the tool requires the environment variables LLM_API_KEY and LLM_MODEL, needs --allow-read --allow-env, and writes a transcript only when TRANSCRIPT_PATH is set.

Briefly explain whether you would accept, revise, or reject the suggested documentation, and why.

Respond with at most four sentences and start with I would....