这是另一种测试气味 。
测试中日志消息的目的是什么？
有时，通过测试套件中的记录器或stdout记录日志消息。 他们发生了。 有时它们的发生是有原因的，但是通常当您查看这些原因时，往往表示缺少更好的东西：
- 我想知道测试在做什么
- 测试现在有哪些数据？
- 为什么那个时候测试失败了？
通常，日志记录不是很好的解决方案，其原因是：
记录的消息通常不是测试报告的一部分，也通常不会影响测试结果。
换句话说，测试我们的测试以与我们交谈可能会做得更好。
何时添加日志消息？
当它们在CI服务器上失败时，我暂时 （然后将它们留在那儿）向一些测试中添加了一些日志输出，或者偶尔在本地（但是我可以在本地调试），以便让我了解发生了什么。 通过将这些日志消息从真正的需求中驱除，而这些需求可能是我可能需要有关环境或特定数据的事实，我证明了这个偶然的问题可能会在管道出现故障时挽救我的屁股，但是这些不是整体测试开发策略的一部分。
那么测试在做什么？
测试不是一个脚本，该脚本统治并手动输出其所在位置的叙述。 如果将测试正确地分解成多个测试用例，那么执行这些测试用例的测试运行者应该提供有关发生的情况和时间的反馈。
诸如Cucumber和Serenity之类的测试框架可用于构建测试和测试代码以自动提供叙述，这可能会更丰富，更重要的是，它们可以在最后生成报告以将发生的事情与假设的规范相关联进行测试。
我们正在处理什么数据？
跟踪数据的问题取决于上下文。 如果我们有测试数据，我们应该从测试执行中的位置知道正在使用什么。 如果我们使用的是数据驱动的测试，那么也许我们通过参数化测试运行程序或数据驱动的测试框架构建测试的方式应该自动使用所使用的数据来检测我们的测试报告。 如果我们正在从被测系统中即时接收数据，那么上帝会帮助我们……这就是我们最终需要添加诊断信息以帮助理解故障的地方。 理想情况下，这些诊断应该更接近我们检测故障的方式。
什么是失败？
使用断言！
在那里，我说了。
提出断言不仅解释他们进行的比较，而且解释他们进行比较的环境。 但是，不要陷入试图在每个断言中编写无意义的glib注释的陷阱。
许多断言是它们所处测试步骤的根源，因此我们知道其上下文。 但是，如果断言不太明确，或者我们觉得有必要提供与我们断言的事物相关的其他数据的补充信息，例如，我们不仅断言HTTP状态代码，还显示代码时的HTTP正文。不是我们所期望的-那么我们应该对断言进行检测，而不是添加日志记录。
结论
与深入研究日志相比，您读取红色/绿色状态和测试套件的测试报告的次数更多。 使用框架，尤其是断言库来绘制关于测试内容和结果的最可靠的描述，将是解释它的最佳策略。
翻译自: https://www.javacodegeeks.com/2020/02/chatty-logging-in-tests.html
