从管理人员到开发者，每个人都在说单元测试，但是却很少有人执行。有关单元测试的好处相信大家也能例举出一二，但很多时候，开发者面对自己的项目代码却无从下手。

　　Lurkerbelow在公司里是执行单元测试的一名开发者，他深知单元测试带来的好处，也积极提倡单元测试。他甚至与公司的管理层人员、开发者都讨论过单元测试，但却无人对此感兴趣。 为了与开发人员形成一条战线，Lurkerbelow甚至“被迫“提交了代码审查（Gerrit）和持续集成开发（Jenkins）。

　　无奈之下，Lurkerbelow在 Stack Exchange发出上“求救”，抛出《“如何激励同事进行单元测试？》的话题，引发了众多开发者的关注，纷纷献策。

　　对此，我们从中摘译了几个较为重要的观点与大家分享，希望能引起大家的共鸣。

　　实质的文档或许有帮助

　　jimmy_keen：我注意到几乎很少有公司在谈论TDD。人们更乐意看到终结果。人人都说“编写单元测试将缩短开发时间”，这是似乎是真的，但这并不足以让人们相信。

　　我与你处在相同的位置（但不像你这么糟糕），开发者在代码问题上都能够自行解决（这里的代码是指单元测试）。某个项目停止更新时，本地的调查自然会更进，进而找出问题所在。

　　然后，当我们进行单元测试时，如果测试被通过了，大多数问题会出现在新的、未测试的代码中。如果不是，测试通常能够发现问题（至少找出了正确的方向）。我们修复Bug，再进行测试。

　　一句话，如果发生类似这样的情况，将会有超过2名开发者变成可TDD 测试爱好者（我们希望更多人参与）。

　　建议，你可以选择TDDkata将使用测试作为方法。

　　根据任务的复杂程度，非测试方法进程通常较为缓慢，尤其是当增量编码器需求发生更改时。

　　● Roy's string calculator

　　● Bank OCR

　　找出问题所在，“对症下药”

　　HLGEM：首先，要弄清楚为什么他们不喜欢写单元测试。 通常严格的时间进程表是导致其大的原因。

　　其次，现有的大型未测试的代码基，编写单元测试工作量巨大。因此，开发者本能认为：“这太麻烦了，我得跳过去。”

　　另一个原因可能是，他们骨子里认为测试是个好方法，但他们在如何写测试上没有信心，尤其是他们从未接触过。究其根本原因，是开发者根本不会写单元测试！