是否存在过度的单元测试？
是否存在过度的单元测试？
提问于 2008-12-07 08:17:57
我对单元测试的概念并不陌生，但同时我也还没有掌握它们。
最近，当我在使用TDD方法编写代码时编写单元测试时，我一直在思考的一个问题是:我应该测试到什么级别？
有时，我想知道我是否过度使用单元测试。
开发人员应该在什么时候停止编写单元测试并完成实际工作？
在人们认为我反对使用TDD之前我可能需要澄清这个问题..。
我在纠结的是我考试的粒度.
- 当我的应用程序有一个配置文件时，我是否测试可以从该文件中检索值？我倾向于yes....but..。
- 然后，我是否为每个可能出现的配置值编写单元测试？检查它们是否可以被解析成正确的exist...and类型.
- 当我的应用程序将错误写入日志时，是否需要测试它是否能够写入日志？那么，我是否需要编写测试来验证条目是否真的被写入日志呢？
我希望能够使用我的单元测试来验证我的app...but的行为，我不太确定该在哪里停止。是否有可能编写过于琐碎的测试？
回答 18
Stack Overflow用户
回答已采纳
发布于 2008-12-07 09:02:41
更新：在TDD ByExample - Pg194中找到了这个问题的简明答案。
Phlip提供的简单答案是：“写测试，直到恐惧转化为无聊。”
/更新
我认为当前普遍存在的问题是缺乏单元测试.不要做过多的测试。我想我明白你的意思了..。我不认为它是过度的单元测试，而是..。在你集中精力的地方不聪明。
所以回答你的问题..。一些准则。
- 如果遵循TDD，那么就永远不会有单元测试不涵盖的代码。因为您只编写(最少)代码来通过失败的单元测试，而不是更多。推论:每一个问题都应该通过一个单元测试来确定缺陷的位置。同样的缺陷不应导致数十个UTs同时断裂
- 不测试您没有编写的代码。的推论是:您不测试框架代码(就像从app.config文件中读取值一样)，您只是假设它可以工作。你有多少次破坏了框架代码？接近零。
- 如果有疑问，会考虑失败的概率，并将其与编写自动化测试用例的成本进行权衡。编写用于访问器/重复数据集测试的测试用例。
- 的地址是疼痛。如果你发现你定期在某一领域有问题，那就把它放在一个测试工具下。而不是花时间为您所知道的非常可靠的领域编写多余的测试。例如，第三方/团队库在接口上不断中断。不像它应该的那样工作。模特儿抓不到它。拥有一个回归类型套件，使用真正的协作者，并运行一些理智测试，以验证链接，如果你知道它是一个问题子。
Stack Overflow用户
发布于 2008-12-07 08:41:18
是的，确实有可能编写过多的单元测试。例如,
- 测试getter和setter。
- 测试基本语言功能是否有效。
Stack Overflow用户
发布于 2008-12-07 13:32:20
在实践中，问题不在于人们编写太多的测试，而是他们不均衡地分配他们的测试。有时候，你会看到刚开始单元测试的人会为容易测试的东西编写数百个测试，但是在他们把测试放在最需要的地方之前，他们就会耗尽精力。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/347379
复制相关文章
相似问题
腾讯云开发者
