TDD 对于小型项目来说是不是太过分了？
我最近读了很多关于 TDD 之类的文章，但我还不太相信它。我做了很多小爱好项目（只有我自己），我担心尝试做 TDD 是否太过分了这样的事。尽管我见过有大约 3 个开发人员从事 TDD 的小型开源项目。 （虽然我见过一些也做 TDD 的单人项目）
那么 TDD 总是一件好事吗？或者在什么阈值下使用 TDD 才有意义？
I have been reading quite a bit recently about TDD and such and I'm not quite sold on it just yet.. I make a lot of small hobby projects(just me) and I'm concerned if trying to do TDD is overkill for such a thing. Though I have seen small open source projects with like 3 developers that do TDD. (though I have seen a few one-person projects that also do TDD)
So is TDD always a good thing to do or at what threshold does it make sense to use?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（17）
小项目可能会在您没有意识到的情况下变成大项目，那么您希望从 TDD 开始:)
Small Projects can have a habit of turning into big projects without you realizing, then you wish you'd started with TDD :)
TDD 在小型项目中大放异彩。在小型项目中遵守 TDD 通常容易，而且现在是练习和获得遵循 TDD 所需纪律的好时机。
根据我的经验，较大的项目往往是在某个阈值上放弃 TDD 的项目。 （我并不是说这是一件好事）。
我认为较大的项目倾向于放弃它有几个原因：
TDD shines in small projects. It's often much easier to adhere to TDD in a small project, and it's a great time to practice and get the discipline required to follow TDD.
In my experience larger projects tend to be the ones that abandon TDD at some threshold. (I'm not suggesting this is a good thing).
I think larger projects tend to abandon it for a couple of reasons:
根据我的个人经验，我可以这样说：
From my personal experience I can say the following:
一切都有成本效益曲线。
忽略 TDD 的许多经常受到争议的好处，如果您的实现经常发生变化，以至于拥有自动化测试套件的好处超过了初始开发中可能涉及的任何额外成本，那么 TDD 是值得的。
Everything has a cost-benefit curve.
Ignoring many of the oft' disputed benefits of TDD, TDD is worth it if your implementation will change sufficiently often that the benefit of having an automated test suite outweighs whatever extra cost might be involved in initial development.
我总是觉得这样的问题很有趣。还有什么选择呢？编写只编译但从不运行来验证其正确性的代码？您是否会等到部署到生产环境后才知道您的类是否有效？
如果我们从未有过称为 TDD 的实践，或者在 1997 年 JUnit 发明之前，是否就没有代码测试？当然有。那么，为什么现在有了测试框架来帮助您解决这个问题如此重要呢？
即使是时间紧迫的小项目也不想等到生产时才知道它是否有效。编写测试。
对于任何“小”项目来说都没有必要，但我将“小”定义为少于一个类。
I always find a question like this funny. What is the alternative? Writing code that you only compile and never run to verify its correctness? Do you wait until you deploy to production to find out if your class works at all?
If we never had a practice called TDD, or before JUnit was invented back in 1997, was there no code testing? Of course there was. So why is it such a big deal now that you have testing frameworks to help you with this?
Even a small project on a tight deadline won't want to wait until production to find out if it works. Write the tests.
It's not necessary for any project that's "small", but I define "small" as less than one class.
矫枉过正？一点也不。除了主要的好处之外，即编写可以依赖的代码，因为您已经考虑过它可能会被破坏的方式，此外，通过测试驱动开发，您将更加自律，并且可能会更加高效。挑选任何一本实用程序员书籍来获取技巧和灵感。
Overkill? Not at all. In addition to the main benefit, which is writing code you can rely on because you've thought about ways it can break, you'll be more disciplined and potentially more productive with test driven development. Pick up any of the Pragmatic Programmer books for tips and inspiration.
我会利用在一个小项目中使用 TDD 的机会来让您入门。即使您意识到这不适合您，这也会是一次很好的学习经历。
I would take the opportunity of using TDD with a small project just to get your feet wet. It would be a good learning experience even if you realize it's not for you.
我从我们当地敏捷小组的一位成员那里听到的是，她认为 TDD 对于项目的最早阶段没有用，在这个阶段，你基本上是在制作快速草图，并且你还不太确定事情的形状。但是，一旦您对接口的外观有了一些了解，您就可以开始使用测试来帮助您定义它们。
TDD 是另一个工具，就像文档一样，可以提高代码的清晰度。当其他人需要使用您的代码时，这一点至关重要，但我们中的许多人发现，在回顾我们自己的代码时，它也非常有帮助。您曾经有过一个爱好项目，在离开一段时间后重新拾起它，遇到了一些奇怪的代码，并想知道“我到底为什么要写那个？”
Something I've heard from one member of our local Agile group is that she doesn't find TDD useful for the very earliest stages of the project, where you're essentially making quick sketches and you're not really sure what shape the thing is taking yet. But as soon as you have some ideas of what the interfaces look like, you can start using tests to help you define them.
TDD is another tool, like documentation, to improve the clarity of the code. This is critical when other people need to work with your code, but many of us find it's also very helpful when looking back at our own code. Ever had a hobby project you picked back up after being away from it for a while, came across a weird bit of code, and wondered "why the heck did I write that?"
我和其他人在任何不仅仅是几行代码的项目上使用 TDD。
一旦发现测试 bug，就很难不使用 TDD。就我个人而言，我发现由于 TDD，我的代码已经改进了好几倍。
I and others use TDD on any project that is more than say a few lines of code.
Once you get the testing bug, it's hard not to use TDD for anything. Personally I've found my code has improved several times over due to TDD.
我相信对于大多数项目来说这都是值得的。 TDD 和随之而来的回归测试不仅使您能够确定组件在编写组件时是否正常工作，而且还能在引入更改和重构时确定组件是否正常工作。如果您的测试足够完整，您就可以涵盖罕见/不太可能的边缘情况，并生成/维护更可靠的代码。
在整个项目生命周期中，连续的测试周期将为您节省手动重复测试的时间，并消除错误/不完整地重复这些测试的明显机会。
I believe it's worth it for most any project. TDD and the consequent regression testing enables you not only to determine if components work as you write them, but as you introduce changes and refactorings. Provided your tests are sufficiently complete, you can cover scenarios for infrequent/unlikely edge cases and produce/maintain more reliable code.
Going forwards through the project lifecycle, the continuous testing cycles will save you the manual repetition of tests, and negate the obvious chance of repeating these incorrectly/incompletely.
嗯，实际上 TDD 的决定因素并不是人数（至少这是你的问题所推断的），而是项目的规模。
TDD 的优点是，您正在开发的所有代码几乎都会经过单元测试。这样你在以后重构时就可以省去很多麻烦。当然，当您的项目规模相当大时，这确实是必要的。
Well, it is not really the amount of people that is the deciding factor for TDD (at least this is what your question kind of infers), but much rather the size of the project.
Advantages of TDD are, that all the code you are developing will pretty much be unit-tested. That way you save a lot of hassle when refactoring later. Of course this is really just necessary when your project has a decent size.
根据我的经验，90% 的人对它的好处持怀疑态度，但他们都没有尝试过。
带着怀疑的心态去尝试一下。衡量您希望从中获得什么，之前和之后。
我可以指出修复生产中发现的错误所花费/浪费的时间要少得多。我看到/衡量了更好的生产力（更快的上市时间）、代码质量的改进（跨各种指标）、更符合需求（即由于需求不明确而减少返工）等。
我对项目“感觉”更好使用 TDD，但随后我就被“测试感染”了。作为主观意见，使用 TDD 的项目的开发人员士气通常较高。
如果您没有得到这些结果，请不要使用它。如果你不太关心这些结果来衡量它们，那么使用或不使用 TDD 会让你感觉更好。
TDD 有一个学习曲线。如果您不愿意付出努力认真尝试，请不要打扰。
小项目是认真尝试的好方法，而且不用冒太多风险。
In my experience 90% of the time those who are dubious about the benefits have not tried it.
Try it, with a skeptical mind. Measure what you are hoping to gain from it, before and after.
I can point to way less time spent/wasted fixing bugs found in production. I see/measure better productivity (faster time to market), improvements in code quality (across a variety of metrics), closer match to requirements (ie less rework because the requirements were not clear), etc.
I "feel" better about projects using TDD, but then I am "test-infected". Developer morale on projects using TDD is generally higher, as a subjective opinion.
If you don't get those results, don't use it. If you don't care enough about those results to measure them, then use TDD or not as makes you feel better.
TDD has a learning curve. If you are not willing to put the effort in to give it a serious attempt, don't bother.
A small project is great way to give it a serious try without risking much.
当您认为编写代码可能会导致您未预料到的后果性错误时，TDD 就有意义了。
When you think that consequential errors that you don't expect might happen as a result of your writing code, TDD makes sense.
我想说这完全取决于给定的时间范围。如果您有时间花费几乎是平时所需时间的两倍，那就去吧。
但在我看来，速度是当今最重要的因素之一（对于有竞争力的公司而言）。
I'd say it totally depends on the given time frame. If you've got the time to spend almost twice the time you'd usually require, then go for it.
But in my opinion speed is these days one of the most important factors (for competitive companies).
使用良好的 OO 代码开发的项目本质上非常适合测试，并且可以说可以在以后的开发风格中获得测试驱动的焦点。事实上，我想说的是，当您在预算有限的情况下沉迷于新兴技术时，考虑所有 TDD 是完全可选的。
A project developed with good OO code is inherently well-suited for testing, and arguably can acquire a test-driven focus later in the development style. I'd actually say that when you're waterfalling on emerging technologies with a limited budget, considering all that is TDD is completely optional.
我认为无论规模大小，TDD 都是值得的（即使它是一个类 - 因为首先编写测试可以帮助您提出更合理的设计）。
我觉得可能没有必要的地方是，当您正在构建一个项目时，您不确定自己想要什么，并且您不太可能关心可维护性。我发现工作中没有任何适合该类别的项目，但我发现偶尔我正在开发的个人项目就是这种情况。在这些情况下，我通常会学习一个新的框架，并且从一开始就不知道自己在做什么，因此随着时间的推移，我的测试更有可能因错误的原因而中断，从而降低其价值。
然而，我也承认不使用 TDD 会降低我的可维护性——一旦我知道我在做什么，我就会立即回到红/绿/重构。
I think TDD is worth it no matter the size (EVEN if it's one class - since writing the tests first can help you come up with a more sane design).
The place that I feel it may not be necessary is when you are building a project in which you aren't sure what you want, and you are unlikely to care about maintainability. I find that there aren't ANY projects that fit that category at work, but I have found that occasionally I am developing personal projects in which this is the case. In these cases, I am usually learning a new framework and have no idea what i'm doing from the beginning, so my tests would be more likely to break over time for the wrong reasons, thus decreasing their value.
However, I am also acknowledging that not using TDD is costing me maintainability - once I know what i'm doing, I promptly fall back to red/green/refactor.
摘要
上面已经有很多答案了。你的问题已经有很多年了，但请允许我插话：是的——做 TDD！测试你的代码！对此要聪明一些。
契约设计
TDD 和 BDD 在霍尔逻辑前置条件和后置条件（以及其他形式的代码正确性布尔断言）的上下文中可以得到最好的理解。我用过的最好的应用程序是 EiffelStudio 中的 Eiffel。
在开始衡量开发人员和 QA 人员在纠正错误上花费了多少时间之前，代码-失败-纠正模型是可以接受的。
TDD 和 BDD 也可能会犯很大的错误。 TDD 最终可能会产生大量代码膨胀，其中测试代码比生产代码更大且更难维护。 BDD（实际上主要是 DbC）可能会因其自身的复杂性、臃肿和成本开销而被误解、误用和管理不善。
需求
最深的需求是一种语言规范、编译器、IDE 和测试系统，其中包含 TDD + BDD（又名 DbC），所有适当的部分都放在适当的位置，而不是试图伪装成螺栓固定的弗兰肯斯坦废话。 TDD+BDD。
看到程序员试图将 TDD 和 BDD 的常见实现硬塞进根本没有契约设计意识的主流语言中，我觉得很有趣。每个人都通过这个语言规范/编译器/IDE 镜头来解释 TDD + BDD，就好像他们真正“了解”了它是什么一样。他们从来没有真正看到它是多么愚蠢和扭曲。
在《From the Cold》中，
TDD + BDD (DbC) 就像其他技术和主题一样被扭曲。例如：不要尝试使用 Java 作为理解面向对象理论的镜头。对于 C++ 或其他 C 派生语言也是如此。尝试使用语言作为学习面向对象的手段就像认为了解计算器就会使您了解微积分。
我所知道的唯一基于对 TDD 和 BDD 的理论理解而构建的语言规范、编译器、IDE 和测试系统是 Eiffel 和 EiffelStudio。我已经使用它大约 20 年了。我已经来过这个街区很多次了。看到你们在那些（对我来说）像春天万里无云的夏日一样清晰的主题上遭受痛苦和扭曲，我感到很沮丧。
Summary
You have a lot of answers above. Your question is years-old, but allow me to chime in: Yes—do TDD! Test your code! Be smart about it.
Design-by-Contract
TDD and BDD are best understood in the context of Hoare-logic preconditions and post-conditions (as well as other forms of code-correctness Boolean assertions). The best application of it I have ever used is Eiffel in EiffelStudio.
The Code-Fail-Correct model is okay until one starts to measure how much time developers and QA people spend on correcting bugs.
You can also go hugely wrong with TDD and BDD as well. TDD can end up generating massive code-bloat, where your test code is larger and harder to maintain than your production code. BDD—which is really mostly DbC—can be misunderstood, misapplied, and mismanaged with its own complexities, bloat, and cost-overhead as well.
The Need
The deepest need is for a language specification, compiler, IDE, and testing system where TDD + BDD (aka DbC) is baked in, with all the proper parts in their proper place instead of bolt-on Frankenstein nonsense trying to masquerade as TDD + BDD.
I find it humorous to watch programmers twisting in the wind of trying to shoehorn common implementations of TDD and BDD into mainstream languages that have no sense of Design-by-Contract at all. Everyone interprets TDD + BDD through this language-spec/compiler/IDE lens as though they truly "get" what it is. They never actually see just how silly and distorted it is.
In From the Cold
TDD + BDD (DbC) get distorted just like other technologies and topics. For example: Do not attempt to use Java as a lens for understand Object Oriented Theory. The same is true for C++ or other C-derived languages. Trying to use a language as a means to learn OO is like thinking that knowing your calculator is going to cause you to understand calculus.
The only language specification, compiler, IDE, and testing system I am aware of that is built from a theory understanding of TDD and BDD is Eiffel and EiffelStudio. I have been using it for some 20 years. I've been around this block many times. It frustrates me to see you all suffering and twisting about on subjects that (to me) are as clear as a cloudless summer day in springtime.