Questions tagged «unit-testing»

在我看来，如果最终用户在生产中发现了严重的错误，应该添加一个失败的单元测试来覆盖该错误，从而有意破坏该构建，直到修复该错误为止。我这样做的理由是构建应该一直失败，但这并不是由于自动测试覆盖率不足所致。 我的几个同事不同意说不应该检查失败的单元测试。就正常的TDD惯例而言，我同意这种观点，但是我认为应该以不同的方式处理生产错误-毕竟，为什么要允许建立已知缺陷的成功方案？ 是否有其他人具有处理这种情况的可靠策略？我知道故意破坏构建可能会对其他团队成员造成破坏，但这完全取决于您使用分支机构的方式。

410 unit-testing  tdd  builds 

在对此出色文章的评论中，Roy Osherove提到了OAPT项目，该项目旨在在单个测试中运行每个断言。 以下内容写在项目的主页上： 正确的单元测试应该仅出于一个原因而失败，这就是为什么您应该在每个单元测试中使用一个断言。 而且，罗伊（Roy）在评论中写道： 我的指导原则通常是每次测试都测试一个逻辑概念。您可以在同一对象上具有多个断言 。它们通常是要测试的相同概念。 我认为在某些情况下需要多个断言（例如Guard Assertion），但总的来说，我尝试避免这种情况。你有什么意见？请提供一个真实的示例，其中确实需要多个断言。

396 unit-testing 

我发现测试比他们正在测试的实际代码更加棘手，更难编写。对于我来说，花更多的时间编写测试而不是测试代码并不稀奇。 那是正常的还是我做错了什么？ 问题“ 单元测试或测试驱动的开发值得吗？”，“ 我们比实施系统本身花费更多的时间来实施功能测试，这是否正常？”，他们的答案更多地是关于测试是否值得（例如“我们应该完全跳过编写测试吗？”中的内容）。尽管我确信测试很重要，但是我想知道我在测试上花费的时间是否比实际代码多还是正常的，还是仅我一个人？ 从我收到的问题的观点，答案和投票的数量来看，我只能认为它是网站上其他任何问题都没有解决的合法问题。

210 unit-testing  testing 

我正在研究Java项目。我是单元测试的新手。在Java类中对私有方法进行单元测试的最佳方法是什么？

184 java  unit-testing 

我们试图在我的公司中多次引入开发人员自动化测试。我们的质量检查团队使用Selenium来自动化UI测试，但是我一直想介绍单元测试和集成测试。过去，每次我们尝试时，每个月的第一个月或第二个月每个人都会感到兴奋。然后，几个月后，人们只是停止这样做。 一些观察和问题： 自动化测试是否有效？我曾经在其他公司工作的大多数同事都尝试过并未能实施自动测试策略。我仍然没有看到一个实际使用它并且不仅仅谈论它的现实软件公司。因此，许多开发人员将自动化测试视为理论上很棒的东西，但实际上却行不通。我们的业务团队希望开发人员即使花费30％的额外时间来做到这一点（至少他们这样说）。但是开发商对此表示怀疑。 没有人真正知道如何正确地进行自动化测试。是的，我们都已经在互联网上阅读了单元测试示例，但是将它们用于大型项目则完全是另外一回事。罪魁祸首是嘲笑/存根数据库或其他不平凡的事情。与编写实际测试相比，您最终花了更多的时间进行模拟。然后，当编写测试花费的时间比编写代码花费的时间长时，就是您放弃了。 在复杂的以数据为中心的Web应用程序中，有没有很好的使用单元测试/系统集成测试的例子？有开源项目吗？我们的应用程序以数据为中心，但也具有大量的域逻辑。我在某个时候尝试了存储库方法，发现它对于单元测试相当不错，但是它是以能够轻松优化数据访问为代价的，它增加了另一层复杂性。 我们有一个由20个经验丰富的开发人员进行的大型项目。这似乎是引入单元测试/集成测试的理想环境。 为什么对我们不起作用？您是如何在公司工作的？

