测试驱动开发“进入壁垒”？答案

【问题标题】：Test-Driven Development "Barriers to Entry"?测试驱动开发“进入壁垒”？
【发布时间】：2023-03-20 02:15:02
【问题描述】：

我正在研究测试驱动开发，其中一个讨论点是与 TDD 相关的“进入障碍”。有没有人有这方面的经验，在你参与过的任何项目中因为进入门槛太高而决定不使用 TDD？

据我所知，进入的唯一障碍是个别开发人员的知识（以及经验），大多数人并不完全习惯这个过程，而且有点陌生。鉴于大多数市场领先的工具都是开源的、免费提供的、有据可查的并且得到很好的支持，因此在财务上似乎非常有吸引力。

赞赏的想法/感觉。

谢谢，

编辑 - 有人知道提倡 TDD 的人的任何高调引用吗？很想看看它在链条上上升到多高。干杯。

【问题讨论】：

标签： tdd

【解决方案1】：

一些障碍包括：

现有的代码库不适合进行单元测试。
难以进行有意义的单元测试的问题域，例如 GUI 工作或与第三方系统的集成。
对单元问题的集成问题的看法（换句话说，如果它不能端到端地工作，它就不会做任何事情，那么测试单元的意义何在）。
一种想要提前设计并拥有清晰的系统设计而不是测试驱动设计的心态
一种政治文化，其中设计由与开发不同的人/团体完成，并且该设计对单元测试不友好。
无法克服 TDD 不是关于一致性测试这一事实（诸如“编写测试的人不应该是编写测试的人，他们对自己过于宽容”等论点） .
到目前为止，他们的编码方式并非如此，因此转变更加困难。
有时某个测试可能难以设置，因此该方法将被放弃，因为它“感觉”较慢。
设计要求不适合或根本不适合改进设计（认为核电站控制软件或其他系统的实际生命取决于它们的正常运行）。
如果每个人都没有在签入代码之前运行测试，测试开始经常由于错误的原因而中断（即代码的预期行为发生了变化，但测试没有跟上，所以测试是错误的，不是代码），因此它们可以被视为拖累。

【讨论】：

【解决方案2】：

就进入壁垒而言，实际上，由于您明确编写了在代码被认为完整之前必须通过的测试，因此在开发周期中获得功能代码所涉及的前置时间更长。现在，当使用 TDD 时，您可以有效地保证代码的一定质量水平（无论您选择测试的质量水平如何），因此这通常足以弥补交付周期的延迟，但严格来说，使用 TDD 获取功能代码的准备时间更长。

实际上，如果您有编写无错误代码的程序员，TDD 将拖累您的开发周期。当然，TDD 的价值在于没有任何程序员可以始终编写无错误的代码，因此必须在某个地方考虑修复错误的成本；在 TDD 中，测试基础设施的成本是预先加载的。

请注意，这绝不是 TDD 的负面影响。我只是说，前装可以被认为是“进入障碍”。就我个人而言，作为一名程序员，我会说投资回报是值得付出努力的，我认为大多数有经验的开发经理也是如此。

【讨论】：

> 如果你有编写无错误代码的程序员，那么你一定生活在另一个星球上......

【解决方案3】：

团队和/或管理层的支持是某些公司的最大障碍。如果您是唯一一个尝试使用 TDD 的开发人员，并且您无法让其他人对该项目感兴趣，那可能会非常令人沮丧。

当然，这根本不是财务障碍。最大的感知财务障碍可能是时间。如果您有一个需要编写单元测试的大型代码库，这似乎相当令人生畏。您的经理（或他们之上的人）会质疑您为什么要花时间编写不会向代码添加特性/功能的代码。许多人没有意识到预先编写测试（就像您在 TDD 中所做的那样）实际上可以节省您的时间，无论是立即还是在您维护该代码时的长期。

【讨论】：

【解决方案4】：

我认为一个主要障碍是它要求你改变你的思维方式。

