如何让初级程序员编写测试?

时间:2008-08-10 17:34:47

标签: unit-testing testing

我们有一名初级程序员,根本没有写足够的测试 我必须每两个小时唠叨一次,“你有没有写过考试?” 我们试过了:

  • 表明设计变得更简单
  • 显示它可以防止出现缺陷
  • 让它成为一个自负的事情,只说坏程序员不
  • 本周末,2名团队成员不得不来上班,因为他的代码有一个NULL参考,而且他没有测试它

我的工作需要高质量的稳定代码,通常每个人都“得到它”,并且不需要推动测试。我们知道我们可以让他编写测试,但我们都知道有用的测试是你进入测试时所写的。

你知道更多的动机吗?

24 个答案:

答案 0 :(得分:122)

这是最困难的事情之一。让您的员工获取

有时,帮助初级程序员“获得它”并从老年人那里学习正确技术的最好方法之一就是做一些结对编程。

试试这个:在即将开展的项目中,将初级男生与自己或其他高级程序员配对。他们应该一起工作,轮流“开车”(在他们的键盘上打字)和“教练”(看着司机的肩膀并指出他们去的建议,错误等)。这似乎是浪费资源,但你会发现:

  1. 这些人一起可以快速,高质量地生成代码。
  2. 如果你的小伙子学会了足够的知识,可以让一个高级家伙指导他沿着正确的道路前进(例如,“好的,现在我们继续之前,让我们在测试时写下这个功能。”)这将是非常值得的你承诺的资源。
  3. 也许你的小组中有人会给Kate Rhodes提供Unit Testing 101演示文稿,我认为如果交付顺利,这是让人们对测试感到兴奋的好方法。

    你可以做的另一件事是让你的Jr. Devs练习Bowling Game Kata,这将有助于他们学习测试驱动开发。它在java中,但可以很容易地适应任何语言。

答案 1 :(得分:21)

在每次提交之前进行代码审查(即使它是1分钟“我已经更改了此变量名称”),并且作为代码审查的一部分,请查看任何单元测试。

在测试到位之前,不要在提交时签名。

(另外 - 如果他的工作未经过测试 - 为什么它首先在生产版本中?如果没有经过测试,请不要让它进入,那么你就不必在周末工作了)

答案 2 :(得分:20)

对于我自己,我已经开始坚持认为我找到并修复的每个错误都表示为测试:

  1. “嗯,那不对......”
  2. 查找可能的问题
  3. 编写测试,显示代码失败
  4. 解决问题
  5. 显示新代码已通过
  6. 如果原始问题仍然存在,则循环播放
  7. 我尝试在敲打东西的同时做到这一点,大约在同一时间完成,只有部分测试套件已经到位。

    (我不是生活在商业编程环境中,而且通常是唯一一个从事特定项目的编码人员。)

答案 3 :(得分:16)

想象一下,我是一个模拟程序员,名字叫...... Marco。想象一下,我不久前已经毕业了,从来没有真正写过考试。想象一下,我在一家没有真正执行或要求的公司工作。好?好!现在想象一下,该公司正在转向使用测试,他们正试图让我对此进行内联。我会对目前提到的项目做出一些讽刺的反应,好像我没有对此做过任何研究。

让我们从创作者开始:

  

表明设计变得更简单。

如何写更多,让事情更简单。我现在必须密切关注获得更多案件等等。如果你问我,这会让事情变得更加复杂。给我详细的信息。

  

显示它可以防止出现缺陷。

我知道。这就是他们被称为测试的原因。我的代码很好,我检查了它的问题,所以我看不出那些测试会有什么帮助。

  

让它成为一个自负的事情,只说坏程序员不会。

哦,所以你认为我是一个糟糕的程序员只是因为我没有那么多用过的测试。我被侮辱并对你感到非常恼火。我宁愿得到帮助和支持而不是说法。

  

@ Justin Standard:在新的角色开始时,与你自己或其他高级程序员一起开始。

