我发现关于TDD的事情是它需要时间来设置你的测试并且自然是懒惰的我总是想写尽可能少的代码.我似乎做的第一件事是测试我的构造函数已经设置了所有的属性,但这是否有点过分？
我的问题是你在单元测试中写出了什么级别的粒度？
..是否有一个测试太多的情况？
所以关于来自SO和其他互联网站点的日志记录,最佳响应似乎是:
void DoSomething() {
Logger.Log("Doing something!");
// Code...
}
现在通常你会避免静态方法,但在记录(特殊情况)的情况下,这是最简单和最干净的路线.在静态类中,您可以通过配置文件/框架轻松注入实例,以获得与DI相同的效果.
我的问题来自单元测试的角度.
在上面的示例代码中,想象DoSomething()的意思是将两个数字加在一起.我会为这个罚款写单元测试.伐木怎么样？
我是否会为日志记录编写单元测试(但是对于记录器本身使用模拟实例)？我知道如果是这种情况我将不得不编写一个集成测试来证明记录器实际写入日志文件,但我不确定.
在测试驱动开发之后(我这样做)我需要进行单元测试才能决定接口没有？
有什么建议？
例如,它生成了一个log(my_work.log)内容:
I, [2015-05-14T00:00:00.000000 #5590] INFO -- : Work started.
我想测试my_work.log是否有内容Work started.,该怎么办？
我不想匹配所有行包括datetime,因为包含#5590,我不能存根.