Unit testing 考虑到一个短暂的（2周）冲刺，放弃TDD到“不”是可以接受的吗；把事情办好；？

给定一个短的sprint，放弃TDD在sprint中“完成任务”是可以接受的吗

例如，一项给定的工作可能需要sprint的1/3来围绕现有实现设计对象模型。在这种情况下，您很可能会得到实现的代码，比如说在冲刺的中途，而没有任何测试（在“设计”阶段实现单元测试将增加大量的工作量，测试可能会被丢弃几次，直到最终的“设计”确定下来）

之后，您可能会在第二周花一两天的时间添加单元/集成测试

---

这可以接受吗？

如果不需要测试就可以准确地编写代码，那么为什么还要使用单元测试呢？单元测试应该帮助您更快地编写代码，或者帮助您编写更好的代码。如果两者都不行，就不要使用单元测试。

在我看来，这可能是一种危险的权衡。虽然它在某些时候可能是可以接受的，但它确实开创了一个难以推翻的先例。我知道我在哪里工作，对于一些复杂的事情，我们往往需要实施一些东西几次，以便最终达到一个好的实施，因为在我们的项目中，更好的想法往往会经常出现

通常，在构建测试时，可以捕捉到缺少的需求，并且在获得大量代码之前，可以先绘制更完整的设计，否则可能会有一堆代码，人们可能希望尽量重用它们，而不是扔掉它们，从零开始构建更好的东西

---

关键是能够在第二周完成这些测试，而不是专注于新的工作，这似乎是一个优先事项。虽然这对一些人来说是好的，但对另一些人来说，这可能会导致灾难，IME。

我想说，如果这意味着你完成了一个本来无法完成的项目，那么绕过任何过程几乎总是可以接受的。流程应该在那里帮助您，但是如果您的流程没有帮助，那么就不要使用它（当然，在与团队其他成员讨论之后）

然而，绕过TDD很容易产生完全相反的效果——您可能会在需要发布之前编写错误代码，需要重写，因为最终测试显示了您应该尽早发现的关键问题，所以在这样做之前请仔细考虑

---

如果你真的跳过单元测试来获得一些东西，并且幸运的是它能够工作，那么你应该将它视为一种技术债务，应该尽快偿还。

根据我的经验，编写适当的单元测试所花费的时间至少与编写它测试的代码所花费的时间一样长，所以我很难想象在“一两天”内你将如何编写测试

也就是说，什么是“可接受的”取决于很多事情。不要将测试视为宗教问题。测试的存在是为了让您对代码有一定程度的信心。你只需要意识到，通过前面的测试，你也在增加你的风险。有时这是合适的，但有时不是

需要注意的两个极端：

• 说你以后会写测试，然后再也不去做了。这是“从未来借款”，你可以很快积累超过你偿还能力的债务

• 在测试上花费的时间比保证的要多。有些风险非常小，如果出现错误的预期成本低于编写测试的成本，那么测试就没有任何意义

---

根据您的描述，您并不是真正在做TDD，因为测试并没有推动设计。更重要的是，您正在进行单元测试，这仍然是一件好事

---

就基本问题而言，你能放弃测试吗？实际上，这是只有（团队的）经验才能指导你的事情，就权衡而言。通常情况下，你会后悔，但有时一次快速的恶意攻击总比根本不交付要好。

也许我遗漏了什么，但你要么按照公认的原则进行TDD，要么像一个TDD货物崇拜者一样运作

---

如果您的团队/公司已经决定使用TDD，并打算坚持使用它，那么您要么需要更长的冲刺时间，要么需要减少在两周内完成的功能量。

两周的迭代对很多人来说并不短。我们中的许多人都在进行一周的迭代。Kent Beck甚至试图鼓励日常部署，而清理开发过程以使其具有响应能力是有好处的

永远不要降低TDD的质量来把东西拿出来-以后清理起来要困难得多，你最终只是教会了客户他们可以迫使你快速、肮脏、被黑客攻击的发布。他们看不到作为结果产生的垃圾代码——他们也无法维护它。如果有人想让我这么做，我会退出。。。我拒绝在“没有时间进行适当测试”的地方工作。这不是一个有效的借口

注意：当我写TDD时，我会包括功能测试。这些测试很重要，因为它们应该根据可识别的用户情景来演练对客户有意义的场景。我通常从功能测试开始编写一个故事，因为这是最重要的测试——“测试客户得到他们所描述的…”所有其他测试可能都需要协商，但当我领导团队时，我希望每个故事至少有一个功能测试，或者它是（正如scrum人员所说的）“未完成！”；-）

不要认为你可以在以后加入测试——这样做要困难得多。（我已经尝试了两种方法-相信我。）在进行测试时进行测试确实更便宜-即使是