哦,这是非常重要的,我将花费资源确保我看到事情是如何完成的,并且有一些帮助我完成工作的方式。这很有帮助,我可能会开始做更多。

  

@ Justin Standard:阅读凯特罗德斯的Unit Testing 101演示文稿。

啊,这是一个有趣的演讲,它让我考虑测试。它打破了我应该考虑的一些问题,它可能会影响我的观点。

我希望看到更引人注目的文章和其他工具,以帮助我认为这是正确的做事方式。

  

@ Dominic Cooney:花一些时间分享测试技巧。

啊,这有助于我了解对技术的期望是什么,并且它将更多的项目放在我的知识包中,我可能会再次使用。

  

@ Dominic Cooney:回答问题,示例和书籍。

让一个点人(人)回答问题很有帮助,这可能会让我更有可能尝试。好的例子很棒,它给了我一些目标,以及寻找参考的东西。直接与此相关的书籍是很好的参考。

  

@ Adam Hayle:惊喜评论。

说什么,你提出了一些我完全没有准备的东西。我对此感到不舒服,但会尽我所能。我现在会害怕并且有点担心再次出现,谢谢。然而,恐吓战术可能有效,但确实有成本。但是,如果没有其他工作,这可能只是需要的推动。

  

@ Rytmis:项目只有在有测试用例时才会被视为已完成。

哦,有趣。我觉得我现在真的必须这样做,否则我没有完成任何事情。这是有道理的。

  

@ jmorris:获取Rid / Sacrifice。

怒视,强光,怒视 - 我有机会学习,在支持和帮助下,我可以成为团队中非常重要和有功能的部分。这是我现在的一个障碍,但不会持续很长时间。但是,如果我没有得到它,我明白我会去。我想我会得到它。


最后,我的团队的支持在这一切中发挥了重要作用。让一个人花时间去帮助,让我开始养成良好的习惯总是受到欢迎。然后,拥有一个良好的支持网将是伟大的。总是会感激的是,有人来过几次,并查看一些代码,看看一切是如何流动的,不是在审查本身,而是更友好的访问。

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

答案 4 :(得分:12)

我注意到很多程序员在合理的层面上看到了测试的价值。如果你听过“是的,我知道我应该测试这个,但我真的需要快速完成”然后你知道我的意思。然而,在情感层面上,他们觉得只有在编写真实代码时才会完成某些事情。

那么,目标应该是以某种方式让他们明白测试实际上是唯一的方法来衡量什么是“完成”,从而给他们编写测试的内在动机

但是,我担心这比应该的要困难得多。你会听到很多借口,“我真的很着急,我稍后会重写/重构,然后添加测试” - 当然,后续工作从未发生,因为,令人惊讶的是,他们 em>就像下周一样忙碌。

答案 5 :(得分:9)

这就是我要做的事情:

  • 第一次出去......“我们将共同完成这个项目。我打算编写测试,你要编写代码。注意我如何编写测试,因为这就是我们在这里做事的方式,这就是我对你的期望。“

  • 接下来......“你做完了吗?太棒了!首先让我们来看看推动你发展的测试。哦,没有测试?让我知道什么时候完成,我们会重新安排看看你的代码。如果你需要帮助来制定测试,请告诉我,我会帮助你。“

答案 6 :(得分:5)

作为一名初级程序员,我仍然在努力养成编写测试的习惯。显然,要养成新的习惯并不容易,但考虑一下这对我有什么影响,我必须给出关于代码审查和辅导/配对编程的评论。

也许值得强调测试的长期目的:确保昨天工作的东西今天,下周和下个月仍在工作。我只是这样说,因为在略读答案时我没有看到提到的那些。

在进行代码审核时(如果你决定这样做),请确保你的年轻开发者知道这不是要让他失望,而是关于让代码更好。因为这样他的信心就更少了可能会受到损害。这很重要。另一方面,知道你知之甚少也是如此。

当然,我真的什么都不知道。但我希望这些词语很有用。

  

