Questions tagged «tdd»

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

410 unit-testing  tdd  builds 

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

178 unit-testing  tdd  test-automation 

我在培训视频上阅读和看到的所有示例都具有简单的示例。但是我看不到绿色后如何执行“真实”代码。这是“重构”部分吗？ 如果我有一个使用复杂方法的相当复杂的对象，并且编写了测试和最低要求以使其通过（在它第一次失败后为红色）。我什么时候回去写真实的代码？在重新测试之前我要写多少实际代码？我猜最后一个是直觉。 编辑： 感谢所有回答。您的所有回答都极大地帮助了我。关于我所问或困惑的事情似乎有不同的想法，也许有，但是我所要问的是，说我有建校的申请。 在我的设计中，我有一个要开始的架构，即“用户故事”，依此类推。在这里，我将获取这些用户故事，然后创建一个测试以测试用户故事。用户说，我们有人入学并支付注册费。因此，我想一种使失败的方法。为此，我为X类（可能是学生）设计了一个测试类，该类将失败。然后，我创建“学生”类。也许我不知道“学校”。 但是，无论如何，TD 设计迫使我思考整个故事。如果我可以使测试失败，那么我知道为什么会失败，但这以我可以通过测试为前提。这与设计有关。 我将此比作考虑递归。递归并不是一个很难的概念。可能很难真正掌握在脑海中，但是实际上，最难的部分是知道递归何时“中断”，何时停止（当然，我的看法。）因此，我必须考虑停止什么递归优先。这只是一个不完美的类比，它假定每个递归迭代都是一次“通过”。再次，只是一个意见。 在实施中，学校很难见到。在可以使用简单算术的意义上，数字分类帐和银行分类帐是“容易的”。我可以看到a + b并返回0，依此类推。对于一个人系统来说，我必须更加思考如何实现它。我有失败，通过，重构的概念（主要是由于学习和这个问题。） 我认为，我不知道的原因是缺乏经验。我不知道如何无法注册新学生。我不知道如何使某人输入姓氏并将其保存到数据库中。我知道如何为简单的数学做一个+1，但是对于像一个人这样的实体，我不知道我是否只是在测试是否有人返回一个数据库的唯一ID或其他东西。数据库或两者兼而有之。 或者，也许这表明我仍然感到困惑。

147 tdd 

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

139 unit-testing  tdd 

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

138 unit-testing  tdd 

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

131 unit-testing  tdd 

我经常使用非常数值/数学的程序，其中函数的确切结果很难预先预测。 在尝试将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 

我和我的朋友一直在努力准确地对什么是集成测试进行分类。 现在，在回家的路上，我才意识到，每当我尝试给出一个真实的集成测试示例时，它实际上就是一个验收测试，即。业务人员会大声说出要指定系统应该提供的内容。 我检查了Ruby on Rails文档中对这些测试类型的分类，现在完全把我扔了。 您能否以一个真实的例子为我提供关于集成测试的简短学术描述？

110 testing  agile  tdd 

今天，我与一位同事进行了有趣的讨论。 我是一名防御性程序员。我认为必须始终遵循“ 类必须确保其对象在从类外部进行交互时具有有效状态 ”的规则。该规则的原因是该类不知道其用户是谁，并且在以非法方式与之交互时，它应该可以预见地失败。我认为该规则适用于所有阶层。 在今天我进行讨论的特定情况下，我编写了代码来验证构造函数的参数正确（例如，整数参数必须大于0），并且如果不满足前提条件，则会引发异常。另一方面，我的同事认为这种检查是多余的，因为单元测试应该捕获该类的任何不正确使用。此外，他认为防御性编程验证也应该进行单元测试，因此防御性编程会增加很多工作，因此对于TDD并不是最佳的。 TDD是否能够取代防御性编程，这是真的吗？结果是否不需要参数验证（并不是我的意思是用户输入）？还是两种技术相辅相成？

104 tdd  defensive-programming 

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

103 design  unit-testing  testing  tdd 

我现在正在学习TDD。我的理解是，私有方法是不可测试的，不应担心，因为公共API将提供足够的信息来验证对象的完整性。 我了解OOP已有一段时间了。据我了解，私有方法使对象更易于封装，从而更能抵抗更改和错误。因此，默认情况下应使用它们，并且仅将对客户端重要的那些方法公开。 好吧，对于我来说，可以创建一个仅具有私有方法并通过侦听其他事件与其他对象进行交互的对象。这将被非常封装，但是完全不可测试。 另外，为了测试而添加方法也被认为是不好的做法。 这是否意味着TDD与封装不一致？适当的余额是多少？我现在倾向于公开大多数或所有方法...

99 object-oriented  testing  tdd 

您的TDD体验的不利方面是什么？您是否发现婴儿脚步（使测试呈绿色的最简单方法）烦人且无用？您是否发现无价值测试（当测试最初具有意义但最终实现时会检查与其他测试相同的逻辑）维护的重要性吗？等等 上面的问题是我在TDD体验期间感到不舒服的事情。因此，我很感兴趣其他开发人员是否有类似的感受，以及他们如何看待它们。 感谢描述TDD负面方面的文章链接（Google充斥着正面且经常是狂热的文章）。

94 tdd 

