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


当前回答

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

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

其他回答

@George Stocker“不幸的是,我们的代码库并不适合简单的测试。”每个人都同意单元测试有好处,但对于这个代码库来说,成本似乎很高。如果成本大于收益,那么他们为什么要对此充满热情呢?倾听你同事的意见;也许对他们来说,单元测试的痛苦比单元测试的价值更大。

具体地说,尽量尽快获得价值,而不是一些感觉良好的“xUnit是绿色的”价值,而是用户和维护者所重视的干净代码。也许您必须为一次迭代强制进行单元测试,然后讨论是否值得这样做。

如果您现有的代码库本身不适合单元测试,并且它已经处于生产环境中,那么通过试图重构所有代码以使其具有单元可测试性,您可能会产生比解决更多的问题。

您最好将精力放在改进集成测试上。有很多代码在没有单元测试的情况下编写起来更简单,如果QA可以根据需求文档验证功能,那么就完成了。船。

在我的脑海中,最经典的例子就是嵌入到GridView的ASPX页面中的SqlDataReader。代码都在ASPX文件中。SQL位于存储过程中。你做什么单元测试?如果页面做了它应该做的事情,那么是否真的应该将其重新设计成几个层,以便实现自动化?

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

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

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

单元测试的好处之一是可预测性。

在单元测试之前,我可以非常准确地预测编写代码所需的时间,但无法预测调试所需的时间。

现在,因为我可以计划将要编写什么测试,所以我知道编码需要多长时间,并且在编码结束时,系统已经调试好了!这为开发过程带来了可预见性,消除了许多压力,但仍然保留了所有的乐趣!!