178 unit-testing  tdd  test-automation 

我的任务是为现有应用程序编写单元测试。完成第一个文件后，我有717行测试代码和419行原始代码。 随着我们增加代码覆盖率，这个比率会变得难以管理吗？ 我对单元测试的理解是测试类中的每个方法，以确保每个方法都能按预期工作。但是，在请求请求中，我的技术负责人指出我应该专注于更高级别的测试。他建议测试该类最常使用的4-5个用例，而不是详尽地测试每个功能。 我相信我的技术主管的评论。他比我拥有更多的经验，并且在设计软件时具有更好的直觉。但是，多人团队如何针对这种含糊的标准编写测试；也就是说，我怎么知道我的同龄人和我对“最常见的用例”有相同的想法？ 对我来说，100％的单元测试覆盖率是一个崇高的目标，但是即使我们只达到50％，我们也知道那50％的覆盖率达到了100％。否则，为每个文件的一部分编写测试将留出很大的作弊空间。

139 unit-testing  tdd 

我在一家小公司工作，担任单人开发人员。实际上，我是该公司唯一的开发人员。我有几个（相对）定期编写和维护的大型项目，但是没有一个项目可以支持它们。在开始新项目时，我经常想知道是否应该尝试TDD方法。这听起来是个好主意，但老实说，我永远无法证明所涉及的额外工作。 我努力工作以在设计中具有前瞻性。我意识到，肯定有一天另一位开发人员将不得不维护我的代码，或者至少要对其进行故障排除。我将事情保持尽可能简单，并评论和记录难以掌握的事情。而且事实是，这些项目没有那么大或太复杂，以至于一个体面的开发人员很难理解它们。 我看到的许多测试示例都涉及细节，涵盖了代码的所有方面。由于我是唯一的开发人员，而且我非常接近整个项目中的代码，因此遵循写后手动测试模式的效率要高得多。我还发现需求和功能的变更足够频繁，以至于维护测试会给项目增加相当大的阻力。原本可以用来解决业务需求的时间。 因此，我每次都得出相同的结论。投资回报率太低。 我偶尔会进行一些测试，以确保我正确编写了算法，例如根据员工的聘用日期计算他们在公司的工作年限。但是从代码覆盖率的角度来看，我已经涵盖了大约1％的代码。 在我的情况下，您是否仍会找到一种使单元测试成为常规做法的方法，还是我有理由避免这种开销？ 更新： 关于我的情况，我遗漏了一些东西：我的项目都是Web应用程序。为了覆盖我的所有代码，我必须使用自动化的UI测试，在这个领域中，与手动测试相比，我仍然没有太大的收获。

138 unit-testing  tdd 

我是一个单独的开发人员，拥有一个受时间限制的漂亮工作环境，每个项目的开发时间通常为1-4周，具体取决于需求，紧迫性或两者兼而有之。在任何给定的时间，我都会处理大约3-4个项目，其中一些时间表彼此重叠。 预期，代码质量会受到影响。我也没有正式测试；它通常会涉及到遍历整个系统，直到出现故障为止。结果，大量的错误逃逸到了生产环境中，我必须修复这些错误，然后又使我的其他项目受挫。 这是进行单元测试的地方。正确完成后，应该将错误（更不用说那些逃到生产环境的错误）保持在最低限度。另一方面，编写测试可能要花费大量时间，对于像我这样的时间受限制的项目来说，这听起来并不好。 问题是，与未经测试的代码相比，编写经过单元测试的代码要花多少时间差？随着项目范围的扩大，时间差如何扩大？

132 unit-testing  productivity  solo-development 

