我应该使用TDD吗？

你是否有易于单元测试的组件？你能构建一个由可单元测试组件组成的应用程序吗？这是在TDD环境下工作时需要思考的心态。

很容易说“这是一个GUI应用程序！我的东西不可能进行单元测试！”这可能会成为自我实现的预言。当然，你不能轻松地对所有小部件的布局进行单元测试，但你的程序有多少与小部件的布局相关联？你可能会因为某些方面与GUI小部件的布局过于紧密耦合，或者与其他不易于单元测试的部分过于紧密耦合而阻止自己进行良好的TDD。停下来挑战自己——这真的是这种情况吗？我能将代码分隔和模块化，使其更好地与系统的这些部分隔离开来吗？这样做是否合适（单元测试的收益是否超过了成本）？不要因为你的软件与不可单元测试的组件相关联就接受它是不可能的。

随着经验的积累，TDD 的开销会减少，并且很快就会变得比不使用 TDD 开发的开销更小。

然而，一开始的开销可能相当大，由于缺乏经验而浪费时间做错事情。在关键项目中包含学习新开发技术所需的时间是有风险的。

如果以务实的方式完成，这将是一个巨大的好处。反对它的论点总是认为它需要太多时间，但我们都知道，在许多情况下，明知 sacrificing quality 可能会更具破坏性。

自我学习 TDD 已经有 3 年了，我可以诚实地说，我已经看到它带来了巨大的价值，但我也看到了它完全浪费的时间。

以下是每种情况的示例...

有益的：处理相当复杂、具有许多依赖和变体且不断演进的解决方案。设计时考虑测试，并拥有一套回归单元测试套件，使我们能够快速适应变化，并能够重构代码以提高可维护性。在创建单元测试时，我们使用了 80/20 规则，并省略了低价值的测试用例。

无益的：（教条式地）决定每个 QA 可想到的测试案例都必须有一个自动化的测试，甚至包括用户界面 (UI) 测试案例。许多情况非常基础，只涉及很少或非常简单的代码。要让其中许多工作起来需要极大的设置，并增加了要维护的测试量，以至于它严重拖慢了我们的速度。

TDD是一种很好的实践方法，我对它评价极高。

然而，如果我处在你的位置，我现在不会过于担心TDD，而是集中精力编写一些良好的单元测试代码。

当你遇到棘手的业务逻辑时，你总是可以稍后再开始使用TDD。

我不希望你对TDD有不好的体验，如果你在交付压力下没有使用该实践的经验，这种情况可能会发生。

在工作中使用TDD之前，尝试在家里练习一些TDD Katas可能是个好主意。

一些好的Katas可以在这里找到。

TDD、伪TDD和准TDD。有许多不同的方法。这取决于谁强制执行TDD的级别。同样也有很多优缺点，这又取决于你的人员配备。这是一种双刃剑哲学之一。如果你不知道自己在做什么，或者你的团队内有不同层次的理解，它会让你陷入泥潭，导致内部斗争，最终可能会完全放弃TDD。另外，TDD与（仅编写测试）不同。