单元测试 – 是否有过多的单元测试?

前端之家收集整理的这篇文章主要介绍了单元测试 – 是否有过多的单元测试?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我不是全新的单元测试的概念,但同时我还没有掌握它们。

最近我一直在编写单元测试的一个问题是使用TDD方法写我的代码是:我应该在什么级别进行测试?

有时我想知道我是否过度使用单元测试。

开发商在什么时候停止编写单元测试并完成实际工作?

在人们认为我反对使用TDD之前,我可能需要澄清这个问题

我正在努力的是我的测试的粒度….

>当我的应用程序有一个配置文件我做
测试可以检索值
文件?我倾向于是….但….
>然后我写一个
对每个可能的配置进行单元测试
将出现的价值?即检查它们是否存在…并且可以解析为正确的类型…
>当我的
应用程序会将错误写入日志,我需要
测试它是否能够写入
日志?然后我需要写
测试以验证条目是
实际上做了日志?

我想能够使用我的单元测试来验证我的应用程序的行为…但我不太确定在哪里停止。是否有可能编写太简单的测试?

[更新:]在TDD ByExample – Pg194中找到了这个问题的简明扼要的答案。

The simple answer,supplied by Phlip
is,“Write tests until fear is
transformed into boredom.”

[/更新]

我认为在当前时代普遍存在的问题是缺乏单元测试…没有过多的测试。我想我会看到你在做什么..我不会把它作为过度的单元测试,而是…不太了解你在哪里集中精力。

所以回答你的问题..一些指导方针。

>如果你遵循TDD,你将不会有单元测试没有覆盖的代码。因为你只写(最小)代码来传递失败的单元测试,而不是更多。推论:每个问题都应该失败,单位测试会明确指出缺陷的位置。同样的缺陷不应该导致数十个UT同时断开>不要测试你没有写的代码。一个推论是:你不要测试框架代码(比如从app.config文件中读取值)你只是认为它是有效的。你有多少次框架代码破裂?接近零。>如果有疑问,请考虑失败的可能性,并对自动测试案例的编写成本进行权衡。为访问者编写测试用例/重复数据集测试。>解决痛苦。如果你发现你在某个地区有周期性的问题,可以把它放在一个测试工具下,而不是花时间为你所知道的领域写出冗余测试。例如第三方/团队图书馆不断在界面上打破。这样做不行。模特不会抓住它。有一个回归类型套件使用真正的协作者,并运行一些健全测试来验证链接,如果你知道它是一个问题的孩子。

原文链接:https://www.f2er.com/javaschema/282125.html

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