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

Question

我觉得有些问题只是难以进行单元测试.即使你这样做,通常这样的测试几乎没有价值.

除了getter和setter之外,什么代码不应该进行单元测试？

(可能与此问题类似)

Answer 1

我的一般方法是"如果这个代码不值得测试,为什么它首先值得拥有"？如果我使用的语言迫使我有很多无用的重复样板,那么如果语言的编译器只能检查它们,我可能不需要测试这些部分; 但我通常使用的语言,我写的代码实际上是有意义的;-).

你能举出一个难以进行单元测试的问题的例子吗？我听说这是一个借口,以避免测试错误恢复和诊断代码只是由罕见和非常不可能的情况引发,但每次出现这种情况我都认为,相反,该代码是一个大多数需要单元测试,因为它不会在集成测试和正常使用中运用(例如在QA阶段).

依赖注入允许你使用假或模拟对象代表(无论"应该永远不会导致此错误,但我们无论如何都要覆盖它" - 网络,数据库,电源控制界面等),你的假或模拟容易并且肯定会导致各种假错误,因此您可以彻底检查错误恢复和诊断代码.

也许这取决于你写的是什么类型的应用程序 - 在过去的几年里,我主要使用集群管理软件,在那里可能出错的一切都会出现,很多事情都不会出错,无论如何,正常运行时间和快速恢复至关重要.在那个领域,没有人会敢于反对腰带和吊带的方法(如果他们确实可靠性工程师会用棍棒跟随他们;-).

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

Answer 2

这是一个成本和收益的问题,你越接近100%,它就会越贵.

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

根据您的情况,您可以删除测试传递层和生成的代码.

请注意,这不仅仅是代码覆盖问题,而是您如何测试,在代码的有限部分和较低的代码覆盖率上进行许多测试可能会更好.

Answer 3

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