如何使初级程序员编写测试？[关闭]

我们有一个初级程序员，根本没有编写足够的测试。
我必须每两个小时na一下他，“你写考试了吗？
我们尝试过：

• 表明设计变得更简单
• 显示它可以防止缺陷
• 说只有不好的程序员不做才是我的事
• 本周末，两名团队成员不得不上班，因为他的代码具有NULL引用，并且他没有对其进行测试

我的工作需要质量稳定的高质量代码，通常每个人都“了解”它，而无需进行测试。我们知道我们可以让他编写测试，但我们都知道有用的测试是您参与其中时编写的测试。

您知道更多动机吗？

这是最难的事情之一。让你的人得到它。

有时，帮助初级程序员“入门”并向大四学生学习正确技术的最佳方法之一就是做一些结对编程。

尝试以下操作：在即将进行的项目中，将初级人员与您自己或其他高级程序员配对。他们应该一起工作，轮流“驾驶”（在键盘上打字）和“训练”（在驾驶员的肩膀上望着，并指出建议，错误等）。似乎浪费资源，但是您会发现：

1. 这些家伙在一起可以快速产生高质量的代码。
2. 如果您的初级人员学得足够多，可以与高级人员一起按正确的方向进行操作（例如，“好吧，在继续之前，让我们编写此功能的测试文件。”）您将非常值得使用这些资源。致力于。

也许您的团队中有人在Kate Rhodes 的单元测试101演示中演讲，我认为这是一种很好的方法，可以使人们对测试感到兴奋，如果交付得当的话。

您可以做的另一件事是让您的小开发人员练习保龄球游戏Kata，这将帮助他们学习测试驱动开发。它是用Java编写的，但是很容易适应任何语言。

在每次提交之前都要进行一次代码审查（即使这是1分钟的“我已经更改了此变量名”），并且作为代码审查的一部分，审查所有单元测试。

测试到位之前，不要在提交上签字。

（此外-如果未对他的工作进行测试-为何首先在生产环境中进行测试？如果未对其进行测试，则不要让其进入，这样您就不必在周末工作）

对于我自己，我开始坚持要把我发现和修复的每个错误都表示为一个测试：

1. “嗯，那是不对的...”
2. 发现可能的问题
3. 编写测试，表明代码失败
4. 解决问题
5. 证明新代码通过了
6. 如果原始问题仍然存在，则循环播放

我什至在尝试扩展内容的同时也尝试这样做，并且大约在同一时间完成了工作，只是有了部分测试套件。

（我不是生活在商业编程环境中，并且通常是从事特定项目的唯一编码器。）

想象一下，我是一个模拟程序员，名为... Marco。想象一下我不久前才毕业，从来没有真正写过测试。想象我在一家没有真正执行或要求这样做的公司中工作。好？好！现在想象一下，该公司正在转而使用测试，而他们正试图让我对此保持一致。对于到目前为止提到的项目，我会做出一些棘手的反应，好像我没有对此进行任何研究。

让我们从创建者开始：

说明设计变得更加简单。

如何编写更多内容，使事情变得更简单。我现在必须密切关注更多案件，等等。如果您问我，这将使其变得更加复杂。给我可靠的细节。

显示它可以防止缺陷。

我知道。这就是为什么它们被称为测试。我的代码很好，并且检查了问题，所以看不到这些测试有什么帮助。

说只有不好的程序员没有，这是我的事。

哦，所以您认为我是一个糟糕的程序员，只是因为我没有做太多的二手测试。我受到了侮辱，对你很生气。我宁愿获得帮助和支持，也不愿发表言论。

@ 贾斯汀·标准（Justin Standard）：在开始新的前景时，初级人员会与自己或其他高级程序员结对。

噢，这是如此重要，以至于将花费大量资源来确保我了解事物的完成方式，并为我提供一些帮助。这很有用，我可能会开始做更多的事情。

@ Justin Standard：阅读Kate Rhodes的单元测试101演示。

啊，那是一个有趣的演示，它使我想到了测试。它敲定了我应该考虑的一些观点，并且可能使我的观点有些摇摆。