如今，测试驱动开发（TDD）规模很大。我经常在Programmers SE和其他场所将它推荐为解决各种问题的解决方案。我不知道为什么行得通。 从工程角度来看，这使我感到困惑，原因有两个： “编写测试+重构直到通过”方法看起来令人难以置信的反工程。例如，如果土木工程师使用该方法进行桥梁建造，或使用汽车设计师作为汽车制造商，则他们将以很高的成本重塑桥梁或汽车，结果将是没有经过深思熟虑的体系结构而造成的混乱。“重构直到通过”准则通常被视为忘记建筑设计并做任何必要的工作以符合测试的要求。换句话说，测试而不是用户来设置需求。在这种情况下，我们如何保证结果中的良好“缺陷”，即最终结果不仅是正确的，而且是可扩展的，健壮的，易于使用的，可靠的，安全的，安全的等。这就是架构通常要做的。 测试不能保证系统正常运行。它只能表明它没有。换句话说，测试可能会向您显示如果系统未通过测试，则该系统包含缺陷，但是通过所有测试的系统并不比未通过测试的系统安全。测试覆盖率，测试质量和其他因素在这里至关重要。在民用和航空航天业中，已经报道了“绿色”结果给许多人带来的错误安全感觉，这是极其危险的，因为它可能被解释为“系统还不错”，而当它真正意味着“系统还不错时”。作为我们的测试策略”。通常，不检查测试策略。或者，谁来测试测试？ 总而言之，我更关心TDD中的“驱动”位而不是“测试”位。测试完全可以；我没有得到的是通过设计来驱动设计。 我想看到一些答案，这些答案包含了为什么软件工程中的TDD是一种好的做法以及为什么我上面解释的问题与软件无关（或不足够相关）的原因。谢谢。

92 testing  tdd 

据我了解，大多数人似乎都同意不应直接测试私有方法，而应通过任何公共方法对其进行测试。我可以理解他们的观点，但是当我尝试遵循“ TDD的三个定律”并使用“红色-绿色-重构”循环时，我对此有一些疑问。我认为最好用一个例子来解释： 现在，我需要一个程序，该程序可以读取文件（包含制表符分隔的数据）并过滤掉包含非数值数据的所有列。我想可能已经有一些简单的工具可以做到这一点，但是我决定从头开始实现它，主要是因为我认为这对我来说是一个不错的，干净的项目，可以进行TDD的实践。 因此，首先，我“戴上红色帽子”，也就是说，我需要测试失败。我想，我需要一种可以找到一行中所有非数字字段的方法。因此，我编写了一个简单的测试，当然它无法立即编译，因此我开始编写函数本身，并且在来回循环（红色/绿色）之后，我有了一个有效的函数和一个完整的测试。 接下来，我继续使用函数“ gatherNonNumericColumns”，一次读取文件，并在每一行调用我的“ findNonNumericFields”功能以收集最终必须删除的所有列。几个红绿色循环，我完成了，又一次具有工作功能和完整的测试。 现在，我认为我应该重构。由于我的方法“ findNonNumericFields”仅是因为我认为实现“ gatherNonNumericColumns”时需要它而设计的，所以在我看来，让“ findNonNumericFields”成为私有是合理的。但是，这将中断我的第一个测试，因为他们将无法再访问他们正在测试的方法。 因此，我最终得到了一个私有方法，以及一组测试它的测试。既然有很多人建议不要测试私有方法，那感觉就像我在这里陷入困境。但是我到底在哪里失败了？ 我认为我本可以从更高的级别开始，编写一个测试以测试最终将成为我的公共方法的方法（即findAndFilterOutAllNonNumericalColumns），但这感觉与TDD的整个观点有些矛盾（至少根据Bob叔叔的说法） ：您应该在编写测试和生产代码之间不断切换，并且在任何时间点，所有测试都在最后一分钟左右进行。因为如果我从为公共方法编写测试开始，那么在私有方法中获得所有详细信息之前，将需要几分钟（甚至几小时，甚至几天）才能使该方法测试公共方法通过。 那么该怎么办？TDD（具有快速的红绿色重构周期）是否与私有方法不兼容？还是我的设计有问题？

91 tdd  refactoring  encapsulation 

我一直在听说测试驱动开发（TDD）的伦敦风格与芝加哥风格（有时称为底特律风格）。 犹他州极限编程用户小组工作坊： 交互风格的 TDD 在伦敦的Extreme Tuesday俱乐部流行后也被称为嘲笑风格，或伦敦风格。通常将其与底特律风格或传统的 TDD 形成鲜明对比，后者更加基于状态。 Jason Gorman的工作坊： 该讲习班既涵盖了芝加哥的TDD 学校（基于状态的行为测试和三角测量），也涵盖了伦敦的伦敦学校，后者更侧重于交互测试，模拟和端到端TDD，尤其着重于责任驱动设计和Steve Freeman和Nat Pryce的出色的《不断增长的面向对象的软件，由Tests引导》一书最近重新采用了“告诉，不要问”的面向对象方法。 张贴经典TDD还是“伦敦学校”？杰森·戈尔曼（Jason Gorman）的著作很有帮助，但他的例子使我感到困惑，因为他使用两个不同的例子，而不是两种方法都使用一个例子。有什么区别？您何时使用每种样式？

88 tdd  concepts