blocks|key|400034|text|是的，单元测试可以过度/极端地进行。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|400035|请记住，只有必需的才能测试特性；其他的一切都是这样的。|offset|length|style|BOLD|400036|因此，不需要测试是否可以从配置文件中读取值，因为其中一个(或多个)特性将需要从配置文件中读取值--如果不需要，则不需要配置文件！|400037|编辑:我想说的话似乎有些混乱。我并不是说单元测试和特性测试是一回事--它们不是。维基百科：“一个单元是应用程序中最小的可测试部分”，从逻辑上讲，这样的‘单元’比大多数‘特性’都要小。|400038|我想说的是，单元测试是极端的，而且很少是必要的--除了超级关键软件(例如，实时控制系统，那里的生命可能受到威胁)，或者没有预算和时间限制的项目。|400039|对于大多数软件来说，从实际的角度来看，测试特性是所需的。比特性更小的测试单元不会有什么影响，而且可能会有所帮助，但是在生产率和质量改进方面的权衡是值得商榷的。|400040|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Unit_testing^0|0|6|3|D|2|0|0|14|4|0|0|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Y|8|@$D|Z|E|10|F|G]|$D|11|E|12|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|13|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|14|8|@]|9|@$D|15|E|16|1|17]]|A|$]]|$1|L|3|M|5|6|7|18|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|19|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|Q|$R|$5|S|T|U|A|$V|W]]]]

yes, unit testing can be taken to excess/extremes

keep in mind that it is only necessary to test features; everything else follows from that

so no, you don't have to test that you can read values from a config file, because one (or more) of the features will need to read values from a config file - and if they don't, then you don't need a config file!

EDIT: There seems to be some confusion as to what I am trying to say. I am not saying that unit testing and feature testing are the same thing - they are not. Per <a href="http://en.wikipedia.org/wiki/Unit_testing" rel="nofollow noreferrer">wikipedia</a>: "a unit is the smallest testable part of an application" and logically such 'units' are smaller than most 'features'.

What I am saying is that unit testing is the extreme, and is rarely necessary - with the possible exception of super-critical software (real-time control systems where lives may be endangered, for example) or projects with no limits on budget and timeline.

For most software, from a practical point of view, testing features is all that is required. Testing units smaller than features won't hurt, and it might help, but the trade-off in productivity vs improvements in quality are debatable.

blocks|key|1935025|text|单元测试需要测试每一项功能、边缘案例，有时还需要测试角落案例。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1935026|如果您发现在测试边缘和角落案例之后，您正在做“中间”案例，那么这可能是过度的。|1935027|此外，取决于您的环境，单元测试可能需要相当长的时间编写，或者非常脆弱。|1935028|测试确实需要持续的维护，所以您编写的每个测试将来都可能中断，需要修复(即使没有检测到实际的错误)--尝试用最少的测试数进行足够的测试似乎是一个好的目标(但不要把几个测试挤成一个不必要的--一次只测试一件事情)。|1935029|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Unit tests need to test each piece of functionality, edge cases and sometimes corner cases.

If you find that after testing edge and corner cases, you're doing "middle" cases, then that's probably excessive.

Moreover, depending on your environment, unit tests might be either quite time consuming to write, or quite brittle.

Tests do require ongoing maintenance, so every test you write will potentially break in the future and need to be fixed (even though it's not detected an actual bug) - trying to do sufficient testing with the minimum number of tests seems like a good goal (but don't just cobble several tests into one needlessly - test one thing at a time)

blocks|key|1935043|text|是的，确实有可能编写过多的单元测试。例如,|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1935044|测试getter和setter。|unordered-list-item|1935045|测试基本语言功能是否有效。|1935046|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|K|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|L|8|@]|9|@]|A|$]]]|H|$]]

Yes, indeed it is possible to write excessive amounts of unit tests. For example, 

<ul>
<li>testing getters and setters. </li>
<li>testing that basic language functionality is works.</li>
</ul>