我希望看到更多引人入胜的文章，以及其他工具来帮助我与认为这是做事的正确方法保持一致。

@ Dominic Cooney：花一些时间并分享测试技术。

嗯，这可以帮助我了解技术方面对我的期望，并且可以在我的知识包中放入更多可以再次使用的项目。

// @ Dominic Cooney：回答问题，示例和书籍。

有一个直接的人（人）来回答问题会有所帮助，这可能会使我更有可能尝试。好的例子很好，它为我提供了一些目标，也为我提供了参考。直接与此相关的书籍是很好的参考。

// @ Adam Hayle：惊喜评论。

说什么，您突然冒出了我完全没有准备的东西。我对此感到不舒服，但会尽力而为。现在，我将对此再次感到恐惧和不安，谢谢。但是，这种恐吓策略可能奏效了，但确实要付出代价。但是，如果没有其他效果，则可能只是需要这样做。

@ Rytmis：仅当项目具有测试用例时才被视为完成。

哦，有趣。我知道我确实必须立即执行此操作，否则我什么也没完成。这很有道理。

@ jmorris：摆脱/牺牲。

刺眼，刺眼，刺眼 -我有机会学习，在支持和帮助下，我可以成为团队中非常重要且功能强大的一部分。这是我现在的障碍之一，但是不会太久。但是，如果我不明白这一点，我就会明白。我想我会得到的。

最后，在所有这些方面，我团队的支持发挥了很大作用。总是欢迎一个人抽出时间来帮助我，并使我养成良好的习惯。然后，以后拥有一个良好的支持网络将是很棒的。总是有人会再来几次，并翻阅一些代码，以查看一切如何进行，而不是本身进行审查，而是以友好的访问的方式，这总是很高兴的。

推理，准备，教学，跟进，支持。

我注意到，许多程序员在合理的水平上看到了测试的价值。如果您听到诸如“是的，我知道我应该对此进行测试，但我确实需要尽快完成此工作”之类的事情，那么您就知道我的意思了。但是，从情感上讲，他们认为只有在编写实际代码时，他们才能完成工作。

因此，目标应该是使他们以某种方式了解测试实际上是衡量某事“完成” 的唯一方法，从而赋予他们编写测试的内在动力。

不过，这恐怕要困难得多。您会听到很多借口，例如“我很着急，我会稍后重写/重构然后再添加测试” –当然，后续工作从未发生，因为令人惊讶的是，它们“再一样忙碌下周。

这是我会做的：

• 第一次出去……“我们将共同做这个项目。我要编写测试，而你要编写代码。请注意我如何编写测试，因为这就是我们的工作方式这就是我对你的期望。”

• 接着...“您完成了吗？太好了！首先让我们看一下推动您开发的测试。哦，没有测试？让我知道何时完成，我们将重新计划您的代码。如果您需要帮助制定测试的方法时，请告诉我，我会为您提供帮助。”

他已经在做这个了。真。他只是不写下来。不服气吗？看着他经历标准的开发周期：

• 写一段代码
• 编译它
• 跑去看看它做什么
• 编写下一段代码

步骤＃3是测试。他已经进行过测试，只是手动进行。问他这个问题：“您明天怎么知道今天的代码仍然有效？” 他会回答：“代码太少了！”

问：“下周怎么样？”

当他没有答案时，问：“您希望程序何时通知您昨天发生的更改中断了？”

这就是自动单元测试的全部内容。

作为一名初级程序员，我仍在尝试养成编写测试的习惯。显然，要养成新习惯并不容易，但是考虑到什么可以使我工作起来，我不得不对有关代码审查和辅导/结对编程的评论+1。

还可能需要强调测试的长期目的：确保昨天，今天，下周和下个月仍然有效。我之所以这么说，是因为在浏览答案时我没有提到。

在进行代码审查时（如果您决定这样做），请确保您的年轻开发人员知道这不是放下他，而是要使代码变得更好。因为那样，他的信心受到损害的可能性较小。这很重要。另一方面，知道自己知道的东西也很少。

当然，我什么都不知道。但我希望这句话有用。

