Java 在非测试代码中使用Hamcrest匹配器是否可以接受

我试图找到在非测试代码中使用Hamcrest匹配器的最终答案。我做了一些研究，并引用了一些对比的话：

• Hamcrest关于：
  Hamcrest是一个框架，帮助用Java编程语言编写软件测试。[snip]这些匹配器在JUnit和jMock等单元测试框架中有用途

• Hamcrest关于：
  Hamcrest是一个匹配器库，可以将其组合在一起，在测试中创建灵活的意图表达

• Hamcrest关于：
  注意：它不是一个测试库：匹配器在测试中非常有用

就个人而言，我将匹配器与测试相关联，因此我倾向于避免在测试之外使用它们。尽管如此，我看不出任何限制会阻止它们在测试范围之外使用

---

那么这是否归结为个人偏好呢？

到目前为止，我已经在非测试代码中多次使用了Hamcrest。大多数情况下，当我想在同一对象上测试不同的条件时，我会使用它来获得关于哪些条件因什么原因失败的报告。然后将单个条件表示为不同的对象，这也会产生其他一些好的效果。例如，检查应用程序配置可以产生支持哪些操作的数据的结果

我特别使用hamcrest执行此类任务的原因：

• 它的设计就是为了做到这一点（测试条件不仅仅是在测试代码中完成的）
• 它不会带来额外的依赖关系
• 众所周知，许多人已经将其用于测试代码
• 具有易于使用的小API
• 易于扩展，并能很好地支持合成

最后归结起来就是为这项工作选择合适的工具。例如，Bean验证可以用于做相对类似的工作。此外，还需要做出深思熟虑的决策，这也包括了开发过程和环境的要求

此外，使用匹配器也是采用“告诉，不问”原则的一种好方法。您可以将匹配器传递给方法，以指示希望返回的返回值。如果所讨论的对象与该匹配器不匹配，则可以立即抛出一个具有良好错误描述的异常

---

另外，当比较匹配器与java 8的

谓词的使用时，匹配器的优点是能够提供描述，但缺点是它们本身不是功能接口。
可以在非测试代码中使用。例如，LambdaJ库支持Hamcrest匹配器：
只需使用它即可。我不明白为什么使用它是不可接受的。