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

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

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

我们知道更多动机吗？

解决方案

回答

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

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

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

回答

坦白说，如果我们需要付出很多努力才能让他做某事，那么我们可能不得不接受这样的想法，即他可能不适合团队，可能需要离开。现在，这并不一定意味着要解雇他……这可能意味着在公司的其他地方找到他的技能更适合的人。但是，如果没有其他地方……我们知道该怎么办。

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

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

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

回答

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

那么，目标应该是使他们以某种方式理解测试实际上是衡量何时"完成"某件事的唯一方法，从而赋予他们编写测试的内在动力。

不过，这恐怕要困难得多。我们会听到很多借口，例如"我实在很着急，我会稍后重写/重构然后添加测试"-当然，后续活动永远不会发生，因为令人惊讶的是，它们下个星期再忙。

回答

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

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

尝试以下操作：在一个即将到来的项目中，将初级人员与我们自己或者另一个高级程序员配对。他们应该一起工作，轮流"驾驶"(在他们的键盘上打字)和"教练"(在驾驶员的肩膀上望着，并指出他们提出的建议，错误等)。似乎浪费资源，但是我们会发现：

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

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

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

回答

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

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

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

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

回答

这是我会做的：

• 第一次出去……"我们将共同做这个项目。我要编写测试，而你要编写代码。请注意我如何编写测试，因为这就是我们的工作方式在这附近，这就是我对你的期望。"
• 之后..."我们完成了吗？太好了！首先让我们看一下推动开发的测试。哦，没有测试？让我知道何时完成，我们将重新计划代码。需要帮助制定测试的方法时，请告诉我，我们会为我们提供帮助。"

回答

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

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

(另外，如果未测试他的作品，为什么首先要在生产版本中使用它？如果未测试，则不要放进去，那么我们就不必周末工作)

回答

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

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

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

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

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

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

回答

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

让我们从创建者开始：

Showing that the design becomes simpler.

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

Showing it prevents defects.

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

Making it an ego thing saying only bad programmers don't.

哦，所以我们认为我是一个糟糕的程序员，只是因为我没有做太多的二手测试。我受到了侮辱，对你很生气。我宁愿有帮助，也不愿有俗语。

@Justin Standard: On start of new propect pair the junior guy up with yourself or another senior programmer.

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

@Justin Standard: Read Unit Testing 101 presentation by Kate Rhodes.

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

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

@Dominic Cooney: Spend some time and share testing techniques.

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

@Dominic Cooney: Answer questions, examples and books.

有一个要点的人(人)来回答问题会有所帮助，这可能会使我更有可能尝试。好的例子是很棒的，它给了我一些目标和参考。直接与此相关的书籍是很好的参考。

@Adam Hayle: Surprise Review.

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

@Rytmis: Items are only considered done when they have test cases.

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

@jmorris: Get Rid / Sacrifice.

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

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

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

回答

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

作为初中新生，他了解许多概念。一些技巧。一些经验。但最后，所有初级人员都是有潜力的。他们使用的几乎所有功能都将有从未有过的新功能。当然，初级人员可能在课堂上为一个项目完成了一个简单的状态模式，即打开和关闭"门"，但从未在模式中进行过实际的应用。

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

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

回答

@jsmorris

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

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

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

"那你辞职了吗？"

回答

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

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

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

回答

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

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

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

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

Edit: [Justin Standard]
  
  Don't put yourself down, what you have to say is pretty much right on.
  
  On your point about code reviews: what you will find is that not only will the junior dev learn in the process, but so will the reviewers.  Everyone in a code review learns if you make it a collaborative process.

回答

作为我自己的初级程序员，我认为我应该揭示自己与初级开发人员处于类似情况时的感受。

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

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

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

带回家点

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

回答

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

回答

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

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

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

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

回答

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

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

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

回答

• 使代码覆盖率成为评论的一部分。
• 将"编写一个暴露漏洞的测试"作为修复漏洞的准备工作。
• 需要一定级别的覆盖范围，才能检入代码。
• 找到一本关于测试驱动开发的好书，并用它来展示测试优先如何加快开发速度。

回答

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

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

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

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

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

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

回答

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

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

回答

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

我们可以用自己认为合适的任何条件(粗糙或者柔软)使用它，这无关紧要。但是事实是，程序员付钱只是把代码放在一起并检入是不付钱的-他们付钱是仔细地放在一起编写代码，然后放进测试，然后测试他们的代码，然后再把整个东西都放进去。根据描述，听起来像什么。)

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

同样，如果我们认为有必要，则可以轻柔地完成所有这些操作，但是很多人只需要在现实世界中付出艰辛的一生，就可以通过向他们提供帮助来帮助他们。

祝你好运。

回答

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

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

大多数组织都存在致命的缺陷，即将测试角色分配给新员工，即我们对代码的接触程度最低的人-理想情况下，高级开发人员应转为质量检查角色，因为他们具有代码方面的经验，并且(希望)对代码气味和可能出现的故障点有了第六种认识。

此外，犯错误的程序员可能不会发现缺陷，因为它通常不是语法错误(在编译中会被拾取)，而是逻辑错误-编写测试时，相同的逻辑正在起作用就像他们编写代码时一样。没有开发该代码的代码测试人员-他们发现的错误将少于其他任何人。

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

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

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

如果组织规模小于6，或者我们无法摆脱组建新团队的麻烦，建议我们使用配对编程(PP)。我并不是所有极限编程技术的总转换者，但我绝对是配对编程的信奉者。但是，成对的编程团队的两个成员都必须专心致志，否则根本行不通。他们必须遵循两个规则：检查员必须完全理解屏幕上正在编码的内容，或者他必须要求编码器对其进行解释；编码人员只能编码他可以解释的内容-不会出现"我们会看到"或者"信任我"的现象，否则将不被允许挥手。

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

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

如果所有其他方法均失败，请让程序员等价于一个发誓的罐子-每次程序员破坏构建时，他们都必须将20美元，50美元，100美元(无论对工作人员造成的痛苦程度)放入我们喜欢的罐子(已注册) ！) 慈善机构。直到他们付清为止，才让他们:)

除了开玩笑，让程序员编写测试的最好方法就是不要让他编程。如果我们想要一名程序员，请雇用一名程序员-如果我们想要测试，请雇用一名测试员。 12年前，我以初级程序员的身份开始从事测试工作，后来这变成了我的职业道路，我不会为了任何东西而将其交易。一个扎实的质量保证部门，经过适当的培训，并拥有改进软件的能力和授权，与开发人员最初编写该软件一样有价值。

回答

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

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

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

问："下周怎么样？"

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

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

回答

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

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

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