Java-Junit5-Assertions
Java-Junit5-Assertions is an code AI skill with a core value of Standardizes JUnit 5 (Jupiter) assertions with best practices for performance, readability, and modern features (5. It
helps developers solve real-world problems in the code domain, boosting
efficiency, automating repetitive tasks, and optimizing workflows.
Standardizes JUnit 5 (Jupiter) assertions with best practices for performance, readability, and modern features (5.8+). Covers Supplier messages, assertAll, assertThrowsExactly, and performance-critic
mkdir -p ./skills/java-junit5-assertions && curl -sfL https://raw.githubusercontent.com/github/awesome-copilot/main/skills/java-junit5-assertions/SKILL.md -o ./skills/java-junit5-assertions/SKILL.mdRun in terminal / PowerShell. Requires curl (Unix) or PowerShell 5+ (Windows).
Skill Content
# JUnit 5 Assertions Best Practices
Follow these best practices when writing, reviewing, or refactoring Java test code with JUnit Jupiter (JUnit 5). These rules focus on test accuracy, performance (lazy evaluation), and leveraging modern Jupiter features.
1. Imports
Prefer static imports for assertions to reduce boilerplate. Unless your team conventions dictate otherwise, prefer explicit imports over wildcard (`*`) imports.
// ❌ BAD — verbose and clutters the test method
Assertions.assertEquals(expected, actual);
// ❌ BAD — wildcard import (unless standard in your team)
import static org.junit.jupiter.api.Assertions.*;
// ✅ GOOD — explicit static import
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertTrue;
assertEquals(expected, actual);> **Best for**: Improving readability and keeping test methods focused on logic. Always import from `org.junit.jupiter.api.Assertions`.
2. assertEquals — Expected Value First
`expected` is always the **first** argument, `actual` is always **second**.
// ❌ BAD — swapped; failure message is misleading
assertEquals(calculator.add(1, 1), 2);
// ✅ GOOD
assertEquals(2, calculator.add(1, 1));
// ✅ GOOD — floating point: always provide a delta
assertEquals(0.3, 0.1 + 0.2, 1e-9);> **Best for**: Ensuring failure logs correctly report "Expected [X] but was [Y]".
3. Failure Messages — Supplier vs String
Pass failure messages as a `Supplier<String>` when the message construction is expensive (e.g., string formatting or complex object inspection).
// ❌ BAD — expensive message constructed even when the assertion passes
assertEquals(expected, actual, "Expected %s but got %s".formatted(expected, actual));
// ✅ GOOD — evaluated only on failure (Lazy evaluation)
assertEquals(expected, actual,
() -> "Expected %s but got %s".formatted(expected, actual));
// ✅ GOOD — simple, constant string literal (zero overhead)
assertTrue(isActive, "User account must be active");> **Best for**: Performance-critical test suites and complex diagnostic messages.
4. assertAll — Group Related Assertions
Use `assertAll` when checking multiple properties of the same result. All assertions run even if earlier ones fail.
// ❌ BAD — stops at first failure; other properties go unchecked
assertEquals("Jane", person.firstName());
assertEquals("Doe", person.lastName());
// ✅ GOOD
assertAll("person",
() -> assertEquals("Jane", person.firstName()),
() -> assertEquals("Doe", person.lastName()),
() -> assertEquals(30, person.age())
);> **Best for**: Comprehensive object state verification and avoiding "partial failure" ambiguity.
5. Exception Testing — assertThrows vs assertThrowsExactly
`assertThrows` returns the exception for further verification. Use `assertThrowsExactly` for strict type matching.
// ✅ assertThrows — passes if thrown type IS-A expected type (subclasses accepted)
ArithmeticException ex = assertThrows(
ArithmeticException.class,
() -> calculator.divide(1, 0)
);
assertEquals("/ by zero", ex.getMessage());
// ✅ assertThrowsExactly — passes ONLY if type matches EXACTLY (JUnit 5.8+)
assertThrowsExactly(IllegalArgumentException.class, () -> {
throw new IllegalArgumentException("invalid");
});> **Best for**: `assertThrows` for general hierarchy testing; `assertThrowsExactly` when the precise implementation class is part of the API contract.
6. assertDoesNotThrow
Use when the absence of an exception is the explicit contract being tested.
// ✅ GOOD — captures and returns the result for further assertions
int result = assertDoesNotThrow(() -> service.calculate(data));
assertEquals(100, result);> **Best for**: Explicitly documenting that a specific edge case should not trigger an error.
7. Performance & Deadlines — assertTimeout
Use `assertTimeout` to ensure execution completes within a limit. Use `assertTime
🎯 Best For
- Claude users
- GitHub Copilot users
- Software engineers
- Development teams
- Tech leads
💡 Use Cases
- Code quality improvement
- Best practice enforcement
📖 How to Use This Skill
- 1
Install the Skill
Copy the install command from the Terminal tab and run it. The SKILL.md file downloads to your local skills directory.
- 2
Load into Your AI Assistant
Open Claude or GitHub Copilot and reference the skill. Paste the SKILL.md content or use the system prompt tab.
- 3
Apply Java-Junit5-Assertions to Your Work
Open your project in the AI assistant and ask it to apply the skill. Start with a small module to verify the output quality.
- 4
Review and Refine
Review AI suggestions before committing. Run tests, check for regressions, and iterate on the skill output.
❓ Frequently Asked Questions
Is Java-Junit5-Assertions compatible with Cursor and VS Code?
Yes — this skill works with any AI coding assistant including Cursor, VS Code with Copilot, and JetBrains IDEs.
Do I need specific dependencies for Java-Junit5-Assertions?
Check the install command and Works With section. Most code skills only require the AI assistant and your codebase.
How do I install Java-Junit5-Assertions?
Copy the install command from the Terminal tab and run it. The skill downloads to ./skills/java-junit5-assertions/SKILL.md, ready to use.
Can I customize this skill for my team?
Absolutely. Edit the SKILL.md file to add team-specific instructions, examples, or workflows.
⚠️ Common Mistakes to Avoid
Skipping validation
Always test AI-generated code changes, even for simple refactors.
Missing dependency updates
Check if the skill requires updated dependencies or new packages.