blocks|key|400101|text|在单元测试中，您将编写一个测试，表明可以从配置文件中读取项。您将测试任何可能的怪癖，以便您有一组有代表性的测试，例如，您能读取空字符串、长字符串或带有转义字符的字符串吗?系统能区分空字符串或缺失字符串吗？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|400102|完成该测试后，不必每次其他类使用您已经测试过的工具时重新检查该功能。否则，对于您所测试的每个函数，您将不得不重新测试它所依赖的每个操作系统特性。对给定特性的测试只需要测试该特性的代码负责实现正确的功能。|400103|有时，如果这很难判断的话，它表示需要重构才能使问题更容易回答。如果您必须多次为不同的特性编写相同的测试，这可能表明这些特性内部共享一些东西，这些特性可以移到单个函数或类中，测试一次，然后重用。|400104|从更广泛的角度来看，这是一个经济学问题。假设您已经停止了不必要的重复测试，那么您能够负担多少您的测试才能完成？由于可能发生的各种情况的组合，实际上不可能为任何非平凡的程序编写真正完整的测试，因此您必须进行调用。许多成功的产品已经占领了世界，尽管它们最初发布时没有单元测试，包括一些有史以来最著名的桌面应用程序。他们是不可靠的，但足够好，如果他们投资更多的可靠性，那么他们的竞争对手将击败他们，在市场份额第一。(看看Netscape，它以一款出了名的不可靠产品获得了第一名，当他们花时间去做正确的事情时，它就完全消失了)。这不是我们工程师想要听到的，希望现在的客户更有洞察力，但我不太怀疑。|400105|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

In unit testing, you would write a test that shows that it is possible to read items from the config files. You'd test any possible quirks so that you have a representative set of tests, e.g. can you read an empty string, or a long string, or a string with escaped characters, can the system distinguish between an empty or missing string.

With that test done, it is not necessary to re-check that capability for every time another class uses the facility you've already tested. Otherwise, for every function you test, you'd have to re-test every operating system feature it relied on. The tests for a given feature only need to test what that feature's code is responsible for getting right.

Sometimes if this is hard to judge, it indicates something that needs refactoring to make the question easier to answer. If you have to write the same test lots of times for different features, this may indicate that those features share something inside them that could be moved out into a single function or class, tested once and then reused.

In broader terms this is an economics question. Assuming you've stopped needless duplicated tests, how much can you afford your tests to be complete? It is effectively impossible to write genuinely complete tests for any non-trivial program due to the combinations of circumstances that can occur, so you have to make the call. Many successful products have taken over the world despite having no unit tests when they originally launched, including some of the most famous desktop applications of all time. They were unreliable, but good enough, and if they'd invested more in reliability then their competitors would have beaten them to first place in market share. (Look at Netscape, who got first place with a product that was notoriously unreliable, and then died out completely when they took time out to do everything the right way). This is not what we as engineers want to hear, and hopefully these days customers are more discerning, but I suspect not by much.

blocks|key|1935102|text|过度的单元测试是绝对可能的，而测试特性是一个很好的起点。但是，也不要忽视测试错误处理。当给定不符合前提条件的输入时，您的单位应该做出明智的反应。如果您自己的代码对错误的输入负责，断言失败是一个明智的响应。如果用户可能导致错误的输入，则需要对异常或错误消息进行单元测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1935103|每个报告的错误都应该导致至少一个单元测试。|1935104|关于您的一些细节:我肯定会测试我的配置文件解析器，以确保它能够解析每种预期类型的每个值。(我倾向于依赖Lua进行配置文件和解析，但这仍然需要进行一些测试。)但是我不会为配置文件中的每个条目编写单元测试；相反，我会编写一个表驱动的测试框架来描述每个可能的条目，并由此生成测试。我可能会从同样的描述中生成文档。我甚至可以生成解析器。|offset|length|1935105|当应用程序将条目写入日志时，您将转向集成测试。更好的方法是有一个单独的日志组件，比如syslog。然后你可以对记录器进行单元测试，把它放到架子上，然后再使用它。或者更好的是重用syslog。然后，一个简短的集成测试可以告诉您，您的应用程序是否与syslog正确地互操作。|1935106|一般来说，如果您发现自己编写了大量的单元测试，那么您的单元可能太大，并且不够正交。|1935107|我希望这能帮上忙。|1935108|entityMap|0|LINK|mutability|MUTABLE|url|http://www.lua.org/^0|0|0|1F|3|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|X|8|@]|9|@$F|Y|G|Z|1|10]]|A|$]]|$1|H|3|I|5|6|7|11|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|12|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|13|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|O|$P|$5|Q|R|S|A|$T|U]]]]

