Back to Details

java-test-quality

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Java Test Quality

Java测试质量

Make Java tests prove behavior, not mirror implementation. Prefer clear failure messages and stable fixtures.
让Java测试验证行为，而非复刻实现。优先选择清晰的失败提示信息和稳定的测试夹具。

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.
  1. 识别变更影响到的行为、边界情况、失败路径以及集成契约。
  2. 选择能够捕获风险的最小测试范围。
  3. 使用项目标准的测试库与命名规范。
  4. 确保测试具有确定性、独立性和可读性。

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.
  • 测试名称需描述场景与预期行为。
  • Arrange/Act/Assert结构清晰可见。
  • 使用AssertJ断言时需明确具体，且对比有意义的字段。
  • 断言异常时，需验证异常类型、消息或重要上下文，必要时还要验证副作用。
  • Mock对象仅验证外部可见的协作；避免过度指定内部调用。
  • 测试夹具应尽可能精简，并根据用途命名。
  • 参数化测试需覆盖有意义的输入分区。
  • 仅当嵌套测试能提升可读性时，才用其对行为进行分组。
  • 当需要将多个独立事实合并为一份失败报告时，使用软断言。
  • 测试应避免使用睡眠、共享可变状态、真实时钟、无种子的随机数据，以及依赖环境的操作。
  • 集成测试需覆盖单元测试无法涉及的组件连接、持久化映射、序列化、事务以及外部边界。
  • 覆盖率目标应聚焦于业务规则与风险，而非单纯的代码行数。
  • 易发生变异的业务规则需添加明确的边界测试与负面测试。
  • 仅当项目惯例允许时，覆盖率配置才可排除自动生成的代码。

Output

输出

When adding tests, include normal path, edge path, and failure path if relevant. When reviewing, distinguish missing coverage from brittle or low-value tests.
See EXAMPLES.md for Java test examples.
添加测试时，若相关则需包含正常路径、边界路径与失败路径。审查测试时，需区分缺失覆盖率的情况与脆弱或低价值的测试。
查看EXAMPLES.md获取Java测试示例。