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


当前回答

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

其他回答

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

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

就在今天,我不得不更改一个类,之前已经为其编写了单元测试。 测试本身写得很好,包括我甚至没有想过的测试场景。 幸运的是,所有测试都通过了,我的更改很快得到了验证,并自信地放到了测试环境中。

单元测试非常值得最初的投资。自从几年前开始使用单元测试以来,我发现了一些真正的好处:

回归测试消除了恐惧 对代码进行更改(什么都没有 就像看到代码的温暖光芒 每次有变化,要么工作,要么爆发 了) 以下的可执行代码示例 其他团队成员(包括你自己) 6个月的时间…) 无情的重构——这是令人难以置信的回报,试试吧!

代码片段可以极大地帮助减少创建测试的开销。创建能够在几秒钟内创建类大纲和相关单元测试fixture的代码片段并不困难。

根据我的经验,在复杂的软件环境中,单元测试和集成测试是“必须的”。

为了说服团队中的开发人员编写单元测试,您可能需要考虑在开发环境中集成单元测试回归分析(例如,在您的日常构建过程中)。

一旦开发人员知道如果单元测试失败,他们就不必花那么多时间调试它来发现问题,他们就会更有动力去编写这些测试。

这里有一个工具可以提供这样的功能:

单元测试回归分析工具

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

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