It's definitely possible to overdo unit tests, and testing features is a good place to start. But don't overlook testing error handling as well. Your units should respond sensibly when given inputs that don't meet their precondition. If your own code is responsible for the bad input, an assertion failure is a sensible response. If a user can cause the bad input, then you'll need to be unit testing exceptions or error messages.

Every reported bug should result in at least one unit test.

Regarding some of your specifics: I would definitely test my config-file parser to see that it can parse every value of every expected type. (I tend to rely on <a href="http://www.lua.org/" rel="nofollow noreferrer">Lua</a> for config files and parsing, but that still leaves me with some testing to do.) But I wouldn't write a unit test for every entry in the config file; instead I'd write a table-driven test framework that would describe each possible entry and would generate the tests from that. I would probably generate documentation from the same description. I might even generate the parser.

When your app writes entries to a log you are veering into integration tests. A better approach would be to have a separate logging component like syslog. Then you can unit test the logger, put it on the shelf, and reuse it. Or even better, reuse syslog. A short integration test can then tell you whether your app is interoperating correctly with syslog.

In general if you find yourself writing a lot of unit tests, perhaps your units are too large and not orthogonal enough.

I hope some of this helps.

blocks|key|733623|text|更新：在TDD+ByExample+-+Pg194中找到了这个问题的简明答案。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|733624|Phlip提供的简单答案是：“写测试，直到恐惧转化为无聊。”|blockquote|733625|/更新|733626|我认为当前普遍存在的问题是缺乏单元测试.不要做过多的测试。我想我明白你的意思了..。我不认为它是过度的单元测试，而是..。在你集中精力的地方不聪明。|733627|所以回答你的问题..。一些准则。|733628|如果遵循TDD，那么就永远不会有单元测试不涵盖的代码。因为您只编写(最少)代码来通过失败的单元测试，而不是更多。推论:每一个问题都应该通过一个单元测试来确定缺陷的位置。同样的缺陷不应导致数十个UTs同时断裂|unordered-list-item|733629|不测试您没有编写的代码。的推论是:您不测试框架代码(就像从app.config文件中读取值一样)，您只是假设它可以工作。你有多少次破坏了框架代码？接近零。|733630|如果有疑问，会考虑失败的概率，并将其与编写自动化测试用例的成本进行权衡。编写用于访问器/重复数据集测试的测试用例。|733631|的地址是疼痛。如果你发现你定期在某一领域有问题，那就把它放在一个测试工具下。而不是花时间为您所知道的非常可靠的领域编写多余的测试。例如，第三方/团队库在接口上不断中断。不像它应该的那样工作。模特儿抓不到它。拥有一个回归类型套件，使用真正的协作者，并运行一些理智测试，以验证链接，如果你知道它是一个问题子。|733632|entityMap^0|0|3|0|0|1|2|0|0|0|2|5|0|0|C|0|6|M|0|0|6|0^^$0|@$1|2|3|4|5|6|7|Z|8|@$9|10|A|11|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|12|8|@]|D|@]|E|$]]|$1|I|3|J|5|6|7|13|8|@$9|14|A|15|B|C]]|D|@]|E|$]]|$1|K|3|L|5|6|7|16|8|@]|D|@]|E|$]]|$1|M|3|N|5|6|7|17|8|@]|D|@]|E|$]]|$1|O|3|P|5|Q|7|18|8|@$9|19|A|1A|B|C]]|D|@]|E|$]]|$1|R|3|S|5|Q|7|1B|8|@$9|1C|A|1D|B|C]]|D|@]|E|$]]|$1|T|3|U|5|Q|7|1E|8|@$9|1F|A|1G|B|C]]|D|@]|E|$]]|$1|V|3|W|5|Q|7|1H|8|@$9|1I|A|1J|B|C]]|D|@]|E|$]]|$1|X|3|-4|5|6|7|1K|8|@]|D|@]|E|$]]]|Y|$]]

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

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

