强制开发人员进行单元测试

Question

首先是一点背景。我工作的公司编写基于Web的软件，这是我们客户的托管解决方案（即ASP（应用程序服务提供商））。我们正在采用敏捷实践，例如Scrum，我们执行sprint来为我们的产品构建新功能。

我是TDD（测试驱动设计）的支持者，作为我在sprint中提供的一部分，我总是编写测试，并且总是将它们与构建集成（即ccnet）;但是其他开发人员不遵循这种做法而且没有强制执行。

强制开发小组提供单元测试作为sprint中提供的内容的一部分是一种好习惯吗？

Answer 1

除非你是一个权威职位，否则你能做的最好的事情就是让他们相信测试套件的价值。

如果开发人员没有正确看待它，就很难让开发人员看到这个问题。

尝试与另一位开发人员配对，向他们展示首先编写测试所带来的好处和清晰度。如果你不这样做，他们可能会编写所有代码，让它工作，然后编写测试。因此，从他们的角度来看，它只是一个额外的任务，无法帮助他们完成任务。

另请注意，人们通常不了解如何编写好的测试。更有甚者，有些人不知道如何使用像jmock这样的工具，这会导致他们陷入困境并放弃编写测试。

Answer 2

在我看来，将任何东西强加给任何人都不是一个好习惯。我会在每次获得机会时向他们展示TDD的好处。这应该会自动让团队的其他成员自愿练习TDD。

Answer 3

您不需要口型服务单元测试，您需要全心全意的单元测试。这不是可以被迫的东西。你需要做的是随着时间的推移影响你的队友，看看单元测试的好处，并发展单元测试文化。

首先，您需要了解不同的人因不同的原因而改变。在Crossing the Chasm术语中，有远见的人会采用新技术，因为他们更好，但实用主义者采用新技术要么是因为他们解决了当前的问题/痛苦，要么是因为其他人都在采用它。

您的任务就是展示单元测试如何解决您团队目前所感受到的痛苦。当你一个接一个地赢得人们时，你最终可以达到一个临界点，单位测试是常态，每个人都同意它。但是，如果你不能将单位测试与你的团队感到痛苦联系在一起，那么你说服他们的努力可能会失败。

Answer 4

考虑到单元测试可以长期提高代码和软件质量，我想说，是的，让开发人员提供单元测试是好的做法 - 无论是否是某种冲刺的一部分。 / p>

我见过的单元测试的两个主要障碍是：

• 开发人员没有明白这一点：“我们为什么要编写更多代码来测试？”
• “我们没有时间编写单元测试”

要回答第一点，我想你必须提供某种示范/形成;如果你能让开发人员看到为什么单元测试是有用的，他们会喜欢它们，并使用/开发它们;但他们需要了解为什么这些是有用的：除非你是他们的老板，否则你不能强迫人们开发单元测试。
而且，即使你是他们的老板，如果他们被迫，他们可能也不会做最好的工作：如果人们理解为什么以及怎么做，单位测试通常会做得更好！

回答第二点......好吧，你显然需要让你的开发人员有一些“特殊”时间来开发单元测试;这可能意味着更少的时间进行手动测试，顺便说一句。

另一件事是：很难知道“测试什么”和“如何测试”：你需要向同事解释/演示：有些东西无法测试，有些东西不需要是的，有些东西不是“单元可测试的” - 好吧，我想，除非你的软件设计得很好^^

Answer 5

我过去在许多工作和合同中都处于这个位置，所以我最终通过提倡Development Driven Development而灰心丧气并接受了黑暗。

我发现，当大多数管理人员接受XP时，他们会接受丢弃文档，而不是真正做TDD。大多数团队的程序员都因快速入侵而获得奖励，从而将缺陷排除在队列之外，而且大约有10名经理有勇气站在高级管理层，作为产品整体质量的倡导者，而不是底层 - 按季度开展业务的方式。毕竟，支付任何费用的大多数软件工作都是企业赞助的，弗洛伊德证明公司是疯了。

或者至少，他应该有。

Answer 6

有一篇很棒的Joel on Software文章，名为Getting Things Done When You're Only a Grunt。他应用于联合测试的策略如下：

1. Just Do It

   最重要的是，我认为。定期编写测试，不要让它看起来像是你自己将它们视为开发的一小部分。

2. 利用病毒式营销的力量

   如果您在别人的代码中看到错误，请编写一个触发它的测试并向他展示。也许他看到了你的观点。

3. 创建一个卓越的口袋

   确定那些对这个想法持开放态度的团队成员，但不太确定如何使用单元测试并设置一些测试类，直到他们每个人都知道如何去做。然后转向其他人。一旦你不再是唯一一个，事情就会变得容易得多。

4. 中立Bozos

   将有几乎不可能编写测试的团队成员。也许这些应该通过定期破解他们的代码来处理 - 然后指出，因为他们没有测试，你很难注意到。

Answer 7

它取决于您的版本控制，但有版本控制软件可以让您在签入之前或合并到生产分支之前运行脚本。如果单元测试失败，它将不会让开发人员签到。

Answer 8

首先，与您的经理交谈。如果他确信测试是一件好事，请在构建系统中添加一个覆盖测试。如果单元测试的覆盖率低于某个级别，则可以将其作为失败的构建进行处理。这为您的同事提供了一种衡量标准，一种了解未能提供经过测试的代码的方法。

在您的情况下，NCover似乎integrate nicely into CC.NET。

Answer 9

创建一个您希望开发人员实现的矩阵。

确保每个故事都有一个用于创建单元测试的子任务。

Answer 10

没有。根据我的经验，TDD在实践中并不是那么有用。我有时会将它用于非常通用的基础类（如几何或通用数据结构），它们可以自然地用于自动化测试。但是对于UI组件或业务逻辑，我发现它比它的价值更麻烦。