编辑：[ 贾斯汀标准 ]

不要让自己失望，您必须说的几乎是正确的。

关于代码审查，您会发现，初级开发人员不仅可以在过程中学习，而且审查者也可以学习。代码审查中的每个人都将学习是否使之成为一个协作过程。

坦率地说，如果你不得不把那太多精力花在让他做一些事情，那么你可能要拿出与思想方面，他可能只是没有很好的适应了球队，并且可能需要去。现在，这并不一定意味着要解雇他……这可能意味着要在公司的其他地方找到他的技能更适合的人。但是，如果没有其他地方……您知道该怎么办。

我假设他还是一个新员工（不到1年），并且可能最近刚从学校辍学……在这种情况下，他可能不习惯公司环境中的工作方式。像这样的事情我们大多数人都可以在大学里摆脱。

如果是这种情况，我发现可以做的一件事就是进行一种“惊喜的新员工审查”。以前是否从未做过都没关系...他不会知道的。只是坐下来，告诉他您将要检查他的表现，并向他显示一些真实的数字...拿起您的普通复习纸（您确实有一个正式的复习程序吗？），并根据需要更改标题。并向他展示他的立场。如果您在一个非常正式的环境中向他展示不进行测试会对他的成绩产生不利影响，而不是仅仅““”他，那他希望会明白这一点。您必须向他展示他的行为实际上会影响他，无论是明智还是其他。

我知道，您可能不希望这样做，因为它不是官方的...但是我认为您有理由这样做，而且与开除他并雇用新人相比，这可能会便宜很多。

我本人是一名初级程序员，所以我想证明自己处于与初级开发人员相似的情况时的感受。

当我刚从uni出来时，我发现它严重地使我无法应对现实世界。是的，我知道一些JAVA基础知识和一些哲学（不要问），但是仅此而已。刚开始工作时，至少可以说有点令人生畏。让我告诉您，我大概是周围最大的牛仔之一，我会整理一些漏洞修复/算法（不加注释/测试/文档），然后将其发布出去。

我很幸运地是一种与监督下非常耐心高级程序员。对我来说幸运的是，他决定和我一起坐下来，花1-2周的时间来检查我被黑的togethor代码。他会解释我哪里出错了，C和指针的更好之处（男孩确实让我感到困惑！）。我们在大约一周的时间内编写了一个不错的类/模块。我只能说，如果高级开发人员没有花时间帮助我走正确的道路，那么我可能不会持续很长时间。

令人高兴的是，下线两年了，我希望我的一些同事甚至可以将我视为普通的程序员。

带回家点

1. 大多数大学都不擅长为现实世界做好准备
2. 配对编程确实对我有所帮助。并不是说它可以帮助所有人，但对我有用。

如果您担心的话，将它们分配给不需要“高质量稳定代码”的项目，然后让它们成为jr。开发人员失败。让他们成为“周末来”的人来修复他们的错误。多吃午饭，谈论软件开发实践（不是讲座，而是讨论）。他们将及时获得并开发最佳实践以完成分配的任务。

谁知道，他们甚至可能提出比您团队目前使用的技术更好的方法。

如果初级程序员或任何其他人没有看到测试中的价值，那么很难让他们去做……期间。

我本来会让初级程序员牺牲他们的周末来修复该错误。他的行动（或缺乏行动）不会直接影响他。同样，要表明，如果他不提高自己的测试技能，他将不会看到晋升和/或加薪。

最后，即使在您的所有帮助，鼓励和指导下，他也可能不适合您的团队，因此请让他去寻找可以得到帮助的人。

我赞同RodeoClown关于代码审查每个提交的评论。一旦完成几次，他就会养成测试东西的习惯。

我不知道您是否需要阻止这样的提交。在我的工作场所，每个人都可以自由提交所有内容，并且所有SVN提交消息（带有差异）都通过电子邮件发送给团队。

注意：如果您打算这样做，您确实想要雷鸟彩色差异插件。

