TDD是否为了小项目而过度使用？
我最近读了很多关于TDD的文章，而且我现在还不是很卖东西。我做了很多小型的爱好项目（只有我），我担心TDD是否过分这样的事情。 虽然我看到了像TDD一样的3个开发者的小型开源项目。 （虽然我见过一些也有TDD的单人项目）
所以TDD总是一件好事，或者在什么样的门槛下使用？
TDD闪耀在小型项目中。 在一个小型项目中坚持TDD通常要容易得多 ，现在是学习TDD遵循规范的好时机。
根据我的经验， 较大的项目往往是在某个门槛放弃TDD的项目。 （我不是说这是一件好事）。
我认为较大的项目往往放弃它有几个原因：
- 开发人员缺乏经验 – 无论是一般还是与TDD
- 时间限制—较大的项目本质上更为复杂
- 增加的复杂性导致超时期限，unit testing往往首先被排除
- 这可以由一个缺乏经验的团队加剧
小项目可能有你没有意识到变成大项目的习惯，那么你希望你开始使用TDD 🙂
一切都有成本效益曲线。
忽略许多经常性TDD的争议好处，TDD是值得的，如果你的实现会经常变化，那么拥有一个自动化testing套件的好处将超过初始开发可能涉及的任何额外成本。
从我个人的经验来看，我可以这样说：
- 每次我开始我个人的小爱好项目之一，我发誓使用TDD来开发它。
- 每一次我都没有。
- 每一次我都后悔了。
我总是觉得这个问题很有趣。 有什么select？ 编写只能编译的代码，从不运行来validation其正确性？ 你是否等到你部署到生产，看看你的class级是否工作？
如果我们从未有过一种被称为TDD的做法，或者在1997年JUnit被发明之前，那么是否没有代码testing？ 当然有。 那么为什么现在有这么大的一个testing框架来帮助你呢？
即使是在一个紧迫的最后期限的小项目，也不会等到生产才能确定是否有效。 写testing。
对于任何“小”的项目来说都没有必要，但我把“小”定义为less于一个类。
矫枉过正？ 一点也不。 除了可以依赖的编写代码的主要优点之外，因为您已经考虑了可能会破坏的方式，所以在testing驱动开发的过程中，您将更具有纪律性，并且可能更具生产力。 拿起任何的实用程序员的书籍提示和灵感。
我会利用TDD的一个小项目的机会，只是让你的脚湿。 即使你意识到这不适合你，这也是一个很好的学习经验。
我从我们当地的一个敏捷组织的一个成员那里听到的一点是，她并没有发现TDD对于项目的最早阶段是有用的，在这个阶段你基本上在做快速的草图，而且你不确定什么形状的东西还在采取。 但只要您对接口的外观有了一些了解，就可以开始使用testing来帮助您定义接口。
TDD是另一个工具，如文档，以提高代码的清晰度。 当其他人需要使用你的代码时，这是至关重要的，但是当我们回顾我们自己的代码时，我们中的许多人发现它也是非常有帮助的。 曾经有一个爱好项目，在离开它一段时间之后，又回过头来，遇到了一些奇怪的代码，并想知道“为什么我写了这个 ？
我相信这对大多数项目都是值得的。 TDD和随后的回归testing使您不仅可以确定组件是否在写入时运行，而且还可以引入更改和重构。 如果您的testing足够完整，您可以覆盖偶发/不可能的边缘情况，并生成/维护更可靠的代码。
在项目生命周期中继续前进，持续的testing周期将为您节省人工重复testing的时间，并避免错误/不完整地重复错误的可能性。
我和其他人使用TDD的任何不只是说几行代码的项目。
一旦你得到testing错误，很难不使用TDD做任何事情。 就个人而言，我发现由于TDD，我的代码已经改进了好几倍。
根据我的经验，有90％的人对这些利益怀疑并没有尝试过。
尝试一下，怀着怀疑的心态。 衡量你希望从之前和之后获得的东西。
我可以指出减less浪费时间来修复生产中发现的错误。 我看到/测量了更好的生产力（更快的上市时间），代码质量的改进（跨越各种指标），更紧密地匹配需求（即由于需求不明确而减less返工）等。
我对使用TDD的项目感觉更好，但后来我感觉“受testing感染”。 对于使用TDD的项目，开发人员的士气通常较高，作为一个主观意见。
如果你没有得到这些结果，请不要使用它。 如果你不太关心这些结果来衡量它们，那么使用TDD或不要让你感觉更好。
TDD有一个学习曲线。 如果你不愿意付出认真的努力，那就不要麻烦了。
一个小项目是一个很好的方式来给它一个认真的尝试，而不会冒很大的风险。
如果您认为由于您的编写代码而导致您不期望的结果性错误可能会发生，则TDD是有意义的。
那么，TDD的决定因素（至less这是你的问题所推断的）并不是真正的人数，而是项目的规模。
TDD的优势在于，您开发的所有代码都将经过unit testing。 这样，以后重构时可以节省很多麻烦。 当然，如果你的项目有一个体面的大小，这当然是非常必要的。
用良好的OO代码开发的项目本质上非常适合testing，并且可以说在开发风格上可以获得testing驱动的重点。 我实际上是说，当你在预算有限的新兴技术上下功夫时，考虑所有的TDD是完全可选的。
我会说这完全取决于给定的时间框架。 如果你有时间花费你通常需要的时间的两倍，那就去做吧。 但在我看来，速度是当今竞争力最重要的因素之一。
我认为无论大小如何，TDD都是值得的（即使是一个级别 – 因为首先编写testing可以帮助您devise一个更合理的devise）。
我觉得这个地方可能不是必要的，当你正在build立一个项目，你不知道你想要什么，你不可能关心可维护性。 我发现在工作中没有任何项目适合这个类别，但是我发现偶尔我正在开发个人项目。 在这些情况下，我通常在学习一个新的框架，不知道自己从一开始就在做什么，所以我的testing更可能因为错误的原因而打破时间，从而降低了它们的价值。
不过，我也承认，不使用TDD会使我的可维护性成为可能 – 一旦我知道自己在做什么，我会立刻回退到红/绿/重构。
