Questions tagged «tdd»

假设您正在编写Yahtzee游戏TDD风格。您要测试代码部分，确定一组五个压模辊是否满座。据我所知，在进行TDD时，您遵循以下原则： 首先编写测试 写出最简单可行的方法 优化和重构 因此，初始测试可能如下所示： public void Returns_true_when_roll_is_full_house() { FullHouseTester sut = new FullHouseTester(); var actual = sut.IsFullHouse(1, 1, 1, 2, 2); Assert.IsTrue(actual); } 当遵循“写出可能的最简单的IsFullHouse方法”时，您现在应该这样编写方法： public bool IsFullHouse(int roll1, int roll2, int roll3, int roll4, int roll5) { if (roll1 == 1 && roll2 == 1 && roll3 == 1 …

36 unit-testing  tdd 

我对编码并不陌生。我已经（认真）编码了15年以上。我一直对我的代码进行一些测试。但是，在过去的几个月中，我一直在使用Ruby on Rails学习测试驱动的设计/开发（TDD）。到目前为止，我还没有看到好处。 我看到为某些事情编写测试有一些好处，但很少。尽管我喜欢首先编写测试的想法，但与调试实际代码相比，我发现我花费大量时间尝试调试我的测试，以使他们说出我的意思。这可能是因为测试代码通常比其测试的代码复杂得多。我希望这只是可用工具（在这种情况下为RSpec）的经验。 但是，我必须说，在这一点上，令人沮丧的程度加上令人失望的性能不足令人无法接受。到目前为止，我从TDD看到的唯一价值是不断增长的RSpec文件库，该库可用作其他项目/文件的模板。与实际的项目代码文件相比，这没有什么用处，也许没有用。 在阅读现有文献时，我注意到TDD似乎需要大量时间，但最终会获得回报。我只是想知道，有没有现实世界的例子？这种巨大的挫败感是否能在现实世界中得到回报？ 我真的希望我不要在这里的其他地方错过这个问题。我进行了搜索，但是所有问题/答案都已经过了几年了。这是我难得的一次机会，当时我发现一个开发人员会对TDD不好说，这就是为什么我花了很多时间在此上的原因。但是，我注意到似乎没有人指出具体的实际示例。我确实读过一个答案，说在2011年调试代码的人会感谢您拥有完整的单元测试套件（我认为评论是在2008年提出的）。 所以，我只是想知道，在所有这些年之后，我们是否最终有任何例子表明收益是真实的？是否有人真的继承或返回了使用TDD设计/开发的代码，并具有完整的单元测试集，并且确实感到收获了？还是您发现您花了太多时间试图弄清楚测试正在测试什么（以及为什么它很重要），以至于您只是把整个混乱扔进了代码中？

36 ruby-on-rails  unit-testing  tdd 

在进行TDD并编写单元测试时，如何在编写要测试的“实现”代码的第一次迭代时抵制“作弊”的冲动？ 例如： 让我们需要计算一个数字的阶乘。我从一个单元测试开始（使用MSTest），例如： [TestClass] public class CalculateFactorialTests { [TestMethod] public void CalculateFactorial_5_input_returns_120() { // Arrange var myMath = new MyMath(); // Act long output = myMath.CalculateFactorial(5); // Assert Assert.AreEqual(120, output); } } 我运行此代码，但由于该CalculateFactorial方法甚至不存在而失败。因此，我现在编写代码的第一次迭代以实现被测方法，并编写通过测试所需的最少 代码。 问题是，我一直很想写以下内容： public class MyMath { public long CalculateFactorial(long input) { return 120; } } 从技术上讲，这是正确的，因为它确实是“作弊”，因为它实际上甚至没有尝试执行计算阶乘的功能，尽管它确实是进行特定测试通过（变为绿色）所需的最少代码。当然，现在重构部分成为“编写正确的功能”的练习，而不是真正的实现重构。显然，添加具有不同参数的其他测试将失败并强制进行重构，但是您必须从该测试开始。 因此，我的问题是，如何在“编写最少的代码以通过测试”同时又保持其功能与您实际试图实现的精神之间取得平衡？

36 unit-testing  tdd 

我一直看到建议，我们应该首先编写单元测试，然后再开始编写代码。但是我觉得（对我来说）走另一条路要舒适得多-编写代码，然后进行单元测试，因为在编写实际代码后，我觉得我们更加清楚了。如果我先编写代码然后进行测试，那么即使我将精力集中在创建可测试的设计上，也可能需要稍稍更改一下代码以使其可测试。另一方面，如果我先编写测试，然后编写代码，则当代码成形时，测试将非常频繁地更改。 正如我看到的有关开始编写测试然后继续进行编码的大量建议一样，如果我以其他方式进行编写，然后编写单元测试，则有什么缺点呢？

33 testing  unit-testing  code-quality  tdd 

测试驱动的开发。我知道了，喜欢它。 但是编写测试确实需要开销。因此，应该在整个代码库中普遍使用TDD，还是在TDD提供较高ROI的区域以及其他ROI如此低以至于不值得关注的区域。

31 development-process  tdd 

在测试驱动开发（TDD）中，您从次优解决方案开始，然后通过添加测试用例和重构来迭代地产生更好的解决方案。该步骤应该很小，这意味着每个新解决方案都将以某种方式位于前一个解决方案的附近。 这类似于数学上的局部优化方法，例如梯度下降或局部搜索。这种方法的一个众所周知的局限性是它们不能保证找到全局最优值，甚至不能保证找到可接受的局部最优值。如果您的起点与所有可接受的解决方案之间有很大范围的不良解决方案，则无法到达此目标，该方法将失败。 更具体地说：我正在考虑一个场景，在该场景中，您已经实现了多个测试用例，然后发现下一个测试用例将需要一种完全不同的方法。您将不得不放弃以前的工作，然后重新开始。 这种想法实际上可以应用于所有以小步骤进行的敏捷方法，而不仅仅是TDD。TDD与局部优化之间的拟议类比是否存在严重缺陷？

30 agile  development-process  tdd  development-methodologies 

根据TDD的规则，单元测试是在生产代码之前编写的，但是，在具体（非模拟）有线对象之间进行交互的集成测试又如何呢？ 它们应该在单元测试之前还是在生产代码之后编写，仅用于测试“接线”？ 请注意，我不是在谈论验收或功能测试，而是在进行较低级别的集成测试。

30 tdd  integration-tests 

BDD和TDD是什么关系？ 据我了解，BDD在TDD之上增加了两个主要内容：测试命名（确保/应该）和验收测试。在BDD开发期间，我应该遵循TDD吗？如果是，我的TDD单元测试是否应使用相同的sure / should样式命名？

30 tdd  bdd 

我知道有些人大力支持测试驱动的开发。我过去曾使用过单元测试，但仅用于测试可以轻松测试的操作，或者我认为很可能是正确的操作。完整或接近完整的代码覆盖范围听起来会花费很多时间。 您将测试驱动的开发用于哪些项目？您是否仅将其用于特定大小以上的项目？ 我是否应该使用它？说服我！

30 programming-practices  unit-testing  tdd 

假设我开始开发角色扮演游戏，角色扮演者会攻击其他角色以及类似的东西。 应用TDD，我做了一些测试用例来测试Character.receiveAttack(Int)方法内部的逻辑。像这样： @Test fun healthIsReducedWhenCharacterIsAttacked() { val c = Character(100) //arg is the health c.receiveAttack(50) //arg is the suffered attack damage assertThat(c.health, is(50)); } 说我有10种方法测试receiveAttack方法。现在，我添加一个方法Character.attack(Character)（调用receiveAttackmethod），并在经过一些TDD循环测试之后，我做出一个决定：Character.receiveAttack(Int)应该是private。 前10个测试用例会发生什么？我应该删除它们吗？我应该保留方法public（我不这样认为）吗？ 这个问题不是关于如何测试私有方法的，而是关于在应用TDD时重新设计后如何处理它们的问题。

29 object-oriented-design  tdd 

纠正错误时，鼓励我在这里工作，首先编写一个因给定错误而失败的测试，然后修复代码，直到测试通过。这遵循TDD惯例，应该被认为是很好的惯例，但是我注意到它往往会产生与实现非常接近的神秘测试。 例如，我们在发送作业，达到某个状态，中止并重试时遇到问题。为了重现此错误，编写了一个包含线程同步的大量测试，其中包含大量的模拟和其他东西。它确实可以完成工作，但是现在我正在重构代码，我发现删除此庞然大物非常诱人，因为要适应新设计，确实需要很多工作（再次）。它只是在单个特定情况下测试一个小功能。 因此，我的问题是：如何测试难以重现的错误？您如何避免创建测试实现的东西，并损害重构和可读性？

29 testing  tdd 

在另一个问题中，揭示了TDD的难题之一是在重构期间和重构之后使测试套件与代码库保持同步。 现在，我非常喜欢重构。我不会放弃做TDD。但是我也遇到过这样的测试问题，即以较小的重构会导致很多测试失败。 重构时如何避免破坏测试？ 您是否将测试写得更好？如果是这样，您应该寻找什么？ 您是否避免某些类型的重构？ 有测试重构工具吗？ 编辑：我写了一个新问题，问我要问什么（但将此问题保留为一个有趣的变体）。

29 development-process  tdd  refactoring 

我们有一个新的（相当大的）项目正在启动，我们计划使用TDD进行开发。 TDD的想法失败了（有很多业务和非业务原因），但是现在我们正在进行对话-是否应该编写单元测试。我的朋友说，在没有TDD的情况下编写单元测试没有任何意义（或几乎为零），我们应该只关注集成测试。我相信相反，编写简单的单元测试仍然有一定的道理，只是为了使代码更可靠。你怎么看？ 补充：我认为这不是>> thisquest <<的重复-我了解UT和TDD之间的区别。我的问题不是关于差异，而是关于编写没有TDD的单元测试的感觉。

28 unit-testing  tdd 

我将在Ruby on Rails中开始我的第一个实际项目，并且强迫自己编写TDD测试。我看不出编写测试的真正优势，但是由于它看起来非常重要，因此我将尝试。 是否有必要测试应用程序的每个部分，包括静态页面？

28 testing  tdd 

在繁重的jquery / backbonejs Web应用程序中期望100％的代码覆盖率是否可行？当实际代码覆盖率在javascript / jquery中徘徊在92％-95％左右时，由于未达到100％覆盖率而导致冲刺失败是否合理？

28 code-quality  tdd  bdd