| name | java-junit |
| description | JUnit 5 testing best practices for this Java Spring Boot backend. Use when adding or reviewing backend tests, Mockito tests, parameterized tests, Spring Boot test slices, integration tests, or Maven test commands. |
JUnit 5 Best Practices
Source: adapted from github/awesome-copilot skill java-junit and this repository's Spring Boot testing conventions.
When to Use
- Adding tests under
backend/src/test/java
- Refactoring Java code and deciding what tests should move with it
- Writing controller, service, repository, or configuration tests
- Introducing parameterized tests or Mockito-based unit tests
Procedure
- Inspect
backend/pom.xml to confirm the available JUnit, Spring Boot Test, Mockito, AssertJ, and testcontainers dependencies.
- Place tests under
backend/src/test/java mirroring the production package where practical.
- Prefer the narrowest useful test type:
- Plain JUnit + Mockito for service logic
@WebMvcTest for controller behavior@DataJpaTest for repository behavior when JPA exists@SpringBootTest only when full context wiring is part of the behavior under test
- Use Arrange-Act-Assert structure and descriptive test names such as
methodName_shouldExpectedBehavior_whenScenario.
- Keep tests independent and deterministic. Do not rely on execution order unless the test is explicitly documenting order-sensitive behavior.
- Use
@ParameterizedTest with @ValueSource, @CsvSource, @EnumSource, or @MethodSource when the same behavior needs multiple inputs.
- Prefer AssertJ fluent assertions when available; otherwise use JUnit assertions with clear failure messages.
- Mock external collaborators, not value objects. Verify observable outcomes before implementation details.
- For Azure integrations, keep local unit tests credential-free. Integration tests should use test doubles or explicitly documented test resources.
- Run tests from
backend with mvn test when Maven is available.
Review Checklist
- Test name describes behavior and scenario
- Test has one clear reason to fail
- Mocks are used only at service boundaries
- Parameterized tests avoid copy-pasted cases
- Spring test scope is no broader than needed
- No test requires real Azure credentials by default
