问给出一个短时间(2周)的冲刺，放弃TDD来“把事情做好”是可以接受的吗？

EN

2周迭代对很多人来说并不短，因为我们很多人都在做1周的迭代。Kent Beck甚至试图鼓励每天的部署--清理开发过程是有好处的，这样它才能做出响应。

从来不会降低TDD质量来清除中的东西--以后清理起来太难了，你最终只能告诉客户，他们可以迫使你发布快速、肮脏、被黑客攻击的版本。他们看不到作为结果而产生的垃圾代码--他们也没有机会维护它。如果有人想让我这么做我就不干了.我拒绝在“没有时间进行适当测试”的地方工作。这不是一个有效的借口。

注意:当我写测试驱动开发时，我包括了功能测试。这些测试很重要，因为它们应该在可识别的用户故事方面演练对客户有意义的场景。我通常从功能测试开始写故事，因为这是最重要的测试--“测试客户得到他们所描述的……”所有其他测试可能都需要协商，但当我领导团队时，我希望每个故事至少有一个功能测试，否则(正如scrum人员所说)“没有完成！”;-)

不要认为你可以在以后添加测试--这样做要困难得多。(两种方法我都试过了--相信我。)在你使用的时候放入测试真的更便宜--即使你不得不重构和重写，或者随着系统的发展而丢弃一些测试。

没有良好的代码覆盖率，你就不能获得高质量的代码。

代码测试覆盖率是这里最重要的词。涵盖可能会崩溃的东西，而不仅仅是无数无意义的测试-覆盖您需要担心的事情的关键测试。

如果你不能及时得到它，这是一个问题，你需要思考为什么？

• 这是一个计划/发布调度问题吗？
• 是否有代码维护/重构问题导致事情停滞不前？
• 是否有人给团队施加了不合理的压力？(让首席技术官痛打他们一顿...)

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

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

如果您确实跳过了单元测试来获得一些东西，并且幸运的是它可以工作，那么您应该将其视为一种技术债务，应该尽快偿还。

如果你可以不用测试就能准确地编写代码，为什么还要使用单元测试呢？单元测试可以帮助您更快地编写代码，也可以帮助您编写更好的代码。如果两者都不起作用，就不要使用单元测试。