我的老板或我本人（两位“高级”编码员）最终将阅读提交内容，并且如果出现诸如“您忘记添加单元测试”之类的内容，我们只需轻拂电子邮件或去与该人聊天，解释为什么他们所需的单元测试或其他。鼓励其他所有人也阅读提交，因为这是查看正在发生的事情的一种很好的方式，但是初级开发人员没有那么多评论。

您可以通过定期说出诸如“嘿，鲍勃，您看到我今天早上所做的承诺了，我发现了这个巧妙的窍门，在这里可以做任何事，阅读承诺并看到这个怎么运作！”

注意：我们有2个“高级”开发人员和3个初级开发人员。这可能无法扩展，或者您可能需要与更多开发人员进行一些调整。

1. 将代码覆盖率纳入评论范围。
2. 将“编写一个暴露漏洞的测试”作为修复漏洞的前提。
3. 需要一定级别的覆盖范围，才能检入代码。
4. 找到一本关于测试驱动开发的好书，并用它来展示测试优先如何加快开发速度。

很多心理学和有用的“指导”技术，但是，老实说，这可以归结为“明天要是还想工作就写测试”。

您可以用自己认为合适的任何条件（粗糙或柔软）使用它，这无关紧要。但是事实是，程序员付钱只是将代码拼凑起来并检入它们是不付钱的-他们得到报酬是仔细地将代码放在一起，然后将测试放在一起，然后对他们的代码进行测试，然后再将整个内容检入。（至少根据您的描述，听起来就是这样。）

因此，如果有人要拒绝做他们的工作，请向他们解释说他们明天可以待在家里，而您会雇用一个愿意做这项工作的人。

同样，如果您认为有必要，可以轻轻地进行所有这些操作，但是很多人只需要在现实世界中度过一生的艰苦时光，就可以通过向他们提供帮助来帮助他们。

祝好运。

暂时将他的工作描述更改为仅编写测试和维护测试。我听说许多公司在刚开始时都会为新手缺乏经验的人这样做。

此外，在他担任该职位时要提出一个挑战：编写将导致a）当前代码失败的测试a）满足软件要求。希望这将使他创建一些可靠而全面的测试（改善项目），并使他在重新集成到核心开发中时更好地编写测试。

编辑>充分满足软件的要求，这意味着当代码从不打算或不需要考虑该测试用例时，他不只是编写测试来故意破坏代码。

如果您的同事缺乏编写测试的经验，则可能是他或她在简单的情况下无法进行测试，这表明测试不足。这是我会尝试的方法：

• 花一些时间并与您的同事共享测试技术，例如依赖项注入，查找边缘情况等。
• 提供回答有关测试的问题。
• 对测试进行代码审查一段时间。要求您的同事审查您所做的更改，这些更改是良好测试的典范。查看他们的评论，看看他们是否真的在阅读和理解您的测试代码。
• 如果有特别适合您团队测试理念的书籍，请给他或她一个副本。如果您的代码审阅反馈或讨论参考了本书，这可能会有所帮助，以便他或她有一个可以跟进和跟进的话题。

我不会特别强调羞耻/内gui感。值得指出的是，测试是一种被广泛采用的良好实践，并且编写和维护良好的测试是出于职业上的礼貌，因此您的队友无需在工作中度过周末，但我不会为这些观点感到lab惜。

如果您真的需要“变强硬”，那就建立一个公正的制度；没有人喜欢觉得自己被挑出来了。例如，您的团队可能需要代码来维持一定水平的测试覆盖率（可以玩游戏，但至少可以自动化）；要求新代码进行测试；要求审阅者在进行代码审阅时考虑测试的质量；等等。建立该系统应该来自团队共识。如果您仔细地主持讨论，您可能会发现其他潜在原因导致您的同事的测试结果超出预期。

教他/她是导师的责任。您教他/她如何测试的程度如何。您正在和他配对编程吗？少年很可能不知道如何为xyz建立良好的测试。

作为一名初中新生，他了解许多概念。一些技巧。一些经验。但最后，所有初级人员都是有潜力的。他们使用的几乎所有功能都将有从未有过的新功能。可以肯定的是，Junior可能在课堂上为一个项目做了一个简单的State模式，打开和关闭“门”，但是从来没有在现实世界中使用过这些模式。

