如果要为单元测试规定最小百分比的代码覆盖率，甚至可能要求作为提交到存储库的要求，那将是什么？

请说明我们是如何得出答案的(因为如果我们所做的只是选择一个号码，那么我本可以独自完成所有工作；)

解决方案

85％将是签入标准的一个很好的起点。

我可能会根据要测试的子系统/组件的关键程度，选择各种更高的标准来确定运输标准。

这在很大程度上取决于应用程序。例如，某些应用程序主要由无法进行单元测试的GUI代码组成。

阿尔贝托·萨沃亚(Alberto Savoia)的散文恰好回答了这个问题(以一种非常有趣的方式！)：

http://www.artima.com/forums/flat.jsp?forum=106&thread=204677

Testivus On Test Coverage
  
  Early one morning, a programmer asked
  the great master:
  
  “I am ready to write some unit tests. What code coverage should I aim
  for?”
  
  The great master replied:
  
  “Don’t worry about coverage, just write some good tests.”
  
  The programmer smiled, bowed, and
  left.
  
  ...
  
  Later that day, a second programmer
  asked the same question.
  
  The great master pointed at a pot of
  boiling water and said:
  
  “How many grains of rice should I put in that pot?”
  
  The programmer, looking puzzled,
  replied:
  
  “How can I possibly tell you? It depends on how many people you need to
  feed, how hungry they are, what other
  food you are serving, how much rice
  you have available, and so on.”
  
  “Exactly,” said the great master.
  
  The second programmer smiled, bowed,
  and left.
  
  ...
  
  Toward the end of the day, a third
  programmer came and asked the same
  question about code coverage.
  
  “Eighty percent and no less!” Replied the master in a stern voice,
  pounding his fist on the table.
  
  The third programmer smiled, bowed,
  and left.
  
  ...
  
  After this last reply, a young
  apprentice approached the great
  master:
  
  “Great master, today I overheard you answer the same question about
  code coverage with three different
  answers. Why?”
  
  The great master stood up from his
  chair:
  
  “Come get some fresh tea with me and let’s talk about it.”
  
  After they filled their cups with
  smoking hot green tea, the great
  master began to answer:
  
  “The first programmer is new and just getting started with testing.
  Right now he has a lot of code and no
  tests. He has a long way to go;
  focusing on code coverage at this time
  would be depressing and quite useless.
  He’s better off just getting used to
  writing and running some tests. He can
  worry about coverage later.”
  
  “The second programmer, on the other hand, is quite experience both
  at programming and testing. When I
  replied by asking her how many grains
  of rice I should put in a pot, I
  helped her realize that the amount of
  testing necessary depends on a number
  of factors, and she knows those
  factors better than I do – it’s her
  code after all. There is no single,
  simple, answer, and she’s smart enough
  to handle the truth and work with
  that.”
  
  “I see,” said the young apprentice,
  “but if there is no single simple
  answer, then why did you answer the
  third programmer ‘Eighty percent and
  no less’?”
  
  The great master laughed so hard and
  loud that his belly, evidence that he
  drank more than just green tea,
  flopped up and down.
  
  “The third programmer wants only simple answers – even when there are
  no simple answers … and then does not
  follow them anyway.”
  
  The young apprentice and the grizzled
  great master finished drinking their
  tea in contemplative silence.

如果这是一个完美的世界，那么单元测试将覆盖100％的代码。但是，由于这不是一个完美的世界，所以这取决于我们是否有时间。因此，我建议不要过多地关注特定百分比，而更多地关注关键领域。如果代码写得很好(或者至少是合理的传真)，那么应该在几个关键点上将API暴露给其他代码。

将测试工作集中在这些API上。确保API 1)记录良好，2)编写了与文档匹配的测试用例。如果预期结果与文档不符，则代码，文档或者测试用例中都有错误。所有这些都值得审查。

祝你好运！

我认为不可能有这样的黑白规则。
应该审查代码，尤其要注意关键细节。
但是，如果尚未对其进行测试，则可能有错误！

简短答案：60-80％

长答案：
我认为这完全取决于项目的性质。我通常通过对每个实际的部分进行单元测试来开始一个项目。在项目的第一个"发行版"中，根据我们正在执行的编程类型，我们应该具有相当不错的基本百分比。那时，我们可以开始"强制"最小代码覆盖率。

根据代码的关键程度，75％-85％之间的任何值都是一个很好的经验法则。
绝对应该比内部公用事业等对运输代码进行更彻底的测试。

直到几天后，我们的目标是> 80％，但是在使用了大量生成的代码之后，我们不在乎％age，而是让审阅者致电所需的覆盖率。

这必须取决于我们处于应用程序开发生命周期的哪个阶段。

如果我们已经开发了一段时间，并且已经有很多实现的代码，并且刚刚意识到需要考虑代码覆盖率，则必须检查当前的覆盖率(如果存在)，然后使用该基准为每个冲刺设定里程碑(或者在一个冲刺期间平均上升)，这意味着在继续交付最终用户价值的同时承担代码债务(至少以我的经验，如果我们增加了测试，则最终用户不在乎一点如果他们看不到新功能，则覆盖范围)。

根据域，拍摄95％的镜头并非没有道理，但我不得不说，平均而言，我们要查看85％到90％的平均案件。

如果目标是100％的覆盖率(而不是对所有功能进行100％的测试)，则代码覆盖率是一个令人误解的指标。

