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


当前回答

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

其他回答

你想说服谁?工程师还是经理?如果你试图说服你的工程师同事,我认为你最好的办法是迎合他们的愿望,让他们做出高质量的软件。有许多研究表明,它能发现漏洞,如果他们关心做好工作,这对他们来说就足够了。

如果您试图说服管理层,您将很可能不得不做一些成本/收益推理,说明未检测到的缺陷的成本大于编写测试的成本。一定要把不可转化的成本也包括在内,比如失去客户的信心等等。

最好的说服方式是……找到一个bug,为它写一个单元测试,修复这个bug。

这个特定的错误不太可能再次出现,您可以通过测试来证明它。

如果你做得足够多,其他人很快就会明白。

我同意与大多数人相反的观点: 不编写单元测试是可以的 特别是重原型的编程(例如AI)很难与单元测试相结合。

当您手动测试软件时,通常会使用一小组测试/操作。最终,您将自动修改输入数据或操作,以便围绕已知问题进行导航。应该有单元测试来提醒您某些事情不能正常工作。

我建议在编写代码之前编写测试,添加新的测试/数据来改进主代码的功能!

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

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

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