高级开发人员和单元测试 - 需要吗？他们可以使用走狗吗？[关闭]

StackOverflow https://stackoverflow.com/questions/23688

  •  09-06-2019
  •  | 
  •  

题

高级开发人员是否应该免于进行单元测试——还是应该允许他们使用走狗来实现单元测试？激励不习惯使用单元测试技术的人采用它们的最佳方法是什么？

有帮助吗？

解决方案

我认为从 TDD 纯粹主义者的角度来看（即认为应该编写单元测试的人 前 实现），高级开发人员应该编写 更多的 单元测试比走狗，不 较少的.

原因是，由于单元测试是第一位的，因此编写单元测试需要对代码库有深入的了解。如果您让走狗来编写它们，那么您实际上是在让那些对您的领域了解最少的人决定您的代码库的结构。对我来说这听起来是个坏主意。

其他提示

我认为让走狗为其他人做单元测试就破坏了单元测试的意义。编写代码的程序员应该知道代码应该如何破坏以及其预期行为是什么。仅仅因为其他人这样做并不能免除原始程序员的责任。

（由于性别中立，措辞很尴尬。）

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

实施测试的人就是所谓的“走狗”

听起来就像一只老狗不喜欢新把戏的例子。俗话说，让他们改变很难......TFD（测试优先开发）一旦开始做就会非常有趣，也许可以举办一个为期 1 天的关于 TDD 或 TFD 的内部研讨会，让整个团队参与其中。

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

绝对不。那么他们根本不应该是高级开发人员。高级开发人员应该是带路的领导者，走狗这样做的想法似乎很荒谬——那为什么还要费心去测试呢。

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

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

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

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

我能立即想到三种情况，即其他人为你编写测试 可以 可以接受。

  1. 验收测试/客户测试/端到端测试。不管你怎么称呼它们，但我的意思是从数据输入点（Web 服务、网页、应用程序屏幕输入）开始的测试，并遍历系统的整个堆栈（到数据库、调用另一个服务、返回到输入结果屏幕等）。这可能是由没有实现测试将要执行的各个单元的细节的人编写的。

  2. 结对编程（乒乓球图案) -

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

  3. 错误修复测试 - 当发现错误时，编写一个暴露缺陷的失败测试通常是一个很好的做法。一旦此测试到位，某人完全有可能实现使测试通过的代码。我认为这并不是一个好主意，因为编写因缺陷而失败的测试的行为通常会提供一些关于如何生成修复程序的见解。

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

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

这是我过去遇到过的问题。尽管我现在尝试在适当的时候执行 TDD，但我还是花了几个月的时间才发现编写测试确实有好处。
我相信试图向其他人展示 TDD 和单元测试的好处是相当困难的。只有当人们亲身体验到“啊哈”时刻时，TDD/单元测试突出了他们代码中的微妙之处，否则他们可能会错过，或者帮助他们在短时间内修复错误。看到好处。让他们达到这一点可能相当困难。
就我个人而言，我是通过上述 Ping Pong 模式中的结对编程实现这一目标的，与一位经验丰富的 TDDer 合作，并看到我们为解决一个不平凡的功能而编写的代码演变成一个所谓的优雅解决方案。接下来，这项工作通过了质量检查并进入了实时环境，没有任何缺陷。

简而言之，我认为与一位已经确信编写单元测试的好处的经验丰富的程序员结对是帮助某人有动力编写单元测试的好方法。

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

如果您需要激励开发人员进行单元测试，只需强调其优点以及从长远来看将节省的时间。如果他们养成了为代码编写单元测试的习惯，他们很快就会理所当然地开始这样做。

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

缺乏测试意愿几乎总是懒惰或无能（或两者兼而有之）的表现，而这两者都不是高级开发人员应该具备的特质。

我能想到的唯一适合高级开发人员让其他人编写单元测试的情况是初级新员工正在了解最新情况。在编写一些代码的同时，这可能是一项很好的任务。

单元测试的最大好处之一是立即反馈，告诉您做得如何。如果您外包测试的实施，那么无论您的设计是否有效，您都不会得到任何反馈。而那些与糟糕的设计作斗争的人却没有办法纠正它。

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

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

但重点是，没有人 真的 除了编写代码的人之外，其他人都知道代码应该做什么，而且通常他们甚至都不知道。

考虑到这一点，您不会从编写测试的“走狗”中获得太多价值，因为

  1. 他们不会深入了解所有微妙的极端情况
  2. 他们不会关心代码，因为他们没有对此进行任何投资
  3. 他们会觉得自己被当作白痴一样对待。

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

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

如果您有一个或多个开发人员无法适应，您应该尝试为他们提供一对一的帮助，并让开发人员配对进行单元测试，直到他或她开始掌握窍门。技术上没有什么复杂到可以编写代码的人无法进行单元测试的程度。如果情况确实如此，则可能是该人的技能出现更大问题的先兆。

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

好吧，我会说是的，但前提是允许走狗将发现的错误的修复交给高级人员。那会教他。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top