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

Question

我的印象是有些问题很难进行单元测试。即使你这样做了，这样的测试通常也没有什么值(value)。

除了 getter 和 setter 之外，哪些代码不应该进行单元测试？

(可能类似于 this question )

Answer 1

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

你能举一个很难进行单元测试的问题的例子吗？我听说这是避免测试错误恢复和诊断代码的借口最需要单元测试，因为它不会在集成测试和正常使用中得到锻炼(例如在 QA 阶段)。

依赖注入(inject)允许你使用一个假的或模拟的对象来代表(任何“不应该导致这个错误但我们无论如何都会覆盖它”——网络、数据库、电源控制接口(interface)等)，你的假或模拟很容易可以并且肯定会导致各种虚假错误，因此您可以彻底检查错误恢复和诊断代码。

也许这取决于你写什么类型的应用程序——在过去的几年里，我主要从事集群管理软件，所有可能出错的东西都会出错，很多不可能出错的东西都会出错，而且正常运行时间和快速恢复至关重要。在那个领域，没有人敢反对带吊带的方法(如果他们这样做，可靠性工程师会用棍子追赶他们；-)。

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