是否存在过度单元测试这样的事情? [英] Is there such a thing as excessive unit testing?

问题描述

我对单元测试的概念并不陌生，但同时我也没有掌握它们.

I'm not brand new to the concept of unit testing but at the same time I've not yet mastered them either.

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

The one question that has been going through my head recently as I've been writing unit tests while writing my code using the TDD methodology is: to what level should I be testing?

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

Sometimes I wonder if I'm being excessive in the use of unit testing.

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

At what point should a developer stop writing unit tests and get actual work done?

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

I might need to clarify that question before people assume I'm against using TDD...

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

What I'm struggling with is the granularity of my test....

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

我希望能够使用我的单元测试来验证我的应用程序的行为......但我不太确定应该在哪里停止.是否可以编写过于琐碎的测试?

I want to be able to use my unit tests to verify the behavior of my app...but I'm not quite sure where to stop. Is it possible to write tests that are too trivial?

推荐答案

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

[Update:] Found the concise answer to this question in TDD ByExample - Pg194.

简单的答案，由 Phlip 提供是，写测试直到恐惧消失变成了无聊."

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

[/更新]

我认为当前普遍存在的问题是缺乏单元测试……而不是过多的测试.我想我明白你的意思了.. 我不会把它称为过度的单元测试，而是.. 不知道你把精力集中在哪里.

I think the problem prevalent in the current times is the lack of unit testing... not excessive testing. I think I see what you're getting at.. I wouldn't term it as excessive unit-testing but rather.. not being smart about where you focus your efforts.

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

So to answer your question.. some guidelines.

• 如果您遵循 TDD，您将永远不会拥有单元测试未涵盖的代码..因为您只编写(最少)代码以通过失败的单元测试，仅此而已.推论:每个问题都应该无法通过单元测试，该测试确定缺陷的位置.同一个缺陷不应导致数十个UT同时损坏
• 不要测试不是你写的代码.一个推论是:你不测试框架代码(比如从 app.config 文件中读取值)你只是假设它可以工作.你有多少次破坏框架代码?接近零.
• 如有疑问，考虑失败的可能性，并权衡编写自动化测试用例的成本.包括为访问者/重复数据集测试编写测试用例.
• 解决痛苦.如果您发现您定期在某个区域遇到问题，请将其置于测试工具下......而不是花时间为您知道非常可靠的区域编写冗余测试.例如第三方/团队库不断在界面上中断.. 不像它应该的那样工作.模拟不会抓住它.使用真正的合作者并运行一些健全性测试来验证链接，如果您知道它是一个问题儿童，则使用回归类型套件.

• If you follow TDD, you'll never have code that is not covered by a unit test.. since you only write (minimal) code to pass a failing unit test and no more. Corollary: Every issue should fail a unit test which pinpoints the location of the defect. The same defect shouldn't cause tens of UTs to break simultaneously
• Don't test code that you didn't write. A corollary is: you don't test framework code (like reading values from an app.config file) You just assume it works. And how many times have you had framework code breaking? Next to zero.
• If in doubt, consider the probability of failure and weigh that against the cost of writing an automated test case. Writing test cases for accessors/repetitive data-set testing included.
• Address the pain. if you find that you're having issues in a certain area periodically, get it under a test harness.. instead of spending time writing redundant tests for areas that you know are pretty solid. e.g. A third party/team library keeps breaking at the interface.. doesn't work like it is supposed to. Mocks won't catch it. Have a regression type suite using the real collaborator and running some sanity tests to verify the link if you know its been a problem child.

这篇关于是否存在过度单元测试这样的事情?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！