高级开发人员应该免于单元测试 - 还是应该允许他们使用走狗来实现它们？激励不习惯使用单元测试技术的人采用它们的最佳方式是什么？
Joe Schneider
问问题
849 次
13 回答
20
我会争辩说，从 TDD 纯粹主义者的角度来看（即认为应该在实现之前编写单元测试），高级开发人员应该比走狗编写更多的单元测试，而不是更少。
原因是由于单元测试是第一位的，编写它们需要对代码库有深入的了解。如果你让那些走狗写它们，你实际上是让那些对你的领域知之甚少的人来决定你的代码库的结构。这对我来说听起来是个坏主意。
于 2008-08-22T23:06:42.783 回答
7
我认为让走狗为别人做单元测试正在破坏开始进行单元测试的意义。编写代码的程序员应该知道代码应该如何中断以及它的预期行为是什么。仅仅因为其他人没有解除原始程序员的责任。
（由于性别中立，措辞尴尬。）
于 2008-08-22T23:00:25.357 回答
5
编写测试的人 = 定义系统应该如何工作 = “老板”
执行测试的人是所谓的“走狗”
听起来像是不喜欢新花样的老狗。俗话说，很难让他们改变...... TFD（测试优先开发）一旦开始就非常有趣，也许有一个涉及整个团队的关于 TDD 或 TFD 的内部 1 天研讨会。
于 2008-08-22T23:09:46.737 回答
5
高级开发人员是否应该免于单元测试
绝对不。他们根本不应该是高级开发人员。高级开发人员应该是带路的领导者，走狗做这件事的想法似乎很荒谬——那为什么还要麻烦测试。
于 2008-08-22T23:54:59.203 回答
4
我认为处理这些情况的一种可能方法是高级开发人员可以编写大部分单元测试。这意味着他们正在定义和设计程序的工作方式。然后，走狗可以编写代码以匹配测试，同时学习高级人员的设计理念。
于 2008-08-22T23:22:18.767 回答
4
第一部分（高级开发人员和单元测试）
当我想到 TDD 或测试驱动设计时，单元测试的目的是推动系统的进化设计，希望确保持续改进。
编写测试会塑造代码或突出已做出决定的问题，希望能导致重构过程以提高设计质量。
根据我的经验，高级开发人员通常是最有经验和能力的人，这意味着他们应该能够更好地发现这些重构机会。（检测代码气味）
我可以想到三种情况，在这些情况下，其他人为你编写测试是可以接受的。
- 验收测试/客户测试/端到端测试。随便你怎么称呼它们，但我的意思是从数据输入点开始的测试，（Web 服务、网页、应用程序屏幕输入），并遍历系统的整个堆栈，（到数据库，调用另一个服务，返回到输入结果屏幕等）。这可以由没有实现将由测试执行的各个单元的细节的人编写。
配对编程（乒乓模式） -
A 编写了一个新测试并发现它失败了。
B 实现了通过测试所需的代码。
B 编写下一个测试。
A 实现它。错误修复测试 - 当发现错误时，编写一个暴露缺陷的失败测试通常是一个好习惯。一旦这个测试到位，完全有可能有人实现了使测试通过的代码。我不认为这是一个好主意，因为编写由于缺陷而失败的测试的行为通常会提供一些关于如何产生修复的见解。
简而言之，我对您的第一个问题的回答是，任何高级开发人员都不应该免于编写单元测试。
第二部分（激励人们编写测试）
这是我过去遇到的问题。尽管我现在尝试尽可能多地执行 TDD，但我还是花了几个月的时间才发现编写测试有真正的好处。
我相信试图向其他人展示 TDD 和单元测试的好处是相当困难的。只有当人们自己体验到，当 TDD/单元测试突出了他们代码中的一个微妙之处时，他们可能会错过，或者帮助他们在短时间内修复错误的“啊哈”时刻，他们看到好处。让他们达到这一点可能非常困难。
就我个人而言，我通过前面提到的 Ping Pong 模式中的结对编程，与一位经验丰富的 TDDer 一起工作，并看到我们为解决一个不平凡的功能而编写的代码演变成一个可以称为优雅解决方案的代码。接下来是通过 QA 并进入 Live Environment 的工作，没有任何缺陷。
简而言之，我认为与已经确信编写单元测试的好处的经验丰富的程序员合作是帮助人们激发编写单元测试的动力的好方法。
于 2008-08-23T12:29:36.910 回答
2
绝对不; 至少因为为自己开发的代码编写测试要容易得多。但是对于所有开发人员来说，无论资历如何，对他们的所有代码进行单元测试都很重要；如果他们知道他们的代码必须是可测试的，那么他们的劳动成果将会大得多。
如果您需要激励开发人员进行单元测试，只需强调从长远来看将节省的优势和时间。如果他们养成为代码编写单元测试的习惯，他们很快就会理所当然地开始这样做。
于 2008-08-22T22:52:51.083 回答
2
如果您是高级开发人员，部分原因是您有足够的经验知道单元测试是一种很好的开发实践，可以帮助您开发出更好的软件
于 2008-08-22T23:05:35.767 回答
2
如果高级开发人员不进行自己的测试，那么他们就不是高级开发人员。
缺乏测试意愿几乎总是懒惰或无能（或两者兼而有之）的表现，这也不是高级开发人员应该具备的特质。
我能想到的唯一适合高级开发人员让其他人编写他们的单元测试的情况是在初级新员工正在加快速度的情况下。在编写一些代码时弄湿他们的脚可能是一项很好的任务。
于 2008-08-22T23:22:27.270 回答
2
单元测试的最大好处之一是即时反馈，它告诉你你做得有多好。如果您将测试的实施外包，那么无论您的设计是否有效，您都不会得到任何反馈。为糟糕的设计而苦苦挣扎的人没有办法纠正它。
于 2008-08-27T21:16:47.560 回答
1
我不认同 TDD 的信仰，但我确实看到了单元/等测试的很多价值，并且在我编写代码时经常这样做。
关键是，除了编写代码的人之外，没有人真正知道代码应该做什么，而且通常他们甚至都不知道。
考虑到这一点，你不会从“走狗”编写测试中获得太多价值，因为
- 他们不会深入了解所有微妙的极端情况
- 他们不会关心代码，因为他们没有任何投资
- 他们会觉得自己被当作白痴对待。
即使他们是白痴，也没有人喜欢被当作一个人对待。如果您希望您的员工辞职，这是鼓励他们的好方法。
于 2008-08-28T00:30:44.817 回答
1
没有人应该免于编写单元测试。所有开发人员都需要能够编写它们，并且单元测试也应该作为代码审查过程的一部分进行审查。单元测试的复杂性通常取决于开发人员的技能——更复杂的代码会交给更高级的开发人员，因此更复杂和更多的单元测试也会交给他们。
如果您有一个或多个无法适应的开发人员，您应该尝试为他们提供一对一的帮助，并将单元测试配对开发人员，直到他或她开始掌握它。没有什么技术上足够复杂，以至于可以编写代码的人无法进行单元测试。如果情况确实如此，那可能是该人技能组合出现更大问题的前兆。
我个人认为，对于测试人员来说，至少能够理解作为项目一部分的单元测试也是有帮助的。开发人员和测试人员之间的协作对于正确诊断和修复缺陷非常重要。我不希望他们必须编写它们，但他们应该能够与开发人员坐在一起并讨论测试为什么/如何失败的概念。
于 2008-12-07T15:26:27.293 回答
0
好吧，我会说是的，但前提是允许走狗将发现的错误的修复交给上级。那会教他的。
于 2008-12-07T15:18:55.013 回答