修改:[Justin Standard]

     

不要让自己失望,你要说的话几乎是正确的。

     

关于代码审查的观点:你会发现,不仅初级开发人员会在这个过程中学习,但审稿人也会如此。代码审核中的每个人都会了解您是否将其作为协作流程。

答案 7 :(得分:4)

他已经这样做了。真。他只是不写下来。不相信?看着他完成标准的开发周期:

  • 写一段代码
  • 编译
  • 运行以查看其功能
  • 写下一段代码

步骤#3是测试。他已经做了测试,他只是手动完成。问他这个问题:“明天你怎么知道今天的代码仍然有效?”他会回答:“这是一个很小的代码!”

问:“下周怎么样?”

当他没有得到答案时,问:“当你的改变打破了昨天有用的东西时,你希望你的程序告诉你什么?”

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

答案 8 :(得分:4)

坦率地说,如果你不得不付出那么多努力让他做某事,那么你可能不得不接受他认为他可能不适合团队的想法。 ,可能需要去。现在,这并不一定意味着解雇他......这可能意味着找到公司的其他地方,他的技能更适合。但如果没有其他地方......你知道该怎么做。

我认为他也是一个相当新的雇员(< 1年),可能最近还没有上学......在这种情况下,他可能不习惯在公司环境中如何运作。我们大多数人都可以在大学里逍遥法外。

如果是这种情况,我发现的一件事就是有一种“令人惊讶的新员工评论”。如果你以前从未这样做过没关系......他不会知道的。只是坐下来告诉他你将继续他的表现,并向他展示一些真实的数字......拿你正常的评论表(你有正确的审查过程吗?)并改变标题,如果你想要它看起来官员并告诉他他的立场。如果你在一个非常正式的环境中向他展示不进行测试会对他的表现评级产生负面影响,而不是仅仅“唠叨”他,他希望能够明白这一点。你必须告诉他,他的行为实际上会影响他,无论是付钱还是其他方式。

我知道,你可能希望远离这样做,因为它不是正式的...但我认为你有理由这样做而且它可能比解雇他并招募某人便宜得多新。

答案 9 :(得分:3)

将它们分配给不需要“高质量稳定代码”的项目,如果这是您的关注并让jr。开发人员失败让他们成为“周末进来”修复他们的错误的人。共进午餐并谈论软件开发实践(不是讲座,而是讨论)。他们将及时获得并开发最佳实践来完成他们分配的任务。

谁知道,他们甚至可能会提出比团队目前使用的技术更好的东西。

答案 10 :(得分:3)

作为一名自己的初级程序员,我认为当我发现自己处于与初级开发人员类似的情况时,我会发现它是什么样的。

当我第一次离开大学时,我发现它完全没有能力处理现实世界。是的,我知道一些JAVA基础知识和一些哲学(不要问),但那是关于它的。当我第一次找到工作时,至少可以说有点令人生畏。让我告诉你我可能是最大的牛仔之一,我会破解一个小错误修复/算法,没有评论/测试/文档,并把它运出门外。

我很幸运能够受到一位善良的非常患者高级程序员的监督。对我来说幸运的是,他决定和我坐下来,用1-2周的时间来完成我的黑客密码。他会解释我出错的地方,c和指针的精细点(男孩让我迷惑了!)。我们设法在大约一周内编写了一个相当不错的课程/模块。我只能说,如果高级开发人员没有花时间帮助我走正确的道路,我可能不会持续很长时间。

令人高兴的是,2年后,我希望我的一些同事甚至可能认为我是一名普通的程序员。

带回家点

  1. 大多数大学都非常擅长为现实世界做好准备
  2. 配对编程确实帮助了我。多数民众赞成不是说它会帮助每个人,但它对我有用。

答案 11 :(得分:2)

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

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

注意:如果您打算这样做,确实想要thunderbird colored-diffs addon

