测试驱动的开发“进入障碍”？

Question

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

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

欣赏的想法/感受。

谢谢，

编辑 - 是否有人知道提倡TDD的人的任何高调引用？很想知道链条有多高。欢呼声。

Answer 1

一些障碍包括：

1. 现有的代码库，不适合单元测试。
2. 难以进行单元测试的问题域，例如GUI工作或与第三方系统的集成。
3. 对单元问题的集成问题的看法（换句话说，如果它不能端到端地工作则不会做任何事情，那么测试单元的重点是什么）。
4. 想要提前设计并拥有清晰的系统设计而不是让测试推动设计的思维方式
5. 一种政治文化，其设计由与开发人员/团体不同的人/团体完成，而且该设计不是单元测试友好的。
6. 无法克服TDD不是为了测试一致性的事实（诸如“编写测试的人不应该是编码测试的人，他们对自己过于宽容”这样的变体）
7. 直到现在他们不是他们编码的方式，所以这种转变更难。
8. 有时某项测试很难设置，因此该方法会因为“感觉”变慢而放弃。
9. 设计要求不能很好地适应不断发展的设计或根本不考虑（认为核电厂控制软件或其他系统的实际寿命取决于它们的正常运行）。
10. 如果每个人在检入代码之前没有运行测试，那么测试会因为错误的原因而开始经常中断（这是代码的预期行为发生了变化，但是测试没有跟上，所以测试错了，不是代码）所以它们可以被视为拖累。

Answer 2

就进入壁垒而言，实际上，因为您明确编写了在代码被认为完成之前必须通过的测试，所以在获取功能代码所涉及的开发周期中的提前期更长。现在，当使用TDD时，您可以有效地保证代码的某种程度的质量（无论您选择哪种质量级别进行测试），因此通常对提前期的延迟进行补偿，但严格来说，使用TDD获取功能代码有更长的准备时间。

实际上，如果你有编写无错误代码的程序员，TDD将会拖累你的开发周期。当然，TDD的价值在于，没有任何编码人员可以随时编写无错误的代码，因此修复错误的成本必须在某个地方考虑​​因素;在TDD中，测试基础设施的成本是前置的。

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

Answer 3

团队和/或管理层的支持是一些公司的最大障碍。如果你是单独的开发人员试图使用TDD而你无法让其他人对这个项目感兴趣，那就非常令人沮丧。

当然，这根本不是财务障碍。最大的感知财务障碍可能是时间。如果你有一个很大的代码库，你需要编写单元测试，它看起来相当艰巨。您的经理（或他们之上的人）会质疑您为什么要花时间编写不会为代码添加功能/功能的代码。很多人没有意识到预先编写测试（正如你在TDD中所做的那样）实际上可以节省你的时间，无论是立即还是从长远来看，当你维护代码时。

Answer 4

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

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

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

你第一次这样做，你感觉有点......好傻和愚蠢。为什么我故意让我的代码失败？ “让它成功”的理念似乎不合逻辑，我们这么长时间都被教导过。

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

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

Answer 5

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

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

诀窍在于考虑如何使用代码而不是关注如何编写代码。说起来容易做起来......

当你开始“得到它”时，知道在哪里停止编写测试有点困难。 你必须记住测试证明什么都没有，所以你只是不能编写测试来涵盖所有情况，你必须选择最有用的......并且已经很多了！

Answer 6

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

• 单元测试用户界面（Web或胖客户端）很棘手。我知道有很多很多试图解决这个问题，但我认为它们中的任何一个都没有让它变得非常简单 - 因为这是一个自然难的问题。
• 另一方面，尽管有各种方法可以更容易地测试数据库所涉及的代码，但它仍然很棘手且耗时。
• 虽然良好的测试肯定会加速整体开发，但测试是一种技能 - 当你吮吸它时，单元测试可能比它的价值更麻烦，这意味着你永远不会积累技能......
• 经理们经常将其视为开发的一个额外选择 - 一个很好而不是批判性的。这意味着当项目不可避免地存在资源紧张时，这是第一件事。

Answer 7

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

我认为最大的障碍是建立首先从测试开始的学科，但我不认为TDD（或任何相关的实践）应该作为一个绝对，绝对，100％的时间解决方案。

TDD是每个开发人员库中的工具。我倾向于认为它在大多数时候对我很有用。一个不习惯于编写测试的开发人员（首先或其他）可能很难在TDD被迫使用时完成任何工作，因为他们无法首先考虑编写测试。

我认为自己是一位经验丰富的测试作家，但我不能总是考虑测试。有些问题本身并不适合，或者至少我的脑袋有些日子不会缠绕它。某些类型的代码（例如UI和客户端代码）不能很好地总是编写测试。

如果你有一个开发团队不习惯于编写测试，我会先推动它。我没有问题要求所有新代码都有可能/实用的单元测试。一旦测试成为一门学科，将开发人员单独或作为一个团队转换为TDD就会容易得多。

Answer 8

一个非显而易见的障碍（至少对我来说不明显）是构建基础架构。如果开发人员无法控制构建过程，或者基础架构太过巴洛克式而无法管理，那么将测试集成到构建过程中将以“效率”的名义分流到一边。 （当然，在这些情况下，构建基础架构应该以效率的名义放在一边。）