[对谈录]是否可以把logger的输出视为一个方法的output, 并针对它进行单元测试？

   A：logger的输出和一个方法的return, exception, output parameter一样，都可以视为这个方法的输出。如果logger的输出的确代表了功能需求，那我们就应该去测试它，包括单元测试（比如用程序读log文件然后与expectation比较）。典型的用况是批量操作中部分失败的日志。按需求，如果部分失败，不能抛exception，而应该把部分的失败放到日志中去。

   B：log是跟业务相去甚远的东西，不应该把它当作模块的一种输出，因此不能做单元测试；至于前面提到的批量操作的例子，应该把日志将要打印的错误信息置为单个操作的返回值或者异常消息，然后只针对批量中的单个操作进行单元测试。只要单个操作的测试通过了，没必要再对批量操作施加日志相关的测试了。

   A: 但是批量操作的日志可能不仅是各个单步操作的简单叠加。它的日志可能跟批量操作的上下文有关，而单步操作的方法可能不方便访问这个上下文；又或者批量操作输出的日志可能跟若干单步操作结果的组合有关，针对单步操作的方法无法进行这种测试。

   B: 那批量操作的代码就应该重构了。应该把所有的出错信息作为return值或output parameter的值，输出来，再用单元测试的代码去验证它。

   A：这似乎是比较优雅的方案。它不但解决了我们的争论，而且还使得log代码不能入侵到业务逻辑之中，使业务逻辑更干净。不过，这可能会存在性能问题。如果一个批量操作中有十几万条错误信息，把这些错误信息放到一个变量里，可能会导致内存溢出。如果用log来做，就没有这个问题，因为它见一条处理一条，不会产生巨大的对象。

   B：...
   A：...
 

把它当成一个全局性的方法,别的类直接调用一下就可以了.
such as:
System.out.pringln();

就行了.不用搞那么复杂.

在回归测试时自动安装布署后用shell程序去检查一下error日志
来决定是否运行下面的测试步骤

那你怎么用程序验证它的输出符合预期？

你的意思是仅仅检查一下日志能否产生，而不用去检查日志的内容是否符合预期？

现在正在运行的daylaiy测试
能否正确安装成功也是测试的一部分
由于没有人在边上观察
所以把error.log里的内容进行判断
如果含有error字眼则认为安装失败(正则...我认为只要字节数对就可以了但为了以后扩展加了这个正则表达式.)
后面的测试也就不用测试了.

是否可以说，你也同意log可以作为模块的一种输出？

非常的难用...
非到万不得以
不建议使用.

有时要延时后才能生效.
有时还会被卡住....
(原因未知)

推荐你去看一下 NetBeans架构师写的那本书
特别是第11章节 看他们是怎么用日志的
相比之下，我们的设计能力还是差上很多啊

书名?传送门