[/Update]

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.

<ul>
<li>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</li>
<li>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.</li>
<li>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.</li>
<li>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. </li>
</ul>

blocks|key|1935167|text|这是很有可能的，但问题不是有太多的测试-它是测试的东西，你不关心，或者投资太多的测试材料，更少和更简单的测试是足够的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1935168|我的指导原则是我在修改代码时的自信程度:如果它永远不会失败，我就不需要测试了。如果是直截了当的话，一个简单的理智就可以了。如果这是个棘手的问题，我会提高测试，直到我有信心做出改变为止。|1935169|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

It's very possible, but the problem isn't having too many tests - it's testing stuff you don't care about, or investing too much in testing stuff fewer and simpler tests would have been enough for.

My guiding principle is the level of confidence I have when changing a piece of code: if it will never fail, I won't need the test. If it's straightforward, a simple sanity will do. If it's tricky, I crank up the tests until I feel confident to make changes.

blocks|key|1935180|text|当您使用代码生成来生成非常明显的单元测试时，经常会出现过多的单元测试。但是，由于生成的单元测试不会真正伤害任何人(并且不会对成本效益比产生负面影响)，所以我认为应该让它们留在--它们可能会在您最不期望的时候有用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1935181|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Excessive unit testing often arises when you use code generation to generate really obvious unit tests. However, since generated unit tests do not really hurt anyone (and do not affect the cost-benefit ratio negatively), I say leave them in - they might come in useful when you least expect it.

blocks|key|400258|text|当然，一个人也可以用过度工程师的方式来过度测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|400259|当您遵循测试驱动开发时，您应该对您的代码获得信心，并在您足够自信时停止。当有疑问时，增加一个新的测试。|400260|关于琐碎的测试，一个eXtreme编程说这是“测试所有可能破坏的东西”。|offset|length|style|BOLD|400261|entityMap^0|0|0|N|8|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@$F|O|G|P|H|I]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

Of course one can overtest the same way one can over-engineer. 

As you follow Test-Driven Development, you should gain confidence about your code and stop when you're confident enough. When in doubt, add a new test. 

About trivial tests, an eXtreme Programming saying about this is "test everything that could break".

blocks|key|1935247|text|我相信一个好的测试会测试一些规范。任何测试不属于规范的部分的测试都是毫无价值的，因此应该省略，例如，测试方法只是实现一个单元的指定功能的手段。同样值得怀疑的是，是否值得测试getter和setter等真正琐碎的功能，尽管您永远不知道它们会有多长时间是琐碎的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1935248|根据规范进行测试的问题是，许多人使用测试作为规范，这是错误的，原因有很多--部分原因是因为它阻止了您真正知道应该测试什么，什么不应该测试(另一个重要的原因是，测试总是只测试一些示例，而规范总是应该为所有可能的输入和状态指定行为)。|1935249|如果您有适当的规格说明您的单位(和您应该)，那么它应该是显而易见的需要测试和任何超越这是多余的，因此浪费。|1935250|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I believe that a good test tests a bit of specification. Any test that tests something that is not part of a specification is worthless and should thus be omitted, e.g. testing methods that are just means of implementing the specified functionality of a unit. It is also questionable if it is worthwhile testing truly trivial functionality such as getters and setters, although you never know how long they will be trivial.

The problem with testing according to specification is that many people use tests as specifications, which is wrong for many reasons -- partly since it stops you from being able to actually know what you should test and what not (another important reason is that tests are always testing only some examples, while specifications should always specify behaviour for all possible inputs and states).

If you have proper specifications for your units (and you should), then it should be obvious what needs testing and anything beyond that is superfluous and thus waste.

blocks|key|1935262|text|根据所给出的一些答案，有一点要注意的是，如果您发现需要编写大量单元测试来一遍又一遍地做相同的事情，请考虑重构所讨论的代码的根本原因。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1935263|是否需要为访问配置设置的任何地方编写测试？不是的。如果重构并为该功能创建一个入口点，则可以对其进行一次测试。我相信测试尽可能多的功能是可行的。但是，真正重要的是要认识到，如果省略重构步骤，代码覆盖率就会直线下降，因为您在整个代码库中继续使用“一次性”实现。|1935264|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

