事后,Pro和Con的单元测试

Question

我有一个大约27k线的大型复杂应用程序.它本质上是一个规则驱动多线程处理引擎,没有给予太多它已经部分测试,因为它已经构建,某些组件.

我有问题,在事实之后进行单元测试的专业人员和合作伙伴是什么,可以说,在实施之后.很明显,传统的测试需要2-3个月的时间来测试每个方面,而这一切都需要工作,而且这个时间真的不可用.

我过去做了很多单元测试,但通常是桌面自动化或LOB应用程序,这些都非常简单.该应用程序本身是高度组件化的内部,真正的界面驱动.我还没决定使用什么特定的框架.任何意见,将不胜感激.

怎么说你.

Answer 1

我认为单元测试现有代码有几个优点

• 回归管理
• 更好地理解代码.测试它会显示你没有预料到的情况下,将帮助定义代码的行为
• 它将指出代码中的设计缺陷,因为您需要对测试定义不当的方法进行测试.

但我认为考虑单元测试代码的缺点更有意思.AFAIK,没有缺点.除了最短的时间周期外,所有花在添加测试上的时间都会为自己付出代价.

Answer 2

单元测试代码的原因有很多.事后我提倡单元测试的主要原因很简单.你的代码坏了,你还不知道.

软件中有一个非常简单的规则.如果没有测试代码,它就会被破坏.这可能不会立即显而易见,但是当您开始测试时,您会发现错误.由您来决定您对发现这些错误的关注程度.

除此之外,单元测试还有其他几个重要的好处,

• 回归测试将变得更简单
• 其他知识渊博的开发人员无法打破您期望的行为
• 测试是一种自我文档形式
• 可以减少未来修改的时间(不再需要手动测试？,减少错误？)

列表可以继续下去.唯一真正的缺点是编写这些测试所需的时间.我相信这个缺点总会被你调试单元测试时可能遇到的问题所需的时间所抵消!

Answer 3

根据"手动测试"出现的错误数量,您可以简单地进行测试驱动的错误修复,根据我的经验,这比通过编写"验尸"单元测试简单地提高代码覆盖率要有效得多.

(这并不是说之后写单元测试是一个坏主意,只是TDD几乎总是一个更好的主意.)

Answer 4

以下是我的一些想法:

优点:

• 随着设计随着时间的推移而不必测试已经移除的方法,节省了时间.剩下的就是真正需要测试的东西.
• 通过添加测试,这有机会审查应用程序中的所有方面,并确定在工作原型准备就绪时可以添加的其他优化.

缺点:

• 为了完成测试所需的大量时间投入,新功能可能会延迟一段时间以生成所有测试.
• 可能已经引入了错误,测试将发现可能导致这比最初计划更长的错误.

重点是添加单元测试允许重构并在应用程序上进行更多润色.

Answer 5

我认为"事后"最大的测试之一就是你可能会有更难的测试时间.如果您编写没有测试的代码,通常不会考虑可测试性,最终编写难以测试的代码.

但是,在您花费额外的时间编写测试并更改代码以获得更好的可测试性之后,一旦您不需要花费大量时间进行调试并检查一切是否正常,您就会对更改更有信心.

最后,您可能会发现之前未捕获的新错误,并花一些时间修复它.但是,嘿,那是测试的原因=)