在尝试 TDD 之前，我会创建一个类，比如 Employee，然后我会存根诸如 FirstName、LastName、Email 等内容。然后我会编写一些逻辑并忘记我错过了一些字段或其他内容。在我知道之前，我有一个非常复杂的类，不知道这些字段是否必要。

此外，这与我们习惯于编写软件的方式完全不同。我们习惯于编写软件，因为我们从签署我们支票的人那里收到功能。我们不习惯编写无法编译的代码，使其编译，然后使其工作以使我们的测试通过。

第一次这样做时，你会觉得有点……愚蠢和愚蠢。为什么我故意让我的代码失败？这似乎与我们长期以来一直被教导的“让它发挥作用”的理念不合逻辑。

到目前为止我工作的地方失败的几个原因：

正在进行的大部分项目都是较旧的应用程序。不是 .NET 之前的版本，而是 .NET 2.0，在某些情况下是 .NET 1.0。
其中一些项目没有得到很好的考虑，要么是因为 1.0 中没有该技术，要么是因为他们现在需要一些东西而快速构建。
正如 Jon 所指出的，对于单元测试、UI、数据库等，有些东西仍然是 PIA（痛苦的***）。
昂贵的工具。如果您只被允许使用 Microsoft 工具，那么以“正确的方式”执行此操作将付出高昂的代价。我们使用的是 resharper，所以这真的不是问题。
时间。我在一个由三个人组成的团队中，支持一个 30 人的部门。我们被认为是开销，我们的许多开发都包括将系统连接在一起

【讨论】：

【解决方案5】：

是的，进入的主要障碍是在你的头脑中或在其他程序员的头脑中。

一开始你不知道在测试中要写什么。

诀窍在于考虑如何使用您的代码，而不是专注于您将如何编写它。说起来容易做起来难……

当您开始“了解”时，有点难以知道在哪里停止编写测试。您必须记住，测试不能证明任何事情，因此您无法编写涵盖所有情况的测试，您必须选择最有用的测试......这已经很多了！

【讨论】：

【解决方案6】：

我当然看到了很多阻力。我遇到的障碍是：

对用户界面（Web 或胖客户端）进行单元测试很棘手。我知道有很多种尝试来解决这个问题，但我认为其中任何一个都没有让它变得非常简单 - 因为这是一个自然而然的难题。
另一方面，尽管有多种方法可以更轻松地测试与数据库相关的代码，但它仍然很棘手且耗时。
虽然好的测试肯定会整体上加快开发速度，但测试是一种技能 - 虽然你不擅长它，但单元测试可能比它的价值更麻烦，这意味着你永远不会积累技能...
经理们经常将其视为开发的可选附加项 - 拥有它而不是关键。这意味着当项目不可避免地出现资源紧张时，这是第一件事。

【讨论】：

【解决方案7】：

几周前我写了一篇关于这个的长篇文章，“Why I write tests first”。

我认为最大的障碍是建立从测试开始的纪律，但我不认为 TDD（或任何与此相关的实践）应该作为始终、绝对、100% 的时间解决方案来处理。

TDD 是每个开发人员的工具。我倾向于认为它在大多数时候对我很有效。不习惯编写测试（首先或其他方式）的开发人员如果强制执行 TDD，可能会很难完成任何事情，因为他们无法考虑首先编写测试。

我认为自己是一位经验丰富的测试编写者，但我不能总是从测试的角度思考。有些问题不适合它，或者至少我的头脑几天没有被它缠住。并且某些类型的代码（例如 UI 和客户端代码）并不适合始终编写测试。

如果您有一个开发人员团队不习惯性地编写测试，我会先推动它。我没有问题要求所有新代码在可能/可行的情况下都附带单元测试。一旦测试成为一门学科，将开发人员单独或作为一个团队转换为 TDD 会容易得多。

【讨论】：

【解决方案8】：

一个不明显的障碍（至少对我来说不明显）是构建基础设施。如果开发人员无法控制构建过程，或者基础架构过于陈旧而无法管理，那么将测试集成到构建过程中就会以“效率”的名义被搁置一旁。（当然，在这些情况下，应该以效率的名义将构建基础设施搁置一旁。）

【讨论】：