A：logger的输出和一个方法的return, exception, output parameter一样，都可以视为这个方法的输出。如果logger的输出的确代表了功能需求，那我们就应该去测试它，包括单元测试（比如用程序读log文件然后与expectation比较）。典型的用况是批量操作中部分失败的日志。按需求，如果部分失败，不能抛exception，而应该把部分的失败放到日志中去。
B：log是跟业务相去甚远的东西，不应该把它当作模块的一种输出，因此不能做单元测试；至于前面提到的批量操作的例子，应该把日志将要打印的错误信息置为单个操作的返回值或者异常消息，然后只针对批量中的单个操作进行单元测试。只要单个操作的测试通过了，没必要再对批量操作施加日志相关的测试了。
A: 但是批量操作的日志可能不仅是各个单步操作的简单叠加。它的日志可能跟批量操作的上下文有关，而单步操作的方法可能不方便访问这个上下文；又或者批量操作输出的日志可能跟若干单步操作结果的组合有关，针对单步操作的方法无法进行这种测试。
B: 那批量操作的代码就应该重构了。应该把所有的出错信息作为return值或output parameter的值，输出来，再用单元测试的代码去验证它。
A：这似乎是比较优雅的方案。它不但解决了我们的争论，而且还使得log代码不能入侵到业务逻辑之中，使业务逻辑更干净。不过，这可能会存在性能问题。如果一个批量操作中有十几万条错误信息，把这些错误信息放到一个变量里，可能会导致内存溢出。如果用log来做，就没有这个问题，因为它见一条处理一条，不会产生巨大的对象。
B：…
A：…