什么不应该进行单元测试?

我的一般方法是“如果这段代码不值得测试,为什么它首先值得拥有”?如果我使用的是一种迫使我拥有大量无用的重复样板的语言,那么如果语言的编译器可以检查这些部分,那么也许我不需要测试这些部分;但我通常使用我编写的代码实际上有意义的语言;-)。

你能给出一个很难进行单元测试的问题的例子吗?我听说这是一个借口,用来避免测试错误恢复和诊断代码,这些代码只由罕见和极不可能的情况触发,但每次出现这种情况时,我都会争辩说,恰恰相反,该代码才是真正的原因 需要单元测试,因为它不会在集成测试和正常使用中得到锻炼(例如在QA阶段)。

依赖项注入允许您使用伪对象或模拟对象来表示(无论是什么“永远不会导致此错误,但我们无论如何都会对此进行覆盖”--网络、数据库、电源控制接口等),你的假代码或模拟代码很容易就会导致各种各样的假错误,所以你可以彻底检查错误恢复和诊断代码。

但我最近转向了商业智能,我注意到这种方法也能很好地转换:如果我的代码生成的数字(可能会向商业决策者显示一个漂亮的图表等)值得生成,那么它们最好是准确的,这意味着(除其他外)产生它们的代码需要像监视网络或电源系统的代码一样进行彻底和仔细的测试

这是一个成本和收益的问题,你越想接近100%,成本就越高。

还有UI层,如果这是一种难以测试的技术,您可以对该层进行编程,使其尽可能薄,然后仅手动测试。

根据您的情况,您可以通过层和生成的代码放弃测试。

请注意,这不仅仅是一个代码覆盖率的问题,而是一个如何测试的问题,最好对有限的代码部分进行多次测试,并降低代码覆盖率。

您不应该为其他人的代码(例如您正在使用的框架)编写单元测试。您应该只为代码编写测试。模拟对其他人代码的依赖,这样您只需要为自己的代码编写测试。

关于我目前正在做的项目 自动化 功能和系统功能的测试,但没有 单元 所有测试: Should one test internal implementation, or only test public behaviour?

有些人说,单元测试的唯一替代方法是临时手动测试;但是,许多好处(例如回归测试)都来自于测试 自动化 和 不 一定是因为它在 单元 数量

您不需要测试语言结构,但除此之外,没有任何东西“不应该”进行单元测试。

如果在某些情况下,您已经获得了设计,并且有很好的理由证明它存在,并且它不是应用程序的关键任务部分,例如一个次要的用户界面特性,那么就可以创建一个不一定值得为其进行单元测试的情况。但这并不一定与单元测试中的“不应该”相同。

自动单元测试不能在图形代码上运行,因为计算机无法决定屏幕上显示的内容是否正确!