什么不应该进行单元测试? [英] What should NOT be unit tested?

问题描述

我的印象是有些问题很难单元测试.即使你这样做了，这些测试通常也没有什么价值.

I got the impression that some problems are just to hard to unit test. And even if you do it, often such tests provide little value.

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

What code should not be unit tested, apart from getters and setters?

(可能类似于这个问题)

推荐答案

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

My general approach is "if this code is not worth testing, why is it worth having in the first place"? If I'm using a language which forces me to have a lot of uselessly repetitive boilerplate, then maybe I don't need to test those parts if the language's compiler can just check them; but I normally use languages where code I write is actually meaningful;-).

你能举一个很难单元测试的问题的例子吗?我听说这被用作避免测试仅由罕见且极不可能的情况触发的错误恢复和诊断代码的借口，但每次出现这种情况时，我都争辩说，相反，该代码是唯一的最需要单元测试，因为它不会在集成测试和正常使用(例如在 QA 阶段)中得到锻炼.

Can you given an example of problem that's too hard to unit-test? I've heard this used as an excuse to avoid testing error-recovery and diagnostic code that's only triggered by rare and very unlikely circumstances, but every time this has come up I've argued that, on the contrary, that code is the one most needing unit tests, because it's not going to get exercised in the integration tests and normal use (e.g. at QA stage).

Dependency Injection 允许你使用一个假的或模拟的对象来代表(无论什么不应该导致这个错误，但无论如何我们都会覆盖它"——网络、数据库、电源控制接口等)，以及你的假或轻松模拟可以而且绝对应该导致各种虚假错误，因此您可以彻底检查错误恢复和诊断代码.

Dependency Injection lets you use a fake or mock object to stand for (whatever "should never cause this error but we're covering for it anyway" -- network, database, power control interface, etc), and your fake or mock easily can and definitely should cause fake errors of all kinds so you can thoroughly check that error-recovery and diagnostic code.

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

Maybe it depends on what kind of apps you write -- for the last few years I've been mostly in cluster-management software, where everything that can go wrong will, lots of things that can't possibly go wrong will anyway, and uptime and fast recovery are crucial. In that field nobody would ever dare argue against a belt-and-suspenders approach (if they did the reliability engineers would be after them with cudgels;-).

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

But I've recently switched to Business Intelligence and I've noticed the approach translates well, too: if the numbers my code is producing (maybe to show as a nice graph to business decision makers, etc) are worth producing at all, they'd better be accurate, which means (among other things) that the code producing them needs to be tested just as thoroughly and carefully as that which monitors a network or a power supply system!-)

这篇关于什么不应该进行单元测试?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！