他/她只会和您的教学水平一样好。如果他们能够“做到这一点”，您认为他们会首先担任初级职位吗？

根据我的经验，少年被录用并承担与老年人几乎相同的责任，但是他们的薪水较低，然后在步履蹒跚时被忽略。原谅我，如果我看起来很苦，那是因为我。

@jsmorris

曾经有一位高级开发人员和“架构师”谴责我和一名测试员（这是我从大学毕业以来的第一份工作），因为他没有熬夜并在前一天晚上完成了这样“轻松”的任务。我们整天都呆在那儿，并称它在晚上7点退出。我从那天中午11点开始就一直在rash不休，那天我一直在困扰我们团队的每个成员至少两次。

我回应并抄送了团队：“一个月以来，我一直对您感到失望。我从未从团队那里得到帮助。如果您需要我，我会在马路对面的咖啡店里。我抱歉，我无法调试几乎所有东西都依赖的12参数800行方法。”

在咖啡店里冷却一个小时后，我回到办公室，抓着我的垃圾，离开了。几天后，他们打电话给我，问我是否要进来，我说可以，但是我接受了采访，也许是明天。

“那你辞职了吗？”

在您的源存储库上：在每次提交之前使用钩子（例如，针对SVN的预提交钩子）

在该挂钩中，检查每种方法是否至少存在一个用例。使用单元测试组织的约定，您可以通过预提交钩子轻松实施该约定。

在集成服务器上，编译所有内容并使用测试覆盖率工具定期检查测试覆盖率。如果代码的测试覆盖率不是100％，则阻止开发人员进行任何提交。他应该向您发送涵盖100％代码的测试用例。

只有自动检查才能在项目上很好地扩展。您无法手动检查所有内容。

开发人员应该有办法检查他的测试用例是否覆盖了100％的代码。这样，如果他不提交100％经过测试的代码，那是他自己的错，而不是“糟糕，抱歉，我忘记了”的错。

切记：人们永远不会做您期望的事情，他们总是会做您检查的事情。

首先，就像这里的大多数受访者所指出的那样，如果这个家伙没有看到测试的价值，那么您就无能为力了，您已经指出您不能解雇这个家伙。但是，失败不是这里的选择，那么您可以做的几件事呢？做什么？

如果您的组织足够大，可以容纳6个以上的开发人员，那么我强烈建议您建立一个质量保证部门（即使只是一个人）。理想情况下，您应该具有1个测试人员与3-5个开发人员的比率。关于程序员的事情是……他们是程序员，而不是测试人员。我还没有采访过已经正式教授适当的质量检查技术的程序员。

大多数组织都存在将测试角色分配给新员工的致命缺陷，因为该人员对您的代码的接触程度最低—理想情况下，高级开发人员应转为质量检查角色，因为他们具有代码方面的经验，并且（希望如此）已经开发出第六种感觉，用于可能出现的代码异味和故障点。

此外，犯了错误的程序员可能不会发现缺陷，因为它通常不是语法错误（在编译中会被拾取），而是逻辑错误-当他们编写该错误时，相同的逻辑正在起作用在编写代码时进行测试。没有开发该代码的人来测试该代码-他们发现的错误比其他任何人都少。

在您的情况下，如果您负担得起重新定向的工作量，请让这个新手成为质量检查小组的第一位成员。让他阅读“现实世界中的软件测试：改进流程”，因为他显然需要接受一些新角色的培训。如果他不喜欢它，他会退出，您的问题仍然可以解决。

较不那么复仇的方法是让这个人做他们擅长的事情（我假设这个人被录用是因为他们实际上胜任这份工作的编程部分），并雇用一两个测试员来进行测试（大学生通常有实习或“合作”条件，会喜欢这种机会，而且很便宜）

旁注：最终，您将希望质量检查团队向质量检查主管报告，或者至少不向软件开发经理报告，因为让质量检查团队向经理报告是主要目的是完成产品，这是冲突的。利益。