• 我们可以通过一次击中所有行来获得100％的收益。但是，我们仍然可能会错过测试击中这些行的特定序列(逻辑路径)的方法。
• 我们无法得到100％，但仍然已经测试了所有80％/频率使用的代码路径。进行测试以测试我们放入的每个" throw ExceptionTypeX"或者类似防御编程防护程序，这是"很不错"而不是"必须"

因此，请相信我们自己或者开发人员要彻底，并涵盖其代码中的所有路径。务实，不要追求神奇的100％覆盖率。如果我们对自己的代码进行TDD，则应该获得90％以上的覆盖率作为奖励。使用代码覆盖率突出显示我们错过的代码块(但是，如果我们使用TDD则不会发生..因为我们编写代码只是为了通过测试。没有其伙伴测试就不会存在任何代码。)

我认为正确覆盖代码的最好症状是，单元测试有助于解决的具体问题的数量与我们创建的单元测试代码的大小合理地相对应。

如果我们已经进行了相当长时间的单元测试，那么我认为没有理由不使其达到95％以上。但是，即使是测试的新手，我也至少要与80％的人打交道。

此数字应仅包括项目中编写的代码(不包括框架，插件等)，甚至可能排除某些类，这些类完全由对外部代码的调用编写的代码组成。这种呼叫应被模拟/打桩。

我想分享另一个有关测试范围的内容。

我们有一个庞大的项目，在Twitter上，我注意到在700个单元测试中，我们只有20％的代码覆盖率。

斯科特·汉塞尔曼(Scott Hanselman)回答说：

Is it the RIGHT 20%? Is it the 20%
  that represents the code your users
  hit the most? You might add 50 more
  tests and only add 2%.

再次，它可以回到我对代码覆盖率答案的见证。你应该在锅里放多少米？这取决于。

总体而言，从我阅读的几篇出色的工程学最佳实践论文中，单元测试中新代码的80％是产生最佳回报的点。超过该CC％，则所付出的努力量将产生较少的缺陷。这是许多大型公司使用的最佳实践。

不幸的是，这些结果大多数是公司内部产生的，因此没有任何公共文献可供我参考。

签出Crap4j。与直接代码覆盖相比，这是一种稍微复杂一些的方法。它将代码覆盖率度量与复杂性度量结合在一起，然后向我们显示当前未测试哪些复杂代码。

我对这个难题的答案是使我们可以测试的代码具有100％的行覆盖率，而无法测试的代码具有0％的行覆盖率。

我目前在Python中的做法是将.py模块划分为两个文件夹：app1 /和app2 /，并在运行单元测试时计算这两个文件夹的覆盖率，并目视检查(我有一天必须自动化)app1的覆盖率是100％， app2的覆盖率为0％。

当/如果我发现这些数字与标准不符，我会调查并更改代码的设计，以使覆盖范围符合标准。

这确实意味着我可以建议实现库代码的100％行覆盖率。

我有时也会查看app2 /，以查看是否可以在此处测试任何代码，如果可以，可以将其移至app1 /

现在，我不必太担心总覆盖率，因为总覆盖率可能会因项目规模而异，但是通常我看到的范围是70％至90％以上。

使用python，我应该能够设计一个烟雾测试，该烟雾测试可以在测量覆盖率的同时自动运行我的应用程序，并希望在将烟雾测试与单元测试数据结合起来时获得100％的综合效果。

代码覆盖范围很棒，但前提是我们从代码获取的好处超过实现它的成本/精力。

我们一直在努力达到80％的标准，但是我们刚刚做出决定放弃它，而是更加专注于我们的测试。专注于复杂的业务逻辑等，

之所以做出此决定，是因为我们花费更多的时间来追求代码覆盖率并维护现有的单元测试。我们认为我们已经到了这样的地步，我们从代码覆盖范围中获得的收益被认为少于我们为实现它所付出的努力。

从另一个角度查看覆盖范围：具有清晰控制流的编写良好的代码最容易覆盖，最容易阅读，并且通常是错误最少的代码。通过在编写代码时要牢记清晰性和可覆盖性，并通过与代码并行编写单元测试，可以得到最佳的恕我直言的结果。

我认为最重要的是了解覆盖率随时间变化的趋势并了解趋势变化的原因。我们是否认为趋势的变化是好是坏，取决于对原因的分析。

代码覆盖范围很大，但功能覆盖范围则更好。我不相信涵盖我所写的每一行。但是，我确实相信要对我要提供的所有功能进行100％的测试覆盖(即使是我自带的超酷功能，也没有在会议中讨论)。

我不在乎是否会有测试未涵盖的代码，但是我会在乎是否重构代码并最终获得不同的行为。因此，100％的功能覆盖率是我唯一的目标。

我使用cobertura，无论使用什么百分比，我都建议使cobertura-check任务中的值保持最新。至少应将totallinerate和totalbranchrate至少提高到当前覆盖率以下，但不要降低这些值。还要将Ant build failure属性绑定到该任务。如果由于缺少覆盖而导致构建失败，则说明我们知道某人已添加代码，但尚未对其进行测试。例子：

<cobertura-check linerate="0"
                 branchrate="0"
                 totallinerate="70"
                 totalbranchrate="90"
                 failureproperty="build.failed" />

当我认为我的代码没有经过足够的单元测试，并且不确定接下来要测试什么时，我会使用覆盖率帮助我决定下一步要测试什么。

如果我增加了单元测试的覆盖率，我知道这个单元测试值得。

这适用于未覆盖，覆盖50％或者覆盖97％的代码。