高级开发人员和单元测试 - 是否必需？他们被允许使用走狗吗？

Question

高级开发人员是否应该免于单元测试 - 或者是否应该允许他们使用走狗来实施它们？激励那些不习惯使用单元测试技术的人采用它们的最佳方法是什么？

Answer 1

我认为从TDD纯粹观点来看（即认为单元测试应该在实现之前编写），高级开发人员应该编写更多单元测试而不是lackeys，而不是 less 。

原因在于，由于单元测试首先出现，因此编写它们需要对代码库有深入的了解。如果你让这些走狗写下来，你基本上就是让那些对你的域知之甚少的人决定你的代码库的结构。这对我来说听起来不错。

Answer 2

我认为让走狗为其他人做单元测试正在破坏开始进行单元测试的重点。编写代码的程序员应该知道代码应该如何破坏以及它的预期行为是什么。仅仅因为其他人不会释放原始程序员的责任。

（由于性别中立而导致尴尬的措辞。）

Answer 3

编写测试的人=定义系统应该如何工作=“老板”

实施测试的人是所谓的“lackeys”

听起来像一只不喜欢新花样的老狗。正如俗话所说，让他们改变很难......一旦你开始做TFD（测试优先开发）非常有趣，可能会有一个关于整个团队的TDD或TFD内部为期一天的研讨会。 / p>

Answer 4

  

高级开发人员是否应免于单元测试

绝对不是。他们当时不应该是高级开发人员。高级开发人员应该是领导者展示出来的方式，认为走狗的想法似乎很荒谬 - 为什么还要费心去测试呢。

Answer 5

我认为处理这些情况的一种可能方法是高级开发人员可以编写大部分单元测试。这意味着他们正在定义和设计程序 的工作方式。然后，走狗可以编写代码来匹配测试，学习高级人员的设计哲学。

Answer 6

第一部分（高级开发人员和单元测试）

当我想到TDD或测试驱动设计时，单元测试的目的是驱逐系统的evolutionary design，希望确保持续改进。
编写测试可以塑造代码或突出显示问题做出已经做出的决定，希望能够通过重构过程来提高设计质量。

根据我的经验，高级开发人员通常是经验和能力最强的人，这意味着他们应该能够更好地发现这些重构机会。 （检测代码闻起来）

我可以想到三种情况，在我的脑海中，其他人为你编写测试可以接受。

1. Acceptance Tests /客户测试/结束测试。按照你的意愿调用它们，但我的意思是从数据输入点开始的测试（Web服务，网页，应用程序屏幕输入），并遍历整个系统堆栈，（到数据库，调用另一个服务，回到输入结果屏幕等）。这可以由没有实施将由测试行使的各个单元的细节的人编写。

2. 配对编程（Ping Pong Pattern） -

     

   A写一个新测试并看到它   失败。
   B实现了所需的代码   通过测试。
   B写下一个   测试。
   A实现它。

3. 错误修复测试 - 当发现错误时，编写一个暴露缺陷的失败测试通常是一种好习惯。一旦完成此测试，就有可能有人实现了使测试通过的代码。我不认为这是一个好主意，因为编写因缺陷而失败的测试的行为通常会给出一些关于如何产生修复的见解。

简而言之，我对你的第一个问题的回答是，高级开发人员不应该免于编写单元测试。

第二部分（激励人们写测试）

这是我过去遇到的问题。尽管我现在尝试并且经常使用TDD，但我花了几个月时间才发现编写测试确实有好处。
我相信试图向其他人展示TDD和单元测试的好处是非常困难的。只有当这个人为自己体验时，TDD /单元测试突显了他们的代码中的一个微妙之处，他们可能会错过或者帮助他们在短时间内修复错误，那就是'啊哈'时刻看到好处。 让他们达到这一点可能非常困难 我个人通过前面提到的Ping Pong模式中的结对编程到达那里，与经验丰富的TDDer一起工作，看到我们编写的代码解决了一个非平凡的功能，演变成可能被称为优雅的解决方案。接下来是通过QA进入实时环境的工作，没有任何缺陷。

简而言之，我认为与经验丰富的程序员合作，他们已经确信编写单元测试所带来的好处是帮助某人有动力编写单元测试的好方法。

Answer 7

绝对不是;至少是因为为自己开发的代码编写测试要容易得多。但是对所有开发人员来说，无论资历如何，对所有代码进行单元测试都很重要;如果他们发展知道他们的代码必须是可测试的，他们的劳动成果会更大。

如果您需要激励开发人员进行单元测试，只需按下从长远来看将节省的优势和时间。如果他们养成为代码编写单元测试的习惯，他们很快就会开始这样做。

Answer 8

如果您是高级开发人员，部分原因在于您有足够的经验知道单元测试是一种很好的开发实践，有助于您生成更好的软件

Answer 9

如果高级开发人员没有进行自己的测试，那么他们就不是高级开发人员。

缺乏测试意愿几乎总是懒惰或无能（或两者）的标志，也不是高级开发人员应该找到的特质。

我能想到的唯一情况是，一个高级开发人员让其他人编写他们的单元测试的适当位置将是一个初级新员工正在加快速度。在编写代码时，让自己的脚湿润可能是一项很好的任务。

Answer 10

单元测试的最大好处之一是即时反馈，它可以告诉您自己的表现如何。如果您将测试的实施外包，如果您的设计有效，您将得不到任何反馈。那些在糟糕设计中挣扎的人无法纠正它。

Answer 11

我不赞成TDD的宗教信仰，但我确实在单元/等测试中看到了很多价值，并且在编码时做了很多。

关键是，没有人真的知道代码应该做什么，除了编写它的人，他们通常甚至都不知道。

考虑到这一点，你不会从编写测试的'lackeys'中获得很多价值，因为

1. 他们不会对所有微妙的角落案件有深入的了解
2. 他们不关心代码，因为他们没有投入任何资金
3. 他们会觉得他们被当作白痴对待。

即使他们是白痴，也没有人喜欢被当作一个人对待。 如果您希望您的员工辞职，这是鼓励他们的好方法。

Answer 12

任何人都不应免于编写单元测试。所有开发人员都需要能够编写它们，并且单元测试也应该作为代码审查过程的一部分进行审核。单元测试的复杂性通常取决于开发人员的技能 - 更复杂的代码会交给更高级的开发人员，因此单元测试的复杂程度也越来越高。

如果你有一个或多个开发人员无法适应，你应该尝试给他们一对一的帮助，并与开发人员进行单元测试，直到他或她开始掌握它。没有什么技术上足够复杂，以至于可以编写代码的人无法进行单元测试。如果情况确实如此，则可能是该人技能组合问题的一个前兆。

我个人认为测试人员至少能够理解作为项目一部分的单元测试也是有帮助的。开发人员和测试人员之间的协作对于正确诊断和修复缺陷非常重要。我不希望他们必须编写它们，但是他们应该能够与开发人员坐在一起，然后讨论测试失败与否的概念。

Answer 13

嗯，我会说是的，但只有在允许将发现的虫子固定到老年人的情况下才允许。那将教会他。