One thing to note, based upon some of the answers given, is that if you find that you are needing to write numerous unit tests to do the same thing over and over, consider refactoring the root cause of the code in question.

Do you need to write a test for everywhere you access a configuration setting? No. You can test it once if you refactor and create a single point of entry for the functionality. I believe in testing as large an amount of functionality as is feasibly possible. But it is really important to realize that if you omit the refactoring step, your code coverage will plummet as you continue to have "one-off" implementations throughout the codebase.

blocks|key|400340|text|在实践中，问题不在于人们编写太多的测试，而是他们不均衡地分配他们的测试。有时候，你会看到刚开始单元测试的人会为容易测试的东西编写数百个测试，但是在他们把测试放在最需要的地方之前，他们就会耗尽精力。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|400341|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

In practice the problem isn't that people write too many tests, it's that they distribute their tests unevenly. Sometimes you'll see people who are new to unit testing write hundreds of tests for the things that are easy to test, but then they run out of steam before they put any tests where they're most needed.

blocks|key|1935312|text|开发人员应该在什么时候停止编写单元测试并完成实际工作？|type|blockquote|depth|inlineStyleRanges|entityRanges|data|1935313|单元测试的要点--除了提供设计指导--是给你反馈你是否真的完成了工作。记住那句古老的格言:如果它不用工作，我现在就完蛋了。|unstyled|1935314|在精益词汇中，测试是“必要的浪费”--它们没有提供任何直接价值。因此，艺术只是写那些提供间接价值的测试--通过帮助我们获得对我们生产的作品的信心。|1935315|因此，关于要编写哪些测试的最终指南应该是您对产品代码的信心水平。这就是极端编程的口号“测试所有可能破坏的东西”的来源--如果有什么东西可能会崩溃，我们需要一个测试作为我们的安全网，这样我们才能通过自信的重构，在未来迅速行动。如果某些东西“不可能损坏”(就像人们常说的简单访问器那样)，为它编写测试将是完全的浪费。|1935316|当然，你的评估有时会失败。你需要经验才能找到正确的平衡。最重要的是，每当您在代码中得到错误报告时，您就应该考虑什么样的测试可以防止该bug出现，并在将来防止类似的错误。然后，将这种测试添加到代码的集合中，测试“可能会崩溃”。|1935317|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|O|8|@]|9|@]|A|$]]|$1|G|3|H|5|D|7|P|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|Q|8|@]|9|@]|A|$]]|$1|K|3|-4|5|D|7|R|8|@]|9|@]|A|$]]]|L|$]]

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

The point of unit tests - besides providing guidance in design - is to give you feedback on whether you actually did get work done. Remember that old adage: if it doesn't have to work, I'm finished now.

In Lean vocabulary, tests are "necessary waste" - they don't provide any direct value. So the art is in writing only those tests that provide indirect value - by helping us get confidence in that what we produced actually works.

So, the ultimate guide on what tests to write should be your confidence level about the production code. That's where the Extreme Programming mantra "test everything that could possibly break" is coming from - if something could possibly break, we need a test as our safety net, to be able to move quickly in the future, by refactoring with confidence. If something "couldn't possibly break" (as is often said about simple accessors), writing tests for it would be total waste.

Of course you fail in your assessment from time to time. You will need experience to find the right balance. Most importantly, whenever you get a bug report against your code, you should think about what kind of test would have prevented this bug from going out into the wild, and will prevent similar bugs in the future. Then add this kind of test to your collection of tests for code "that could possibly break".

blocks|key|734067|text|如果两个测试用例将运行完全相同的代码，那么就没有必要分别测试它们。例如，对于读取配置文件的示例，只需测试它是否能够正确读取每种类型的值(并且当要求读取不存在或无效的值时，它以正确的方式失败)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|734068|如果您测试它是否正确地读取配置文件中的每个值，那么您将测试配置文件，而不是代码。|734069|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