如果您的组织规模小于6，或者您无法摆脱创建新团队的麻烦，建议您使用配对编程（PP）。我不是所有极限编程技术的总转换者，但我绝对是配对编程的信奉者。但是，成对的编程团队的两个成员都必须专心致志，否则根本行不通。他们必须遵循两个规则：检查员必须完全了解屏幕上正在编码的内容，或者必须请编码员对其进行解释；编码人员只能编码他可以解释的内容-不会容忍“您会看到”或“信任我”或挥手致意。

我只建议您的团队有能力去做PP，因为像测试一样，如果他们感到不自在，就不会有多少欢呼或威胁会说服几个内向的内向型人一起工作。但是，我发现在选择编写详细的功能规范，进行代码审查与配对编程之间，PP通常会胜出。

如果PP不适合您，那么TDD是您最好的选择，但前提是按字面意义进行。测试驱动开发意味着您首先要编写测试，运行测试以证明它们确实确实失败了，然后编写最简单的代码使其生效。现在需要权衡的是，您（应该）具有数千个测试的集合，这些测试也是代码，并且与包含错误的生产代码一样可能。老实说，我不是TDD的忠实拥护者，主要是因为这个原因，但是它对许多愿意编写测试脚本而不是测试用例文档的开发人员有效-有些测试总比没有好。将TDD与PP​​结合使用，可以更好地进行测试覆盖，并减少脚本中的错误。

如果所有其他方法都失败了，请让程序员等效使用一个发誓的罐子-每次程序员破坏构建时，他们都必须将20美元，50美元，100美元（无论对您的工作人员造成多少痛苦）放入一个您喜欢的罐子中（注册！）慈善。直到他们付清为止，才让他们:)

除了开玩笑，让程序员编写测试的最好方法就是不要让他编程。如果需要程序员，请雇用一名程序员。如果要测试，请雇用一名测试员。12年前，我以初级程序员的身份开始从事测试工作，后来这变成了我的职业道路，我一无所获。一个扎实的质量保证部门，得到适当的培养，并拥有改进软件的权力和授权，与开发人员最初编写该软件一样有价值。

这可能有点无心，但是您描述情况的方式听起来像是您需要解雇这个人。或者至少要说清楚一点：拒绝遵循房屋开发实践（包括编写测试）并检入其他人必须清理的错误代码最终会被解雇。

初级工程师/程序员无需花费大量时间来设计和执行测试脚本的主要原因是，由于大多数CS认证都没有太多要求，因此大学课程中还涵盖了其他工程领域，例如设计模式。

以我的经验，使初级专业人员习惯的最好方法是明确地将其纳入流程。也就是说，当估计迭代所需的时间时，设计，编写和/或执行案例的时间应纳入此时间估计中。

最后，对测试脚本设计的审查应该是设计审查的一部分，而实际代码应在代码审查中进行审查。这使程序员有责任对他/她编写的每一行代码进行正确的测试，而高级工程师和同伴则有责任对所编写的代码和测试提供反馈和指导。

根据您的评论“展示设计变得更简单”，我假设你们练习TDD。在事实结束后进行代码审查将无法正常工作。关于TDD的全部内容是它是设计而不是测试原理。如果他没有将测试作为设计的一部分来编写，那么事后编写测试将不会从中获得很多收益，尤其是对于初级开发人员而言。他最终会丢失大量的极端情况，并且他的代码仍然很糟糕。

最好的办法是有一个非常耐心的高级开发人员坐在他旁边，并进行一些配对编程。一直坚持下去，直到他学习为止。还是没有学到，在这种情况下，您需要将他重新分配给他更适合的任务，因为这只会使您真正的开发人员受挫。

并非每个人都有相同水平的才能和/或动力。开发团队，甚至是敏捷团队，都由“ A团队”中的人员和“ B团队”中的人员组成。A-Team成员负责设计解决方案，编写所有重要的生产代码并与企业主进行交流-所有这些工作都需要在框外进行思考。B团队负责处理诸如配置管理，编写脚本，修复me脚的错误以及进行维护工作-所有这些工作都有严格的过程，对失败造成的影响很小。