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


当前回答

单元测试的一个好处是,它们可以作为说明代码行为方式的文档。好的测试有点像参考实现,团队成员可以通过查看它们来了解如何将他们的代码与您的代码集成。

其他回答

如果你正在使用NUnit,一个简单而有效的演示就是在他们面前运行NUnit自己的测试套件。看到一个真正的测试套件对代码库进行测试,胜过千言万语……

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

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

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

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

单元测试适用于QA人员或你的经理,而不是你;所以绝对不值得。

您应该专注于编写正确的代码(不管这意味着什么),而不是测试用例。让其他人去担心吧。

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

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

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