Java Test Quality

Workflow

1. Identify behavior, edge cases, failure paths, and integration contracts affected by the change.
2. Choose the smallest test scope that catches the risk.
3. Use project-standard test libraries and naming.
4. Keep tests deterministic, isolated, and readable.

Checks

• Test names describe scenario and expected behavior.
• Arrange/Act/Assert structure is visible.
• AssertJ assertions are specific and compare meaningful fields.
• Exceptions are asserted with type, message or important context, and side effects when relevant.
• Mocks verify externally visible collaboration only; avoid overspecifying internal calls.
• Fixtures are minimal and named by intent.
• Parameterized tests cover meaningful input partitions.
• Nested tests group behavior only when they improve scanability.
• Use soft assertions when multiple independent facts need one combined failure report.
• Tests avoid sleeps, shared mutable state, real clocks, random data without seed, and environment dependence.
• Integration tests cover wiring, persistence mapping, serialization, transactions, and external boundaries where unit tests cannot.
• Coverage targets business rules and risk, not line count alone.
• Mutation-prone business rules get explicit boundary and negative tests.
• Coverage config excludes generated code only when the project convention already allows it.

Output