如何说服队友使用TDD [关闭]

我是团队中唯一使用TDD的人。如何使他们使用它？

我很烦恼，当我退出时，某人的代码会破坏我的测试，而我是必须修复它们的人。

使用github，fork和pull请求是否可以解决此问题，以便他们需要在接受pull之前通过测试？

我不是项目经理，我似乎无法说服她使用它。

我认为，说服测试的唯一方法就是证明它们是有用的，即测试失败有助于发现和修复错误。

但是，您描述问题的方式似乎不是这里的情况。看...

...当我退出时，某人的代码将破坏我的测试，而我是必须对其进行修复的人。

如果我理解正确，则意味着必须修改测试。好吧，这听起来不像测试失败有助于发现并修复错误吗？如果测试不能帮助您发现错误，那么说服您的同事就处于很弱的地位-他们期望得到什么？脆弱的测试代码中乏味的修复程序？

这听起来像是一个死胡同，但实际上并非如此。您的最终目标（相信TDD）仍然很有意义，请不要放弃。只需将精力重新集中在消除发现的障碍上即可。

现在困扰您的测试失败实质上是“错误警报”，这意味着这些是测试中的错误，而不是代码中的错误。利用这些机会来改进测试，学习如何进行可靠的测试设计。进行测试，以减少“错误警报”的发生频率，并使发现被测代码中的实际错误更容易。

当您发现真正的错误时，请让您的同事知道并帮助他们修复-不要忘记指出这些错误是您的测试中发现的。这将为说服您的同事奠定坚实的基础。

值得一提的是，如果您最终说服队友使用TDD，则很可能需要再次使用在“初步”阶段开发的测试设计技能。想一想...

...将测试驱动的开发介绍给您的经验不足的同事会发生什么？

首先要期待的是，伙计们将开始编写糟糕的测试，并且（恐怖！）甚至在学习过程中打破好测试。为了帮助他们找到正确的方法，您需要对良好的测试设计有充分的了解。

您现在在测试中发现并修复的所有错误，在所有团队成员开始学习时都会一次又一次地重复。如果（何时！）发生，您最好准备快速清楚地说明如果希望他们对TDD保持积极态度如何进行改进。

当我想鼓励使用测试驱动开发时，我运行了Cyber​​-Dojo。通过这种练习，重点不在代码本身上，而是在编写代码的过程中。

我们成对地度过了一个下午，重复相同的kata，但条件不同。我们从所有小组同时进行一项练习开始。这提供了基线。

然后，我们讨论了TDD的一些基本原理，让每个人都改变了合作伙伴并重复同样的方法。我们重复同样的方法来强调代码的生成，而不是让人们专注于命名测试用例和“红色/绿色”循环。

然后，我们再次重复该动作，但是大约每10分钟，每组中的一个人就会移到另一组中，模拟这些天我们经常发现自己处于不稳定状态的团队环境。

在最后的迭代中，我们让两个合作伙伴每隔10分钟左右将其更改为不同的组。这有助于证明，使用TDD，即使从一个团队向完全不同的团队移交也不必太痛苦，因为该项目只应该是每个红色/绿色工作周期。

有趣的是，在会议之前很少有人做过TDD，但是那里的TDD知识迅速传播，直到通过kata进行最后迭代之前，大多数人都以TDD方式思考，或者至少可以理解为什么这样做可能是有益的。

人们通常说，下午既有趣又有益，我们现在正在寻找在我的工作场所使用Cyber​​-Dojo的其他方法。

由乔恩·贾格尔（Jon Jagger）撰写的Cyber​​-Dojo，对于这种锻炼非常有效。这是一个基于Web的集成环境，用于认真进行TDD 练习并了解团队动态。它有很多专门选择的kata来帮助人们专注于TDD的过程而不是问题。它还支持多种语言，从Python和Ruby到Java和C ++。

最好的事情是，做完答卷之后，您可以返回并查看每个参加活动的小组的红色/绿色进度（或者可能不是* 8'）。它的红绿灯是可视化的TDD过程是如何工作的好方法。

如果您想要自己的Cyber​​Dojo服务器，则可以在github上找到整个项目，甚至在那里链接一个Turnkey Linux设备虚拟机，这意味着如果您已经安装了VMware Player或VirtualBox，则可以在其中运行几分钟下载设备！

如果他们拒绝TDD，那就没关系。许多人（包括我自己）首先遇到编写单元测试的问题。

但是，您应该提出一个问题：根本没有任何单元测试，以及单元测试中断的问题。单元测试是一个安全网，可以防止许多可能的错误，并允许代码重构。说明更高的代码质量和更干净的代码。

