我正致力于将单元测试集成到我所在团队的开发过程中,有一些人对此持怀疑态度。有什么好方法可以让团队中持怀疑态度的开发人员相信单元测试的价值?在我的具体情况下,我们将在添加功能或修复错误时添加单元测试。不幸的是,我们的代码库并不容易进行测试。


当前回答

作为一名物理专业的学生,我非常有动力去证明我的代码是可以正常工作的。您可以从逻辑上证明这一点,随着实现变得更加复杂,难度会急剧增加,或者您可以通过良好的测试对功能进行(尽可能接近的)经验证明。

如果不提供函数的逻辑证明,就必须进行测试。唯一的选择是说“我认为代码可以工作....”

其他回答

测试驱动开发中经常被忽略的一个主要部分是可测试代码的编写。乍一看,这似乎是一种妥协,但您会发现可测试代码最终也是模块化的、可维护的和可读的。 如果你仍然需要说服别人,这是一个关于单元测试优点的简单演示。

One of the best things about unit testing is that your code will become easier to test as you do it. Preexisting code created without tests is always a challenge because since they weren't meant to be unit-tested, it's not rare to have a high level of coupling between classes, hard-to-configure objects inside your class - like an e-mail sending service reference - and so on. But don't let this bring you down! You'll see that your overall code design will become better as you start to write unit-tests, and the more you test, the more confident you'll become on making even more changes to it without fear of breaking you application or introducing bugs.

There are several reasons to unit-test your code, but as time progresses, you'll find out that the time you save on testing is one of the best reasons to do it. In a system I've just delivered, I insisted on doing automated unit-testing in spite of the claims that I'd spend way more time doing the tests than I would by testing the system manually. With all my unit tests done, I run more than 400 test cases in less than 10 minutes, and every time I had to do a small change in the code, all it took me to be sure the code was still working without bugs was ten minutes. Can you imagine the time one would spend to run those 400+ test cases by hand?

当涉及到自动化测试——无论是单元测试还是验收测试——每个人都认为编写可以手动完成的代码是浪费精力,有时这是真的——如果你计划只运行一次测试的话。自动化测试最好的部分是,您可以毫不费力地运行它们几次,并且在第二次或第三次运行之后,您所浪费的时间和精力已经得到了补偿。

最后一个建议是,不仅要对代码进行单元测试,还要先进行测试(详见TDD和BDD)。

使用单元测试套件,可以在保持其余功能不变的情况下对代码进行更改。这是一个很大的优势。当你完成新功能的编码时,你会使用单元测试套件和回归测试套件吗?

关于单元测试要记住的一件事是,它对开发人员来说是一种安慰。

相反,功能测试是针对用户的:无论何时添加功能测试,您都是在测试用户将看到的东西。当您添加单元测试时,您只是让开发人员的生活更轻松。在这方面有点奢侈。

当您必须在编写单元或功能测试之间做出选择时,请记住这种二分法。

偶尔,我自己或我的同事会花几个小时来研究一个不太明显的错误,一旦发现了错误的原因,90%的情况下代码都没有经过单元测试。单元测试并不存在,因为开发人员为了节省时间而偷工减料,但随后却失去了这一点和更多的调试。

花少量的时间来编写单元测试可以节省未来调试的时间。