Week 8 Analysis of LLM-Generated Tests Tutorial

In this week’s tutorial you will:

1. Manually fix buggy tests generated by an LLM
2. Analyse why LLMs sometimes produce buggy or incorrect tests (hallucination)
3. Discuss ways to reduce hallucination (prompting, post-processing, iterative generation)
4. Assign groups for Assignment 3 (3 students per group) and confirm your group details

Tutorials are one hour. Work in pairs or small groups where suggested.

Prerequisites

1. At least one LLM-generated test file (e.g. from Week 7 or Assignment 2) that contains at least one buggy or failing test.
2. A Java project and test runner (e.g. JUnit, Maven/IDE) to run and fix tests.

Reference: LLM Hallucinations: Why They Happen, How to Spot Them, and How to Reduce the Risk

Outline (1 hour)

Activity 1: Manually fix buggy tests (~15 min)#

Task 1.1: Run and identify failures#

1. Take one or two test methods (or a small test class) that were generated by an LLM (e.g. from your Week 7 pipeline or A2).
2. Run the tests (e.g. mvn test or run from your IDE).
3. Note which tests fail or error (e.g. compilation error, wrong assertion, wrong API usage).
4. List the symptoms: e.g. “wrong expected value”, “calls non-existent method”, “wrong exception type”.

Do the failures look like “typos” and small mistakes, or like the model “invented” behaviour that doesn’t match the real code?

Task 1.2: Fix the tests by hand#

For each failing test:

1. Locate the cause (wrong assertion, wrong method name, wrong type, etc.).
2. Fix it so the test compiles and passes and still tests the intended behaviour where possible.
3. Write a one-line note (e.g. in a comment) describing what was wrong: e.g. “LLM used assertEquals(5, …) but correct value is 4” or “LLM assumed method X existed; replaced with Y”.

Keep fixes minimal so you can later compare “what the LLM did wrong” vs “what a human had to change”.

Activity 2: Analyse why LLMs generate buggy tests (~15 min)#

Task 2.1: Categorise the bugs#

As a group or pair, classify the bugs you found into categories. For example:

• Wrong API or signature: e.g. wrong method name, wrong number/type of arguments.
• Wrong expected value: e.g. wrong constant, wrong order of arguments in assertion.
• Wrong control flow: e.g. wrong exception type, missing setup.
• Syntactic / style: e.g. wrong import, wrong JUnit annotation.
• Hallucination: the model “invented” behaviour (e.g. return value, method, or class) that does not exist in the real code.

Discuss: Which of these are “hallucination” in the sense of the model being confident but wrong? Which are more like ambiguity (e.g. underspecified prompt) or context limits (e.g. model didn’t have enough code context)?

Task 2.2: Why do hallucinations happen?#

Read or recall the main ideas from the reference on LLM hallucinations. Then briefly answer:

1. Why might an LLM produce a plausible-looking test that doesn’t match the real code? (e.g. training on similar but different APIs, no execution feedback, limited context.)
2. How can you spot such tests? (e.g. run tests, use compiler, check method existence, compare to source.)

If the LLM had been given more code context (e.g. full method body, return type, exceptions), would that reduce some of the bugs you saw? Which ones?

Activity 3: Ways to reduce hallucination (~15 min)#

Task 3.1: Three directions#

Discuss and jot down one concrete idea for each of the following (in the context of test generation):

1. Prompting: How could you change the prompt (e.g. instructions, examples, format) to reduce wrong API use or wrong expected values?
2. Post-processing: What automated checks could you run on the generated code before accepting it? (e.g. compile with javac, run a linter, check that method names exist in the project.)
3. Iterative generation: If the first attempt fails (e.g. compile error or test failure), how could you feed the error back to the LLM and ask for a fixed version? (We will implement a simple version in Week 10.)

Share one idea per category with another group. Which approach do you think would help most for the bugs you saw in Activity 1?

Task 3.2: Quick design (optional)#

Sketch a one-sentence pipeline:
“First we … then we … if it fails we …”
that uses at least one of: better prompting, post-processing, or iterative regeneration.

Activity 4: Assign groups for Assignment 3 (~15 min)#

Task 4.1: Form your group (3 students per group)#

1. Form your Assignment 3 group (exactly 3 students per group).
2. Choose teammates thoughtfully and confirm everyone can commit for the rest of the semester.
3. Once formed, your group should remain unchanged for the semester (unless staff approve an exception).

Task 4.2: Submit group details to your tutor#

Provide your tutor with:

• Full name and student ID of each member

Task 4.3: Check the group list / resolve issues#

If your tutor cannot find your name on their list for any reason, message the instructors on EdStem. A group list may also be made available on the course site.

Reminder: Assignment 3 includes a group presentation in the final tutorial. Plan early and divide responsibilities.

References

• LLM Hallucinations: Why They Happen, How to Spot Them, and How to Reduce the Risk