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


当前回答

[我有一个观点,我不能在上面看到]

“每个人都在进行单元测试,他们不一定意识到这一点——事实”

想想看,你写了一个函数来解析一个字符串并删除新的行字符。作为一个开发新手,你要么在命令行中通过Main()实现它来运行几个用例,要么用一个按钮组合一个可视化前端,将你的函数绑定到几个文本框和一个按钮上,然后看看会发生什么。

这就是单元测试——基本的和糟糕的组合在一起,但是你测试了一些情况下的代码段。

你写一些更复杂的东西。当您抛出一些用例(单元测试)并将其调试到代码中并进行跟踪时,它会抛出错误。你在浏览过程中查看这些值,并决定它们是对还是错。在某种程度上,这是单元测试。

这里的单元测试实际上是采用这种行为,将其形式化为结构化模式并保存,以便您可以轻松地重新运行这些测试。如果您编写了一个“适当的”单元测试用例而不是手动测试,那么它所花费的时间是相同的,或者随着您的经验的增加可能会更少,并且您可以一次又一次地重复它

其他回答

Unit testing helps a lot in projects that are larger than any one developer can hold in their head. They allow you to run the unit test suite before checkin and discover if you broke something. This cuts down a lot on instances of having to sit and twiddle your thumbs while waiting for someone else to fix a bug they checked in, or going to the hassle of reverting their change so you can get some work done. It's also immensely valuable in refactoring, so you can be sure that the refactored code passes all the tests that the original code did.

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

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

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

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

单元测试回归分析工具

让你测试的第一个东西与单元测试无关。我主要使用Perl工作,所以这些都是特定于Perl的示例,但您也可以适应。

每个模块是否正确加载和编译?在Perl中,这是一个创建Foo的问题。t对每个Foo。PM的代码库,它做: use_ok('Foo'); 所有的POD(普通文档)格式是否正确?使用Test::Pod来验证所有文件中所有Pod格式的有效性。

你可能不认为这些是大事情,他们不是,但我可以保证你会抓到一些泔水。当这些测试每小时运行一次,并捕捉到某人的过早提交时,您会让人们说“嘿,这很酷”。

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

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

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

[我有一个观点,我不能在上面看到]

“每个人都在进行单元测试,他们不一定意识到这一点——事实”

想想看,你写了一个函数来解析一个字符串并删除新的行字符。作为一个开发新手,你要么在命令行中通过Main()实现它来运行几个用例,要么用一个按钮组合一个可视化前端,将你的函数绑定到几个文本框和一个按钮上,然后看看会发生什么。

这就是单元测试——基本的和糟糕的组合在一起,但是你测试了一些情况下的代码段。

你写一些更复杂的东西。当您抛出一些用例(单元测试)并将其调试到代码中并进行跟踪时,它会抛出错误。你在浏览过程中查看这些值,并决定它们是对还是错。在某种程度上,这是单元测试。

这里的单元测试实际上是采用这种行为,将其形式化为结构化模式并保存,以便您可以轻松地重新运行这些测试。如果您编写了一个“适当的”单元测试用例而不是手动测试,那么它所花费的时间是相同的,或者随着您的经验的增加可能会更少,并且您可以一次又一次地重复它