单元测试 – 单元测试:记录和依赖注入

前端之家收集整理的这篇文章主要介绍了单元测试 – 单元测试:记录和依赖注入前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
因此,从SO和其他网站在互联网上的录像最好的回应似乎是:
void DoSomething() {
    Logger.Log("Doing something!");
    // Code...
}

现在通常你会避免使用静态方法,但是在记录(特殊情况)的情况下,这是最简单和最干净的路由。在静态类中,您可以通过配置文件/框架轻松地注入一个实例,使其具有与DI相同的效果

我的问题来自于单元测试的角度。

在上面的示例代码中,想象DoSomething()的一点是将两个数字加在一起。我会写这个罚单的单位测试。记录怎么样?

我会为日志记录写一个单元测试(但是为记录器本身使用模拟实例)?我知道如果是这样,我必须编写一个集成测试来证明记录器实际写入一个日志文件,但我不确定。

在测试驱动开发(我做)之后,我需要单元测试来规定接口否?

任何建议?

就个人而言,我在宗教上练习TDD / BDD,我几乎不会测试日志记录。有一些例外,日志记录是开发人员的便利性或可用性因素,而不是方法核心规范的一部分。它也往往比方法的实际语义具有更高的变化率,所以你只是因为添加了一些更多的信息记录而打破了测试。

可能有一些测试只需要运行日志子系统,但对于大多数应用程序,我不会测试每个类以特定方式使用日志。

原文链接:/javaschema/282082.html

猜你在找的设计模式相关文章