如何让初级程序员编写testing？
我们有一个初级程序员，根本不写足够的testing。
我每隔两个小时就要唠叨一句，“你有写testing吗？”
我们已经尝试过：
- 表明devise变得更简单
- 显示它可以防止缺陷
- 把自己的东西说成只有糟糕的程序员才会这样做
- 这个周末，2名团队成员不得不开始工作，因为他的代码有一个NULL引用，他没有testing它
我的工作需要最高质量的稳定代码，通常每个人都能得到它，而且不需要通过testing。 我们知道我们可以让他编写testing，但我们都知道有用的testing是在你写入testing时写的。
你知道更多的动机吗？
这是最难的事情之一。 让你的人得到它 。
有时候帮助初级程序员“得到它”并从老年人那里学习正确技术的最好方法之一就是做一些结对编程。
试试这个：在即将到来的项目上，把小辈和自己或者其他高级程序员配对。 他们应该一起工作，轮stream“驾驶”（键盘上打字的人）和“指导”（看着司机的肩膀，指出build议，错误等等）。 这可能看起来像是浪费资源，但你会发现：
- 这些人一起可以产生足够多的代码快速和更高的质量。
- 如果你的小伙子学得足够了，可以和一个正确的道路上的高级人员“合作”（例如，“好吧，现在我们继续之前，让我们来testing一下这个function吧。”）这将是非常值得的资源承诺。
也许也可以让你们小组里有人给出Kate Rhodes的unit testing101演示，如果交付得好的话，我认为它是让人们对testing感到兴奋的好方法。
你可以做的另一件事是让你的小开发者练习保龄球游戏卡塔 ，这将帮助他们学习testing驱动开发。 这是在Java中，但可以很容易地适应任何语言。
每次提交前都要进行代码审查（即使是1分钟“我已经更改了这个variables名称”），并且作为代码审查的一部分，请检查任何unit testing。
在testing到位之前，不要签署提交。
（另外 – 如果他的工作没有经过testing – 为什么在生产环境中是第一位的？如果没有testing，不要让它进入，那么你就不必在周末工作）
对于我自己，我已经开始坚持认为，每一个我发现和修复的bug都可以用一个testing来expression：
- “唔，那是不对的…”
- 发现可能的问题
- 写一个testing，显示代码失败
- 解决问题
- 显示新的代码通过
- 如果原始问题仍然存在，请循环
我试图做这个，即使是在把东西撞出来的时候，我也是在同一时间完成的，只有部分testing套件已经到位了。
（我不住在商业编程环境中，而且经常是唯一一个编写特定项目的编码人员。）
想象一下，我是一个模拟程序员，名叫… Marco。 想象一下，我不久前就已经gradle了，从未真正写过testing。 想象一下，我在一家没有真正执行或要求这样做的公司工作。 好？ 好！ 现在想象一下，公司正在转向使用testing，他们正试图让我内联这一点。 对于目前提到的项目，我会作出些许反应，好像我没有对此做过任何研究。
让我们从创build者开始：
表明devise变得更简单。
如何写得更多，使事情更简单。 我现在必须密切注意获取更多的案例等。如果你问我，这会变得更加复杂。 给我一些细节。
显示它可以防止缺陷。
我知道。 这就是为什么他们被称为testing。 我的代码是好的，我检查了它的问题，所以我没有看到那些testing将帮助。
把自己的东西说成只有糟糕的程序员才会这样做。
哦，所以你认为我是一个糟糕的程序员，只是因为我没有做太多的testing。 我受到了侮辱，并对你感到非常恼火。 我宁愿有比说法更多的帮助和支持。
@ 贾斯汀标准 ：在新的开始阶段，把初学者与自己或其他高级程序员搭档。
哦，这是非常重要的，资源将花费在确保我看到事情如何完成，并有一些帮助我如何做事情。 这是有帮助的，我可能会开始做更多。
@ 贾斯汀标准 ：阅读Kate Rhodes的unit testing101演示。
啊，这是一个有趣的介绍，这让我想到了testing。 它强调了我应该考虑的一些观点，这可能会影响我的观点。
我希望看到更多引人入胜的文章和其他工具来帮助我认识到这是正确的做事方式。
@ Dominic Cooney ：花点时间和分享testing技巧。
啊，这有助于我理解我对技术的期望，并且把更多的东西放在我的知识背后，以便我再次使用。
@ Dominic Cooney ：回答问题，例子和书籍。
有一个点人（人）回答问题是有帮助的，这可能会使我更有可能尝试。 很好的例子是很好的，它给了我一些东西的目标，并寻求参考。 与此直接相关的书籍是很有参考价值的。
@ 亚当Hayle ：惊喜回顾。
说什么，你弹了一个我完全没有准备好的东西。 我感到不舒服，但会尽我所能。 现在我会害怕和轻蔑地再次提起这个问题，谢谢。 然而，恐慌策略可能已经奏效，但确实有成本。 但是，如果没有其他的工作，这可能只是需要的推动。
@ Rytmis ：项目只有在有testing用例的情况下才会考虑。
哦，有趣。 我看到我现在真的必须这样做，否则我没有完成任何事情。 这是有道理的。
@ jmorris ：摆脱/牺牲。
眩光，眩光，眩光 – 我有机会学习，在支持和帮助下，我可以成为团队中一个非常重要的function部分。 这是我现在的一个障碍，但不会太久。 但是，如果我不明白，我明白我会去的。 我想我会得到它。
最后，我的团队的支持在这一切中发挥了很大的作用。 有一个人花时间来帮助，并让我开始养成良好的习惯总是受欢迎的。 然后，有一个良好的支持网将是伟大的。 人们总是会很高兴有人来过几次，然后去看一些代码，看看事情是如何stream逝的，而不是在回顾本身，而更像是一次友好的访问。
推理，准备，教学，跟进，支持。
我注意到很多程序员在合理的层面上看到了testing的价值。 如果你听说过“是的，我知道我应该testing这个，但我真的需要很快完成”，那么你明白我的意思了。 但是，在情感层面上，他们认为只有在编写真实代码时才能完成某件事情。
那么，目标应该是让他们明白，testing实际上是衡量什么时候“完成”的唯一方法，从而给他们编写testing的内在动机。
不过，恐怕这比应该要困难得多。 你会听到很多借口：“我真的很急，我会稍后重写/重构，然后添加testing” – 当然，后续从未发生，因为，令人惊讶的是，他们下周的工作一样繁忙 。
这是我会做的：
-
第一次……“我们要共同完成这个项目，我要写testing，然后编写代码，注意我如何编写testing，因为我们是这样做的在这附近，这就是我所期望的。“
-
在这之后…“你完成了吗？好的！首先让我们来看看那些正在推动你的开发的testing。哦，没有testing？让我知道什么时候完成了，我们将重新计划你的代码。需要帮助来制定testing让我知道，我会帮助你。
作为一名初级程序员，我仍然在努力养成编写testing的习惯。 显然，挑起新的习惯并不容易，但是想一下为什么这样做会对我有用，我必须对代码审查和辅导/结对编程的评论+1。
也许值得强调testing的长期目的：确保昨天的工作在今天，下个星期和下个月仍然有效。 我只是说，因为在撇开答案，我没有看到提及。
在做代码评审时（如果你决定这样做的话），确保你的年轻开发人员知道这不是把他放下，而是让代码更好。 因为这样他的信心不太可能受到损害。 这很重要。 另一方面，知道你知道多less。
当然，我什么都不知道。 但是，我希望这些话是有用的。
编辑：[ 贾斯汀标准 ]
不要放下自己，你必须说的是非常正确的。
关于代码评论的观点：你会发现，不仅初级开发者会在这个过程中学习，评审者也会这样做。 代码审查中的每个人都会了解您是否使其成为一个协作过程。
他已经这样做了 真。 他只是不写下来。 不服气？ 看他经历标准的开发周期：
- 写一段代码
- 编译它
- 运行看看它是什么
- 写下一段代码
步骤＃3是testing。 他已经做了testing，他只是手动做。 问他这个问题：“你明天怎么知道今天的代码仍然有效？ 他会回答：“这是less量的代码！”
问：“下周怎么样？”
当他没有得到答案的时候，问：“如果一个变化破坏了昨天发生的事情，你希望你的程序告诉你什么？”
这就是自动unit testing的全部内容。
坦率地说，如果你不得不花费很大的精力来让他做一些事情，那么你可能不得不认为他可能不适合球队，可能需要去。 现在，这不一定意味着解雇他……这可能意味着在公司的其他地方find他的技能更适合他的地方。 但是，如果没有其他地方…你知道该怎么做。
我假设他也是一个相当新的雇员（<1年），可能最近失去了学习……在这种情况下，他可能不习惯在公司背景下工作。 像我们大多数人可以在大学里得到的东西。
如果是这样的话，我发现的一件事就是有一种“令人惊讶的新雇佣评论”。 没关系，如果你以前从来没有做过……他不会知道的。 只要坐下来，告诉他你要去看他的performance，并给他一些真实的数字…把你的正常的审查表（你有一个正式的审查过程是正确的？），并改变标题，如果你想这样看起来正式向他展示他的立场。 如果你在一个非常正式的环境中performance出他没有进行testing会对他的performance评分产生负面影响，而不是只是“唠叨”他，他会希望得到这个观点。 你必须告诉他，无论是明智的还是其他的，他的行为都会影响他。
我知道，你可能想避免这样做，因为它不是官方的……但我认为你有理由这样做，这可能比把他解雇和招募新人要便宜很多。
作为一名初级程序员，我认为Id发现自己处于与初级开发人员类似的状态时，会发生什么情况。
当我刚从联合国出来的时候，发现它已经没有装备我去处理现实世界了。 是的，我知道一些JAVA的基础和一些哲学（不要问），但是这是关于它。 当我第一次得到我的工作时，至less可以说有点令人望而生畏。 让我告诉你，我可能是周围最大的牛仔之一，我会一起hack一个小bug修复/algorithm，没有评论/testing/文件，并将其发送出去。
我很幸运，在一个非常耐心的高级程序员的监督下。 幸运的是，他决定和我一起坐下来，花上1-2周的时间，浏览一下我的黑客代码。 他会解释我出错的地方，c和指针的更精细的点（男孩让我困惑！）。 我们在一个星期内写了一个相当好的课程/模块。 我只能说，如果高级开发人员没有时间帮助我走正确的道路，我可能不会持续很长时间。
令人高兴的是，2年后，我希望我的一些同事甚至可以认为我是一个普通的程序员。
带回家的积分
- 大多数大学在为现实世界的学生做准备方面非常糟糕
- 配对编程确实帮助了我。 这并不是说它会帮助所有人，但它为我工作。
将它们分配给不需要“最高质量稳定代码”的项目，如果这是您的担心，让jr。 开发商失败。 让他们成为“周末进来”来修复他们的错误。 吃午饭，谈论软件开发实践（不是讲座，而是讨论）。 及时他们将获得和发展的最佳做法来完成他们分配的任务。
谁知道，他们甚至可以拿出比你的团队目前使用的技术更好的东西。
我第二次RodeoClown关于代码审查每个提交的评论。 一旦他完成了这个工作，他有几次会养成testing东西的习惯。
我不知道你是否需要像这样提交。 在我的工作场所，每个人都有自由的承诺，所有的SVN提交信息（包括差异）通过电子邮件发送给团队。
注意：如果你打算这么做的话，你真的想要thunderbird color-diffs插件 。
我的老板或我自己（2位“高级”编码员）最终会对提交内容进行阅读，如果有什么东西像“你忘了添加unit testing”那么我们只是轻弹一下电子邮件或去和那个人聊天，需要unit testing或其他。 其他人都被鼓励去阅读这个提交，因为这是一个很好的方法来看看发生了什么事情，但是初级开发人员不会这么评论。
你可以通过定期说出“嘿，鲍勃，你今天早上看到我做了什么，我发现了这个巧妙的技巧，你可以做任何事情，阅读提交并看到怎么运行的！”
注：我们有2个“高级”开发者和3个初级开发者。 这可能无法扩展，或者您可能需要与更多开发人员稍微调整一下过程。
- 使代码覆盖部分的评论。
- 让“写一个暴露bug的testing”是修复bug的先决条件。
- 在可以检入代码之前，需要一定的覆盖率。
- 找一本关于testing驱动开发的好书，并用它来展示如何以testing为先，加速开发。
很多心理学和有益的“指导”技巧，但实际上，这只是归结为“如果明天还想继续工作，就写testing”。
你可以用任何你认为合适的，苛刻的或软性的术语来处理，这并不重要。 但事实上，程序员不会付钱把代码放在一起检查，而是把代码仔细地放在一起，然后把testing放在一起，然后testing他们的代码，然后检查整个事情（至less这就是你的描述所听到的。）
因此，如果有人拒绝做他们的工作，向他们解释他们可以待在家里，明天，你会雇用一个能够完成工作的人。
如果你认为这是必要的，那么你可以轻轻松松地做所有这些事情，但是很多人只需要在现实世界中生活的一大步，你会帮他们一个忙。
祝你好运。
改变他的工作描述一段时间，只写testing和维护testing。 我听说很多公司在刚开始的时候为一些没有经验的新人做了这些工作。
另外，在他担任这个职位时发出一个挑战：写testing将会a）当前代码失败a）满足软件的要求。 希望这会使他创造一些坚实而彻底的testing（改进项目），并使他在重新整合到核心开发中时为testing做好准备。
编辑>满足软件的要求，这意味着他不只是编写testing，故意破坏代码时，代码从来没有打算或需要考虑testing用例。
如果初级程序员或任何人没有看到testing的价值，那么很难让他们这样做。
我会让这个初级程序员牺牲他们的周末来修复这个bug。 他的行为（或缺乏）并不直接影响他。 另外，显而易见，如果他没有提高testing技能，他就不会看到进步和/或加薪。
最后，即使在你所有的帮助，鼓励，指导下，他也可能不适合你的队伍，所以让他去找一个能得到它的人。
如果你的同事缺乏写作testing的经验，可能他或她在简单的情况下就难以testing，这就performance为testing不足。 这是我会尝试的：
- 花一些时间，与同事共享testing技术，如dependency injection，寻找边缘案例等等。
- 提供回答关于testing的问题。
- 做一段时间的testing代码评论。 要求你的同事回顾一下你的好的testing的变化。 看看他们的评论，看他们是否真的在阅读和理解你的testing代码。
- 如果有些书与您团队的testing理念特别吻合，可以给他或她一份副本。 如果你的代码审查反馈或讨论引用这本书，这可能会有所帮助，所以他或她有一个线程可以拿起并遵循。
我不会特别强调羞耻/罪恶因素。 值得指出的是，testing是一个被广泛采用，良好的做法，编写和保持良好的testing是一个专业的礼貌，所以你的队友不需要在周末工作，但我不会将这些点。
如果你真的需要“变得强硬”，那么build立一个公正的制度; 没有人喜欢觉得他们被挑出来。 例如，您的团队可能需要代码来维护一定水平的testing覆盖率（能够进行游戏，但至less能够自动化）; 需要新的代码进行testing; 要求评审人员在进行代码评审时考虑testing的质量; 等等。 制定这个制度应该来自团队的共识。 如果你仔细讨论，你可能会发现其他潜在的原因，你的同事的testing不是你所期望的。
教导他/她是他的导师的责任。 你如何教他/她如何testing。 你和他一起编程吗？ 这个小辈很可能不知道如何为xyzbuild立一个好的testing。
作为一名初中生，他知道很多概念。 一些技巧。 一些经验。 但最终，所有的初中都是有潜力的。 几乎他们所做的每一个function，都会有一些他们以前从未做过的新function。 当然，less年class可能在课堂上为一个项目做了一个简单的国家模式，打开和closures“门”，但从来没有真正的模式应用。
他/她只会和你的教导一样好。 如果他们能够“得到它”，你认为他们是否会在初级阶段？
根据我的经验，小辈被聘用，几乎和老年人一样承担责任，但他们开始动摇时，却less付了钱，然后被忽略了。 原谅我，如果我看起来苦涩，这是因为我。
@ jsmorris
我曾经让高级开发人员和“架构师”在电子邮件中抨击我和一名testing人员（这是我的第一份工作），不迟到，并在前一天晚上完成这样一个“简单”的任务。 我们一整天都在这里，晚上7点就打电话过去了，那天早上11点以前，我一直在打嗝，并且至less两次把我们团队的每个成员都打了一遍。
我回答说：“我已经对你失望了一个月，我从来没有得到团队的帮助，如果你需要我，我会在马路对面的咖啡店里。对不起，我无法debugging12参数，800线方法，几乎所有的东西都依赖于。“
在咖啡厅冷却了一个小时后，我回到办公室，抓住我的废话，离开了。 几天后，他们打电话问我是否进来，我说我会但是我可能会面试，也许明天。
“那么你的戒烟呢？”
在您的源代码库上：在每次提交之前使用钩子（例如SVN的预提交钩子）
在该钩子中，检查每个方法是否存在至less一个用例。 使用unit testing组织的惯例，您可以通过预先提交钩子轻松执行。
在集成服务器上编译所有内容，并使用testing覆盖率工具正规地检查testing覆盖率。 如果代码的testing覆盖率不是100％，则阻止开发者的任何提交。 他应该给你发送覆盖100％代码的testing用例。
只有自动检查可以在一个项目上很好地扩展。 你不能手工检查所有的东西。
开发人员应该有一个检查他的testing用例是否覆盖全部代码的意思。 这样，如果他没有100％的testing代码，这是他自己的错，不是一个“哎呀，对不起，我忘了”的错。
记住：人们从来没有做你期望的事情，他们总是做你所检查的。
这可能有点无情，但你描述的情况听起来像你需要解雇这个人。 或者至less说清楚：拒绝遵循房屋开发实践（包括编写testing） 和检查其他人必须清理的错误代码最终会被解雇。
初级工程师/程序员不需要花费大量时间来devise和执行testing脚本的主要原因是因为大多数CSauthentication并不需要这么做，因此其他工程领域在大学课程（如devise模式）中得到进一步的覆盖。
根据我的经验，让初级专业人员养成习惯的最好办法是明确地将其纳入进程。 也就是说，在估算迭代所需的时间时，devise，编写和/或执行案例的时间应该被纳入到这个时间估计中。
最后，审查testing脚本devise应该是devise评审的一部分，实际的代码应该在代码评审中进行评审。 这使程序员负责对他/她编写的每一行代码进行适当的testing，而高级工程师和同行则负责对代码和testing提供反馈和指导。
首先，像大多数受访者所指出的那样，如果这个人没有看到testing的价值，那么对此你就没有太多的办法，你已经指出你不能解雇这个人。 然而，失败在这里不是一个select，所以你可以做的几件事情呢？
如果你的组织规模足够大，有6个以上的开发者，我强烈build议有一个质量保证部门（即使只有一个人开始）。 理想情况下，你应该有一个testing者比3-5的开发者。 关于程序员的事情是…他们是程序员，而不是testing人员。 我还没有采访一位已经正式教授适当的QA技术的程序员。
大多数组织都将testingangular色分配给新招聘人员，这种人员对代码的暴露程度最低 – 理想情况下，高级开发人员应该转移到质量保证angular色，因为他们有代码方面的经验，并且（希望）已经开发出了可以出现的代码味道和失败点的第六感。
此外，犯了错误的程序员可能不会发现缺陷，因为它通常不是一个语法错误（在编译时会被拾取），而是一个逻辑错误 – 而且在编写testing，当他们写代码。 没有开发代码testing代码的人 – 他们会发现比其他人更less的错误。
在你的情况下，如果你能负担得起重新定向的工作，让这个新人成为你的QA团队的第一个成员。 让他阅读“现实世界中的软件testing：改进过程”，因为他明显需要一些新的angular色培训。 如果他不喜欢，他会放弃，你的问题仍然解决。
稍微less一些报复的方法是让这个人做他们擅长的事情（我假设这个人被聘用，因为他们实际上是在工作的编程部分胜任），聘请一两个testing人员来做testing（大学生往往有实习或“合作社”条款，会喜欢这种曝光，价格便宜）
注意：最终，您需要QA团队向QA总监报告，或者至less不要向软件开发人员经理报告，因为让QA团队向经理报告主要目标是完成产品是一个冲突利益。
如果你的组织小于6，或者你不能脱身创build一个新的团队，我推荐配对编程（PP）。 我并不是所有极限编程技术的完全转换，但我绝对是编程配对的信徒。 然而，配对的编程小组的两名成员都必须专心致志，否则根本无法工作。 他们必须遵循两条规则：检查员必须完全理解屏幕上正在编码的内容，或者要求编码员解释; 编码者只能编码他能解释的东西 – 不会“你会看到”或“相信我”或挥手是可以容忍的。
我只推荐PP，如果你的团队有能力的话，因为像testing一样，如果他们觉得不舒服，那么没有任何的欢呼或者威胁就会说服一些自负的内向者一起工作。 然而，我发现在编写详细function规格的select和做代码评论与配对编程之间，PP通常是胜出的。
如果PP不适合你，那么TDD是你最好的select，但只有从字面上理解。 testing驱动开发意味着你写testing第一，运行testing，以certificate他们实际上失败，然后写最简单的代码，使其工作。 权衡现在你（应该）有成千上万个testing的集合，这也是代码，和生产代码一样可能包含错误。 我诚实地说，我不是TDD的忠实粉丝，主要是因为这个原因，但是对于那些宁愿写testing脚本的开发者来说，它比testing用例文件更有效 – 一些testing比没有testing更好。 将TDD与PP结合起来，可以提高testing覆盖率，减less脚本中的错误。
如果一切都失败了，请让程序员等同于一个发誓的jar – 每次程序员打破构build，他们必须把20美元，50美元，100美元（无论是对你的员工中等痛苦）放入一个jar子，注册！）慈善。 直到他们付出，顺他们:)
所有的开玩笑，让你的程序员编写testing的最好方法是不要让他编程。 如果你想要一个程序员，聘请一个程序员 – 如果你想testing，聘请一个testing人员。 我从12年前开始做一个初级程序员做testing，并且变成了我的职业道路，我什么都不会做。 一个坚实的QA部门得到了适当的培养，赋予了改进软件的权力和授权，与开发软件的开发人员一样有价值。
根据你的评论，“显示devise变得更简单”我假设你们练习TDD。 事后做代码审查是不行的。 关于TDD的全部内容是它是一种devise而不是testing哲学。 如果他没有将testing作为devise的一部分来编写，那么在事后 – 特别是初级开发者，你不会从写testing中获得很多好处。 他最终会错过很多的angular落案例，他的代码仍然很糟糕。
最好的办法是让一个非常耐心的高级开发人员和他坐在一起，做一些配对编程。 直到他学习。 或者没有学习，在这种情况下，你需要重新分配一个他更适合的任务，因为你最终会挫败你真正的开发人员。
不是每个人都有相同水平的人才和/或动机。 开发团队，甚至是敏捷团队，都是由“A团队”的人员和“B团队”的人员组成的。 团队成员是构build解决scheme的人，编写所有不重要的生产代码，并与企业主进行交stream – 所有需要思考的工作。 B团队负责处理configurationpipe理，编写脚本，修复跛脚错误以及进行维护工作等所有严格程序的工作，这些工作对故障影响很小。