在我当前的项目（一个用C ++编写的游戏）中，我决定在开发过程中将100％使用“测试驱动开发”。 就代码质量而言，这很棒。我的代码从未设计得那么好或没有漏洞。当我查看一年前在项目开始时编写的代码时，我并不畏缩，而且我对如何组织事物有了更好的了解，不仅可以更容易测试，而且可以更容易实现和使用。 。 但是...我开始这个项目已经一年了。当然，我只能在业余时间处理它，但是与我以前相比，TDD仍然使我的速度大大降低。我读到，随着时间的流逝，开发速度的降低会越来越好，而且我确实确实比以前更容易进行测试，但是我已经进行了一年，而且我仍在努力。 每当我考虑需要执行的下一步时，就必须每次都停下来思考如何为它编写测试，以便允许我编写实际的代码。有时我会被困上几个小时，确切地知道我要编写什么代码，却不知道如何将其分解得足够细致，以至于无法完全被测试覆盖。其他时候，我会迅速考虑十几个测试，并花一个小时编写测试，以覆盖一小部分真实的代码，而这些代码原本要花几分钟才能编写。 或者，在完成第50次测试以涵盖游戏中的特定实体及其创建和使用的各个方面之后，我查看了我的待办事项清单，看到了下一个要编码的实体，并为写作而大吃一惊。另进行50次类似测试以使其得以实施。 到了关键点，回顾去年的进展，我正考虑放弃TDD，以“完成该死的项目”。但是，放弃它随附的代码质量并不是我所期望的。恐怕如果我停止编写测试，那么我将失去使代码如此模块化和可测试的习惯。 我是否可能在做错事而仍然如此缓慢？是否有其他选择可以在不完全丧失收益的情况下提高生产率？TAD？较少的测试范围？其他人如何在不破坏所有生产力和动力的情况下在TDD中生存？

131 unit-testing  tdd 

考虑一种随机调整数组元素的方法。您将如何编写一个简单而健壮的单元测试以确保其正常工作？ 我提出了两个想法，两个都有明显的缺陷： 随机排列数组，然后确保其顺序与以前不同。这听起来不错，但是如果随机播放以相同顺序随机播放，则失败。（不可能，但可能。） 用恒定的种子对数组进行混洗，并根据预定的输出进行检查。这依赖于随机函数始终在给定相同种子的情况下始终返回相同的值。但是，有时这是一个无效的假设。 考虑第二个函数，该函数模拟掷骰子并返回随机数。您将如何测试此功能？您将如何测试该功能... 永远不会返回给定范围之外的数字？ 返回有效分布中的数字？（一个骰子统一，大量骰子正常。） 我正在寻找答案，以提供不仅可以测试这些示例，而且可以测试常规代码的随机元素。这里的单元测试甚至是正确的解决方案吗？如果没有，那是什么样的测试？ 只是为了让大家放心，我没有编写自己的随机数生成器。

127 testing  unit-testing  random 

我经常使用非常数值/数学的程序，其中函数的确切结果很难预先预测。 在尝试将TDD与此类代码一起应用时，我经常发现编写被测代码比编写该代码的单元测试要容易得多，因为我知道找到预期结果的唯一方法是应用算法本身（无论头，纸上或通过计算机）。感觉不对，因为我正在有效地使用被测代码来验证单元测试，而不是相反。 当难以预测被测代码的结果时，是否存在用于编写单元测试和应用TDD的已知技术？ 难以预测结果的（真实）代码示例： 返回weightedTasksOnTime给定每天workPerDay在（0，24]范围内完成的工作量，当前时间initialTime> 0和任务列表的函数taskArray；每个任务的完成属性时间time> 0，到期日due和重要性值importance；返回[0，1]范围内的标准化值，表示due如果每个任务按taskArray，给出的顺序完成，则可以在其日期之前完成的任务的重要性initialTime。 实现此功能的算法相对简单：对中的任务进行迭代taskArray。对于每个任务，添加time到initialTime。如果新时间< due，则添加importance到累加器。时间是通过反向workPerDay来调整的。返回累加器之前，请除以任务重要性之和以进行归一化。 function weightedTasksOnTime(workPerDay, initialTime, taskArray) { let simulatedTime = initialTime let accumulator = 0; for (task in taskArray) { simulatedTime += task.time * (24 / workPerDay) if (simulatedTime < task.due) { accumulator += task.importance } } return accumulator / totalImportance(taskArray) } 我相信可以通过删除workPerDay和规范化要求来简化上述问题，同时保持其核心，从而得出： …

