The test failure that taught me to write better debugging prompts was a flaky integration test that failed roughly one CI run in five. I pasted the assertion error into an AI assistant and got back five generic guesses, none right. Then I pasted the complete picture — full stack trace, the whole test class, the production method, and the fact that it only failed in parallel runs — and the diagnosis (shared static state in a test fixture) came back in one reply. The lesson: with debugging, the prompt is mostly evidence collection.

This post collects 10 prompts for diagnosing and fixing broken, flaky, or misbehaving JUnit 6 tests, each structured around the evidence that particular failure type needs — so the AI diagnoses the root cause instead of guessing. Tested with Claude Sonnet 4 and GPT-4o against JUnit 6.0, Mockito 5.x, and Spring Boot 3.4 failures.

For complementary reading, see Debugging JUnit 6 Tests: Fix Failures Like a Pro and How to Fix Flaky Tests in JUnit 6.

Existing test suites accumulate technical debt just like production code. Tests that were written quickly become brittle, slow, hard to read, or duplicated. Optimising and updating your JUnit 6 tests is not just housekeeping — it directly determines whether your test suite remains a trusted safety net or becomes a maintenance burden that developers work around.

This post gives you 10 targeted AI prompts designed to refactor, improve, and modernise existing JUnit 6 test code. Each prompt addresses a specific quality problem — from brittle mocking to slow Spring contexts to missing boundary cases — and produces immediately usable improved test code.

For foundational context, see Writing Maintainable Tests in JUnit 6 and Refactoring Legacy Tests to JUnit 6.

The first time I asked an AI assistant to generate tests for a service class, it gave me fifteen green tests that verified almost nothing — assertNotNull on every line, mocks returning values no production system would produce, and not a single boundary case. The tests passed; they just didn’t protect anything. What changed the output quality wasn’t a better model — it was a better prompt: one that pinned the JUnit version, demanded specific annotations, listed the scenarios that had to be covered, and forced meaningful assertions.

This post collects the 10 prompts for generating JUnit 6 tests that came out of that process — refined across real projects until the output was something I could commit after a review pass rather than a rewrite. They work with GitHub Copilot, Claude, ChatGPT, JetBrains AI, or any capable LLM. Tested against Claude Sonnet 4 and GPT-4o, generating tests for JUnit 6.0 with Mockito 5.x and Spring Boot 3.4.

For background on JUnit 6 test structure, see the JUnit 6 Tutorial Series. For best practices on what makes a test maintainable, see Writing Your First Clean Test in JUnit 6.