如何激励同事编写单元测试.docxVIP

如何激励同事编写单元测试？ 从管理人员到开发者，每个人都在说单元测试，但是却很少有人执行。 从管理人员到开发者，每个人都在说单元测试，但是却很少有人执行。Lurkerbelow 深知单元测试带来的好处，也积极提倡单元测试，但公司同仁却对此毫无兴趣。无奈之下， Lurkerbelow 在Stack Exchange 发出上“求救”，抛出《如何激励同事进行单元测试？》的话题。 从管理人员到开发者，每个人都在说单元测试，但是却很少有人执行。有关单元测试的好处相信大家也能例举出一二，但很多时候，开发者面对自己的项目代码却无从下手。 Lurkerbelow 在公司里是唯一执行单元测试的一名开发者，他深知单元测试带来的好处，也积极提倡单元测试。他甚至与公司的管理层人员、开发者都讨论过单元测试，但却无人对此感兴趣。 为了与开发人员形成一条战线，Lurkerbelow 甚至“被迫 “提交了代码审查（ Gerrit）和持续集成开发（ Jenkins）。 无奈之下，Lurkerbelow 在 Stack Exchange 发出上“求救”，抛出《如何激励同事进行单元测试？》的话题，引发了众多开发者的关注，纷纷献策。 对此， CSDN 研发频道从中摘译了几个较为重要的观点与大家分享，希望能引起大家的共鸣。 实质的文档或许有帮助 jimmy_keen：我注意到几乎很少有公司在谈论TDD。人们更乐意看到最终结果。人人都说 “编写单元测试将缩短开发时间”，这是似乎是真的，但这并不足以让人们相信。 我与你处在相同的位置（但不像你这么糟糕），开发者在代码问题上都能够自行解决（这里的代码是指单元测试）。某个项目停止更新时，本地的调查自然就会更进，进而找出问题所 在。 然后，当我们进行单元测试时，如果测试被通过了，大多数问题会出现在最新的、未测试的代码中。如果不是，测试通常能够发现问题（至少找出了正确的方向）。我们修复Bug，再进行测试。 一句话，如果发生类似这样的情况，将会有超过2 名开发者变成可TDD 测试爱好者（我们希望更多人参与）。 建议，你可以选择TDDkata 将使用测试作为首选方法。 根据任务的复杂程度，非测试方法进程通常较为缓慢，尤其是当增量编码器需求发生更改时。 Roys string calculator Bank OCR 找出问题所在，“对症下药” HLGEM：首先，要弄清楚为什么他们不喜欢写单元测试。 通常严格的时间进程表是导致其最大的原因。 其次，现有的大型未测试的代码基，编写单元测试工作量巨大。因此，开发者本能认为：“这太麻烦了，我得跳过去。” 另一个原因可能是，他们骨子里认为测试是个好方法，但他们在如何写测试上没有信心，尤其是他们从未接触过。究其根本原因，是开发者根本不会写单元测试！ 还有一大原因是，他们没有看到这项额外的工作所带来的好处（利润）故放弃，即便是他们想提供这样的服务。 那么，对于以上这些情况该如何处理呢？ Reason 1：向开发者展示案例，如何节省开发时间。 Reason 2：告诉开发者在一年内能编写多少测试，代码基覆盖了多少比例。 算算这一年里他们写了多少测试，明年他们依然愿意这么做。一旦他们发觉每天都会进步一点点，思想上就会潜移默化了，从而产生质的变化。 如果可以的话，把系统数据拉出来，让他们知道在未经测试的代码中有多少重复Bug？进行单元测试的代码中又有多少重复bug？ Reason 3：培训，让开发者在培训班中编写测试。 Reason 4：这是问题的关键所在，首先，选择一个痛点，比如在某个项目中这些Bug 被多次返回。在上述过程中，向管理部门提出建议，如果他们在这个项目中进行单元测试，那就不会出现不想见而又偏又见到的代码。 当然，作为开发人员，我们首先要学会自我管理。 写好单元测试，学会重构很重要 ElYusubov：我想先说说TDD 的好处。 从正常人类的角度思考，开发者都是以利益为主，因为他们不想进行工作意外的事情。单元测试意味着更少的工作；意味着与朋友相处的时间更多；意味着有更多的乐趣，因为你无须每个夜晚编码工作到 11 点；也就意味着可以舒心的度过假期。 想要写好单元测试，学会重构是很重要的。这里补充几点： 1.编写测试代码建立基本的防护网。；2.在单元测试和功能测试之间要有取舍，如果单元测 试实施成本很高，可以先加功能测试；3.通过增加中间层来打破依赖，不是为了去掉依赖， 而是为了后续的修改以及测试的便利；4.将第一步中编写的功能测试换成单元测试。 TDD 最大的好处之一是，你可以重构程序获得更好的设计或者只需改变某个项目的名称……只要这种设计没有破坏测试，前提是你有 100%的信心保证你的改变没有破坏任何东西。 TDD 为遗留代码创建单元测试，这将出现重构。从长远的来说，这将有有助于改善你的代码