If two test cases will run exactly the same code, then there's no need to test them separately. e.g., For your example of reading the config file, you only need to test that it is able to correctly read each type of value (and that it fails in the correct manner when asked to read a nonexistent or invalid value).

If you test that it correctly reads in every single value in the config file, then you are testing the config file, not the code.

blocks|key|400413|text|如果您发现自己在测试例程中花费了所有的调试时间，那么您可能已经做得太过火了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|400414|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If you find yourself spending all your debugging time in the testing routines, you may have gone overboard.

blocks|key|1935396|text|TDD方法是关于设计的--拥有一套供以后使用的测试是一个相当受欢迎的副作用。测试驱动的开发揭示了完全不同的代码，而不是让测试“只是”作为一种事后考虑。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1935397|因此，当您在TDD上下文中询问:过度设计“过度设计”的解决方案是很容易的。当你的设计有足够的固定，使它不会滑倒时，停止。不需要用螺栓把它固定下来，用水泥绑起来，用水泥盖住。您需要设计具有足够的灵活性，以便在下一次重构过程中进行更改。|1935398|我关于过度工程测试的个人经历是一个过度模拟的测试，其中一些类的实现或多或少地反映在对各自模拟对象的“expect”调用中。说到拒绝接受改变的要求..。|1935399|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

The TDD methodology is about designing - having a suite of tests for later is a rather welcome side effect. Test driven development reveals completely different code than having tests "just" as an afterthought. 

So when you ask in the TDD context: It's easy to excessively design a solution that is "overengineered". Stop when you have the design fixed enough that it will not slip. No need to bolt it down, strap and cover with cement. You need the design to be flexible enough to be changed during the next refactoring.

My personal story for overengineered testing is an over-mocked test where the implementation of some classes was more or less mirrored in 'expect'-calls to respective mock objects. Talk about resistance to adopt to changed requirements...

blocks|key|734100|text|我认为这条规则也应该应用于TDD，以防止过度的单元测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|734101|entityMap|0|LINK|mutability|MUTABLE|url|http://www.lindsaar.net/2008/6/28/tip-27-spec-a-behaviour-not-an-implementation^0|3|4|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

I think <a href="http://www.lindsaar.net/2008/6/28/tip-27-spec-a-behaviour-not-an-implementation" rel="nofollow noreferrer">this rule</a> should also apply to TDD to prevent excessive unit test.

blocks|key|400519|text|为了确定我在程序上投入了多少测试工作，我根据要测试的内容定义了这个测试活动的标准:所有代码分支、所有函数、所有输入或输出域、所有特性……|type|unstyled|depth|inlineStyleRanges|entityRanges|data|400520|因此，当我的标准完全涵盖时，我的测试工作就完成了。|400521|我只需要意识到某些目标是不可能达到的，比如所有的程序路径或所有的输入值。|400522|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

For determining how much testing effort I put on a program, I define criteria for this testing campaign in terms of what is to be tested: all the branches of the code, all the functions, all the input or output domains, all the features...

Given this, my test work is done when my criteria are entirely covered.

I just need to be aware that certain goals are impossible to reach such as all the program paths or all the input values.

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

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?

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....

<ul>
<li>When my app has a config file do I
test that values can be retrieved
from the file? I lean towards yes....but....</li>
<li>Do I then write a
unit test for each possible config
value that will be present? ie check that they exist...and can be parsed to the correct type...</li>
<li>When my
app writes errors to a log do I need
to test that it is able to write to
the log? Do I then need to write
tests to verify that entries are
actually made to the log?</li>
</ul>

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?

Is there such a thing as excessive unit testing?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我对单元测试的概念并不陌生，但同时我也还没有掌握它们。最近，当我在使用TDD方法编写代码时编写单元测试时，我一直在思考的一个问题是:我应该测试到什么级别？有时，我想知道我是否过度使用单元测试。开发人员应该在什么时候停止编写单元测试并完成实际工作？在人们认为我反对使用TDD之前我可能需要澄清这个问题..。我在纠结的是我考...

问是否存在过度的单元测试？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问是否存在过度的单元测试？EN