我的老板或我自己(2位'高级'编码员)最终将阅读提交内容,如果有任何类似“你忘了添加单元测试”的内容,我们只需点击一封电子邮件或者去与该人聊天,解释为什么他们需要单元测试或其他什么鼓励其他人也阅读这些提交内容,因为这是查看正在发生的事情的一种很好的方式,但是初级开发者并没有这么多评论。

你可以通过定期说“嘿,鲍勃,你看到我今天早上做了什么,我发现这个巧妙的伎俩,你可以做什么等等,你可以帮助鼓励人们养成这个习惯。”提交并看看它是如何工作的!“

注意:我们有2个'高级'开发者和3个初级开发者。这可能无法扩展,或者您可能需要与更多开发人员稍微调整一下这个过程。

答案 12 :(得分:2)

很多心理学和有用的“辅导”技巧,但老实说,这只是归结为“如果你想明天仍然有工作,可以写下测试。”

你可以用你认为合适,苛刻或柔软的任何条件来安抚它,这无关紧要。但实际情况是,程序员不需要付费就可以将代码放在一起。检查它 - 他们付钱是为了仔细整理代码,然后将测试放在一起,然后测试他们的代码,然后检查整个内容。(至少听起来就是这样,来自你的描述。)

因此,如果有人拒绝做他们的工作,请向他们解释他们明天可以待在家里,并且你会聘请一位能够胜任这项工作的人。

再一次,你可以轻轻地做这一切,如果你认为这是必要的,但是很多人只需要一点点真实世界中的生活,你就会做到这一点给予他们的帮助。

祝你好运。

答案 13 :(得分:2)

改变他的工作描述一段时间,完全是编写测试和维护测试。我听说很多公司在他们开始的时候会为新的没有经验的新人做这件事。

此外,当他担任该角色时发出挑战:编写将在当前代码上失败的测试a)满足软件的要求。希望这将使他能够创建一些可靠而彻底的测试(改进项目),并使他更好地编写测试,以便重新集成到核心开发中。

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

答案 14 :(得分:2)

如果初级程序员或任何人没有看到测试的价值,那么很难让他们这样做......期间。

我会让初级程序员牺牲周末来修复bug。他的行为(或缺乏行动)不会直接影响他。另外,很明显,如果他不提高测试技能,他就不会看到晋升和/或加薪。

最后,即使得到你所有的帮助,鼓励,指导,他也可能不适合你的团队,所以让他去寻找能够得到它的人。

答案 15 :(得分:2)

  1. 将代码覆盖率作为评论的一部分。
  2. 让“编写公开错误的测试”是修复错误的先决条件。
  3. 在签入代码之前需要一定程度的覆盖率。
  4. 找一本关于测试驱动开发的好书,并用它来展示测试优先如何加速开发。

答案 16 :(得分:1)

在您的源存储库上:在每次提交之前使用挂钩(例如,为SVN预提交挂钩)

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

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

只有自动检查才能在项目中很好地扩展。你不能手工检查所有东西。

开发人员应该有意思检查他的测试用例是否涵盖了100%的代码。这样,如果他没有提交100%经过测试的代码,那就是他自己的错,而不是“哎呀,对不起我忘记了”。

记住:人们永远不会做你期望的事情,他们总是做你所检查的事情。

答案 17 :(得分:1)

他的导师有责任教导他/她。你如何教他/她如何测试。你和他结对编程吗? Junior很可能不知道如何为xyz设置一个好的测试。

作为一名少年新学校,他知道很多概念。一些技巧。一些经验。但最终,所有青少年都是潜在的。几乎他们所处理的每一个功能,都会有一些他们以前从未做过的新事物。当然,Junior可能已经为课堂上的项目做了一个简单的状态模式,打开和关闭了“门”,但从未真正应用过模式。

他/她只会和你的教学一样好。如果他们能够“只是得到它”你认为他们会在第一时间采取初级职位吗?

根据我的经验,三年级学生被聘用并且与老年人一样承担相同的责任,但是他们只是少付钱,然后在他们开始动摇时被忽略。原谅我,如果我看起来很苦,那是因为我。