我认为最好的方法是找到一个视频，解释使用TDD的优点，并在会议上进行演示。

如果她拒绝听，那么您可以尝试去找她上方的人，但是如果您的老板如此固执，那可能不是很明智。

很难说服人们改变他们的习惯，但是您可以尝试以下方法：

• 与其他开发人员交谈，并向他们解释为什么您认为TDD是个好主意。
• 说服他们（或至少其中一些）在有限的时间内尝试
• 尝试建立一些良好的最低要求，以便团队合作。他们不一定必须执行TDD，但是他们当然不应该在未通过单元测试的代码中签入。与说服他们使用TDD相比，这是一个单独的问题，而解决这个问题要重要得多。
• 尝试说服管理层强制执行TDD的试用期。您将必须准备提供一些证据，证明这是一种好的做法，以及如何在将来节省公司的时间和金钱。

如果这些都不起作用，那么您可能要考虑在其他地方工作。还有许多其他公司可以使您的生活变得更加轻松。

这里有2个略有不同的问题：促使人们去做TDD和打破测试的人们。

我不确定第一个问题，我个人认为这是一种人为的工作方式，并不适合所有类型的开发。我都有一套很好的单元测试套件，但是我通常会发现先编写代码然后再编写测试会更有效率，因为编写代码时我的想法总是在变化，而且浪费时间编写测试早期（IMO）。

在第二个问题上，设置项目，以便在签入时运行单元测试，以便其他开发人员别无选择，只能知道他们已经破坏了测试。

正如在其他许多“我应该如何说服X使用Y方法/技术”中所说的那样，我的答案始终是相同的：例如。

使用它并获得更好的（可衡量的）结果。然后确保其他人注意。

在现有项目中，您不需要。就像您要更改大括号在旧版代码中的放置方式一样，因为您不喜欢缩进样式。

很多好的建议。现在，还有更多...

您必须一次赢得一个Luddite的人心（WHAM）。忘了强迫他们下咽。在一段不确定的时间内（很抱歉）有很多对象课程。最终，您将达到临界点，说服“正确”的人。

在WHAM活动中，您对TDD持续不断的热情和追求非常重要。

您必须将测试中断和代码更改变成可教的时刻，这对您的共同编码者至关重要。使其个性化。IE他们是否关心提供高于平均水平的干净代码的声誉？他们是否在乎管理问题，因为集成测试人员对他们进行了现实检查，而使他们对现在已经晚了的代码之以鼻？杰克是否想修改一些困难的代码，但又害怕副作用？

收集作为诱因程序员引起的错误的测试破坏的好例子。编码人员将更改测试视为无关代码的不必要工作。他们必须了解测试只是覆盖了他们的屁股。

找到一些具有全局含义的代码（一些简单的实用方法），构建一些测试，然后证明测试允许更改整个应用程序而无需担心地震。我的确也要强调情感问题！

收集一些简单的代码清洗时间示例（即，投入生产），并证明尽管在测试编码方面付出了很多努力，但我们还是更快地完成了她，并且质量更高。

警告： TDD不能解决问题，不能克服糟糕的OO设计和编码（但绝对可以暴露它）。不要让Luddites责怪测试代码的努力。

我会再试一次以说服经理。从您写的内容来看，我认为您无法说服队友在她的背后做TDD。

你必须说她的语言。经理往往不会对技术留下深刻的印象，但是他们了解业务语言：

• 测试将节省开发过程中的时间，因为您将自动运行测试，而不是手动测试（尝试在本地重现错误，使用rails控制台...）。

• 测试将在应用程序维护期间节省大量时间，使您可以在每次更改某些内容时轻松检测到错误。说明测试需要较高的初始投资，但从长远来看，它们会自己付出代价（维护好测试通常是快速而容易的）

• 那多余的时间你会怎么做？制造摩尔的东西，使他们赚钱:)

对于程序员，请尝试以下参数（对我有用，可以追溯）：“无论如何，无论有无TDD，您都在测试代码。只有您手动执行代码，而不是使其自动化。聪明的开发人员将尽可能多地实现自动化。 ”

在具有截止日期的真实项目中，人们希望专注于利用他们所知道的完成工作。那只是人的本性。而且，如果您从未学过TDD，在这种情况下，您将与她一样。我保证。

为什么垃圾收集人群不喜欢，学习和生活RAII？您如何拥护自动内存管理，却又坚持传统的管理方式来管理文件，连接等常规资源？因为RAII是他们在需要完成工作的截止日期时不了解，理解并且没有时间使用的技术。

我敢打赌，您不会使用RAII，也不愿意为您当前的项目学习和理解它。与不愿意学习和理解TDD的同事一样。