TDD规则与Java重写equals必重写hashCode约定冲突如何处理

TDD第一条规则：Write production code only to pass a failing unit test（仅当为了通过失败的单元测试时才编写生产代码）
《Effective Java（第三版）》第11条Java官方约定：Always override hashCode when you override equals（重写equals时必须同时重写hashCode）

很多人会误以为这两个规则在此场景下存在冲突，实际处理逻辑非常明确：

• 必须同步重写equals和hashCode两个方法，而非只重写equals来通过当前测试。Java中equals和hashCode的联动是语言层面的强制契约，不属于"额外的业务功能"范畴，只要重写了equals就必须遵守该契约，否则类的行为不符合Java规范，后续如果该类被放入HashMap、HashSet等依赖哈希值的集合中，会直接出现元素去重失败、找不到元素等极难排查的隐式BUG，哪怕你当下不需要集合场景，也不能写出违反基础规范的代码。
• TDD的规则约束的是无测试支撑的业务逻辑开发，并不是鼓励开发者忽略语言基础规范。你只需要额外补充一个验证hashCode契约的单元测试用例：验证两个equals返回true的对象哈希值一定相等，该测试用例本身就是对类契约的必要覆盖，完全符合TDD的要求，不存在"写了没有对应测试的生产代码"的问题。
• 如果确定该类未来绝对不会用于集合场景（极端情况），也必须在hashCode方法的实现里抛出UnsupportedOperationException，并且添加明确的注释说明该类不支持哈希相关操作，避免后续被误用，绝对不能直接使用父类Object的hashCode实现，否则等于隐性破坏了Java规范。

内容的提问来源于stack exchange，提问作者Mohammad Yasin