答案 18 :(得分:1)

@ jsmorris

我曾经让高级开发人员和“建筑师”在电子邮件中谴责我和测试人员(这是我大学毕业后的第一份工作),因为他们没有迟到,并且在前一天晚上完成了这么简单的任务。我们整天都在这里,并称它在晚上7点退出,当天上午1​​1点之前我一直在吵架,并且纠缠了我们团队的每个成员至少两次。

我回复并抄送了团队: “我已经对你失望了一个月了。我从来没有得到团队的帮助。如果你需要我,我会在街对面的咖啡店。我很抱歉我无法调试12参数, 800线方法,几乎​​所有东西都依赖于它。“

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

“那你放弃了吗?”

答案 19 :(得分:1)

如果您的同事缺乏编写测试的经验,他或她可能难以在简单情况下进行测试,这表明测试不充分。这是我会尝试的:

  • 花一些时间和共享测试技术,如依赖注入,寻找边缘案例等等,与您的同事一起。
  • 提出回答有关测试的问题。
  • 暂时对代码进行代码审查。请您的同事查看您的更改,这些更改是良好测试的典范。查看他们的评论,看看他们是否真正阅读并理解您的测试代码。
  • 如果有适合您团队测试理念的书籍,请给他或她一份副本。如果您的代码审核反馈或讨论引用该书,那么它可能会有所帮助,因此他或她有一个线索可以接听和关注。

我不会特别强调羞耻/内疚因素。值得指出的是,测试是一种广泛采用的良好实践,编写和维护良好的测试是一种专业的礼貌,所以你的队友不需要在工作中度过周末,但我不会对这些问题提出异议。 / p>

如果你真的需要“变得强硬”,那么建立一个公正的制度;没有人愿意觉得他们被挑出来了。例如,您的团队可能需要代码来维持一定程度的测试覆盖率(能够进行游戏,但至少能够实现自动化);要求新代码进行测试;要求审稿人在进行代码审查时考虑测试的质量;等等。建立该系统应该来自团队共识。如果您仔细调整讨论,可能会发现您的同事测试不符合您预期的其他潜在原因。

答案 20 :(得分:1)

首先,就像大多数受访者在这里指出的那样,如果这个人没有看到测试中的价值,你就无法做到这一点,而且你已经指出你不能解雇这个人。但是,失败不是一个选择,那么你可以做的几件事呢?

如果您的组织足够大,可以拥有超过6名开发人员,我强烈建议您拥有质量保证部门(即使只有一个人可以开始)。理想情况下,您应该有1个测试人员与3-5个开发人员的比率。关于程序员的事情是......他们是程序员,而不是测试人员。我还没有采访过已经正式教授适当QA技术的程序员。

大多数组织都会将测试角色分配给新员工,这是一个对您的代码负面影响最小的人员的理想缺陷 - 理想情况下,高级开发人员应该被转移到QA角色,因为他们有经验在代码中,(希望)已经为代码气味和失败点提出了第六感。

此外,犯了错误的程序员可能不会找到缺陷,因为它通常不是语法错误(那些在编译中被拾取),但是逻辑错误 - 并且相同的逻辑在工作时他们在编写代码时编写测试。没有开发代码测试代码的人 - 他们会发现比其他人更少的错误。

在您的情况下,如果您能负担重定向的工作量,请让这个新人成为您QA团队的第一个成员。让他阅读“现实世界中的软件测试:改进过程”,因为他显然需要接受一些新角色的培训。如果他不喜欢,他会退出,你的问题仍然可以解决。

一个稍微不那么复仇的方法就是让这个人做他们擅长的事情(我假设这个人被雇用,因为他们实际上能胜任工作的编程部分),并雇用一两个测试人员去做测试(大学生经常有实习或“合作社”的条款,会喜欢这种曝光,并且很便宜)

附注:最后,您需要QA团队向QA主管报告,或者至少不向软件开发人员报告,因为让QA团队向经理报告的主要目标是完成产品是利益冲突。