124 unit-testing  tdd 

我刚大学毕业，下周要去上大学。我们已经看到了单元测试，但是我们并没有太多地使用它们。每个人都在谈论他们，所以我想也许我应该做些。 问题是，我不知道要测试什么。我应该测试一下普通情况吗？边缘情况？我怎么知道一个功能已被充分覆盖？ 我总是有一种可怕的感觉，尽管测试可以证明某个功能在特定情况下可以工作，但是证明该功能在一定时期内是完全没有用的。

122 unit-testing  testing  test-coverage 

有人坚持认为集成测试是种种种错误和错误的方法 -一切都必须经过单元测试，这意味着您必须模拟依赖项；由于种种原因，我并不总是喜欢这种选择。 我发现在某些情况下，单元测试根本无法证明任何事情。 让我们以以下（简单，幼稚的）存储库实现（在PHP中）为例： class ProductRepository { private $db; public function __construct(ConnectionInterface $db) { $this->db = $db; } public function findByKeyword($keyword) { // this might have a query builder, keyword processing, etc. - this is // a totally naive example just to illustrate the DB dependency, mkay? return $this->db->fetch("SELECT * …

120 unit-testing  testing  integration-tests  repository-pattern 

我试图养成定期用我的代码编写单元测试的习惯，但是我已经读过第一件事，编写可测试的代码很重要。 这个问题涉及编写可测试代码的SOLID原则，但是我想知道这些设计原则是否有益（或至少无害），而根本不计划编写测试。需要澄清的是-我了解编写测试的重要性；这不是它们有用性的问题。 为了说明我的困惑，在启发这个问题的那篇文章中，作者给出了一个检查当前时间并根据时间返回一些值的函数示例。作者指出这是错误的代码，因为它会产生内部使用的数据（时间），因此很难进行测试。但是，对我而言，将时间作为争论似乎有点过头了。在某个时候需要初始化值，为什么不最接近消耗量呢？另外，在我看来，该方法的目的是基于当前时间返回一些值，通过将其设为参数，您可以暗示可以/应该更改此目的。这个问题以及其他问题使我想知道可测试的代码是否与“更好的”代码同义。 即使在没有测试的情况下，编写可测试的代码是否仍然是一种好习惯？ 可测试的代码实际上更稳定吗？建议重复。但是，这个问题与代码的“稳定性”有关，但是我在更广泛地询问代码是否由于其他原因（例如可读性，性能，耦合性等）是否优越。

103 design  unit-testing  testing  tdd 

我了解自动测试的价值，并在问题足够明确的地方使用它，以便我可以提出好的测试用例。但是，我注意到，这里和StackOverflow上的某些人只强调测试一个单元，而不是测试其依赖项。在这里我看不到好处。 为避免测试依赖性而进行的模拟/存根增加了测试的复杂性。它在生产代码中增加了人工灵活性/去耦要求，以支持模拟。（我不同意说这会促进良好设计的任何人。写额外的代码，引入诸如依赖注入框架之类的东西，或者以其他方式增加代码库的复杂性以在没有实际用例的情况下使事情变得更灵活/可插拔/可扩展/解耦是过度设计，而不是好的设计。） 其次，测试依赖项意味着使用其他输入的测试关键的底层代码，而不是那些编写测试的人明确想到的输入。通过在高级功能上运行单元测试而不嘲笑它所依赖的低级功能，我发现了低级功能中的许多错误。理想情况下，这些可以通过单元测试中的低级功能找到，但是总是会漏掉一些情况。 另一面是什么？单元测试不要同时测试其依赖关系真的很重要吗？如果是这样，为什么？ 编辑：我可以理解模拟外部依赖项（如数据库，网络，Web服务等）的价值。（感谢Anna Lear激励我进行澄清。）我指的是内部依赖项，即其他类，静态函数等。没有任何直接的外部依赖关系。

103 testing  unit-testing  dependency-injection  mocking