是否有过度的单元测试？

我对单元测试的概念并不陌生,但与此同时我还没有掌握它们.

我最近在使用TDD方法编写代码时编写单元测试时遇到的一个问题是:我应该测试什么级别？

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

在什么时候开发人员应该停止编写单元测试并完成实际工作？

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

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

当我的应用程序有配置文件时,我是否测试可以从文件中检索值？我倾向于......但....

然后,我是否为每个可能存在的配置值编写单元测试？即检查它们是否存在...并且可以解析为正确的类型...

当我的应用程序将错误写入日志时,我是否需要测试它是否能够写入日志？那么我是否需要编写测试来验证条目是否实际存在于日志中？

我希望能够使用我的单元测试来验证我的应用程序的行为...但我不太确定在哪里停止.是否有可能编写过于微不足道的测试？

[更新:]在TDD ByExample - Pg194中找到了这个问题的简明答案.

Phlip提供的简单答案是"编写测试直到恐惧变成无聊".

[/ 更新 ]

我认为当前流行的问题是缺乏单元测试......而不是过度测试.我想我知道你得到了什么......我不会把它称为过度的单元测试,而是......不要把你的工作重点放在哪里.

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

如果您遵循TDD,您将永远不会拥有单元测试未涵盖的代码..因为您只编写(最小)代码以通过失败的单元测试,而不是更多.推论:每个问题都应该通过单元测试失败,该测试可以确定缺陷的位置.同样的缺陷不应该导致数十个UT同时破坏

不要测试你没写的代码.一个必然结果是:你不测试框架代码(比如从app.config文件中读取值)你只是假设它有效.你有多少次破解框架代码？零点旁边.

如果有疑问,请考虑失败的可能性,并将其与编写自动化测试用例的成本进行权衡.编写用于访问器/重复数据集测试的测试用例.

解决痛苦.如果你发现你在某个区域定期遇到问题,那就把它放在测试工具下......而不是花时间为你知道非常可靠的区域编写冗余测试.例如,第三方/团队库不断破坏界面..不能像它应该的那样工作.模拟不会抓住它.如果您知道它是一个有问题的孩子,请使用真正的协作者并运行一些健全性测试来验证链接的回归类型套件.

是的,确实有可能编写过多的单元测试.例如,

测试getter和setter.

测试基本语言功能是否有效.

在实践中,问题不是人们写了太多的测试,而是他们不均衡地分配他们的测试.有时您会看到不熟悉单元测试的人会为易于测试的事情编写数百个测试,但是在他们最需要测试的地方之前他们就会失去动力.