如果您的组织小于6,或者您无法创建新团队,我建议使用配对编程(PP)。我不是所有极端编程技术的完全转换,但我绝对相信配对编程。但是,配对编程团队的成员都必须专注,或者根本不起作用。他们必须遵循两条规则:检查员必须完全理解屏幕上的编码内容,或者他必须要求编码员解释它;编码员只能编码他能解释的内容 - 没有“你会看到”或“信任我”或挥手将被容忍。

如果你的团队有能力,我只会推荐PP,因为,就像测试一样,没有任何欢呼或威胁可以说服一些自我内向的内向者如果他们感觉不舒服就会一起工作。但是,我发现在编写详细的功能规范和进行代码审查与配对编程之间,PP通常会胜出。

如果PP不适合你,那么TDD是你最好的选择,但前提是它的字面意思。测试驱动开发意味着您首先编写测试,运行测试以证明它们确实失败,然后编写最简单的代码以使其工作。现在,您应该拥有数千个测试的集合,这也是代码,并且与包含错误的生产代码一样可能。老实说,我不是TDD的忠实粉丝,主要是因为这个原因,但它适用于许多开发人员,他们宁愿编写测试脚本而不是测试用例文档 - 有些测试总比没有好。将PPD与PP结合使用可以提高测试覆盖率,减少脚本中的错误。

如果所有其他方法都失败了,让程序员等同于一个发誓的jar - 每次程序员打破构建时,他们必须把20美元,50美元,100美元(对于你的员工来说是适度的痛苦)放到一个罐子里去你最喜欢的(注册!)慈善机构。直到他们付钱,避开他们:)

所有开玩笑,让程序员编写测试的最佳方法是不要让他编程。如果你想要一个程序员,雇用一个程序员 - 如果你想要测试,雇用一个测试员。我12年前开始作为一名初级程序员进行测试,并且它变成了我的职业道路,我不会为此做任何交易。一个可靠的QA部门得到了适当的培养,并赋予了改进软件的权力和授权,这与开发人员首先编写软件一样有价值。

答案 21 :(得分:0)

根据你的评论,“表明设计变得更简单”我假设你们练习TDD。事后进行代码审查不起作用。关于TDD的全部内容是它是一种设计,而不是一种测试理念。如果他没有将测试作为设计的一部分进行编写,那么在事后编写测试并不会从中获得很多好处 - 特别是来自初级开发人员。他最终会错过很多角落案件,他的代码仍然很糟糕。

你最好的办法是让一个非常耐心的高级开发人员与他坐在一起做一些结对编程。只要坚持下去,直到他得知。或者不学习,在这种情况下你需要重新分配给他更适合的任务,因为你最终会让真正的开发者感到沮丧。

并非所有人都具有相同水平的人才和/或动力。开发团队,甚至是敏捷开发团队,由“A-Team”上的人员和“B-Team”上的人员组成。 A-Team成员是构建解决方案,编写所有非平凡生产代码并与业务所有者沟通的人员 - 所有需要在框外思考的工作。 B-Team处理诸如配置管理,编写脚本,修复缺陷错误和执行维护工作之类的事情 - 所有具有严格程序的工作都会对失败产生很小的影响。

答案 22 :(得分:0)

初级工程师/程序员不需要花费大量时间来设计和执行测试脚本的主要原因是因为大多数CS认证并不需要这么做,因此大学课程中还有其他工程领域,例如设计patters。

根据我的经验,让初级专业人员养成习惯的最佳方法是明确地将其作为流程的一部分。也就是说,当估计迭代应该花费的时间时,设计,编写和/或执行案例的时间应该被合并到该时间估计中。

最后,检查测试脚本设计应该是设计审查的一部分,并且应该在代码审查中审查实际代码。这使程序员有责任对他/她编写的每行代码进行适当的测试,高级工程师和同事有责任提供有关代码和测试的反馈和指导。

答案 23 :(得分:0)

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