TDD和单元测试似乎是目前的热门话题。但与其他形式的自动化测试相比,它真的那么有用吗?
直觉地说,我猜想自动化集成测试比单元测试更有用。在我的经验中,大多数bug似乎是模块之间的交互,而不是每个单元的实际(通常有限的)逻辑。此外,回归通常是由于模块之间的接口变化(以及前后条件的变化)而发生的。
我是不是误解了什么,或者为什么与集成测试相比,单元测试得到了如此多的关注?这仅仅是因为我们假设集成测试是您拥有的东西,而单元测试是我们需要学习作为开发人员应用的下一个东西?
或者,与自动化测试的复杂性相比,单元测试只会产生最高的增益?
如果您必须选择一种形式的测试才能在您的下一个项目自动化,它会是哪一种?
提前谢谢。
发布于 2011-01-24 12:44:19
使单元测试非常有用的一个重要因素是快速反馈。
考虑一下当您的应用程序被集成/系统/功能测试完全覆盖时会发生什么(这已经是一种理想的情况,在大多数开发公司中都是不现实的)。这些测试通常由一个专门的测试团队来运行。
这一切可能需要几天甚至几个星期。到目前为止,您已经在处理其他任务,因此您还没有前面编写的代码的详细信息。此外,通常您甚至没有任何直接的证据来证明bug的实际位置,因此查找和修复该bug需要相当长的时间。
而在单元测试(TDD)中
这一切在几分钟内就会发生。
这并不是说集成/系统测试没有用;它们只是服务于不同的目的。有了编写良好的单元测试,您可以在代码中捕获大量的bug,然后再进入集成阶段,在那里查找和修复它们已经花费了很多钱。您是正确的,需要集成测试来捕获那些很难或不可能通过单元测试捕获的bug类型。然而,在我的经验中,这是比较罕见的类型;我看到的大多数bug都是由于方法中某个简单甚至微不足道的遗漏引起的。
更不用说单元测试也测试您的接口的可用性/安全性等,从而为您提供至关重要的反馈,以改进您的设计和API。而IMHO可以大大减少模块/susbsystem集成错误的可能性: API越容易、越干净,误解或遗漏的可能性就越小。
您在自动化单元测试、自动化集成测试和自动验收测试方面有哪些经验?在您的经验中,什么产生了最高的ROI?为什么?
ROI取决于许多因素,其中最重要的可能是您的项目是绿地还是遗产。对于绿地开发,我的建议(和迄今为止的经验)是从一开始就对TDD风格进行单元测试。我相信这是最具成本效益的方法。
然而,在一个遗留的项目中,建立足够的单元测试覆盖范围是一项巨大的任务,将非常缓慢地产生效益。如果可能的话,尝试通过UI通过系统/功能测试来覆盖最重要的功能是更有效的。(桌面GUI应用程序可能很难通过GUI自动测试,尽管自动化测试支持工具正在逐步改进.)。这给了你一个粗糙而有效的安全网。然后,您可以开始逐步建立单元测试围绕最关键的部分应用程序。
如果您只需要选择一种形式的测试来自动化您的下一个项目,它会是哪一种?
这是一个理论问题,我认为这是毫无意义的。各种各样的测试都在一个优秀的SW工程师的工具箱中使用,所有这些都有不可替代的场景。
发布于 2011-01-24 13:34:44
所有类型的测试都是非常重要的,并确保系统的各个方面都符合规范。所以向后看,“如果我必须选择一种测试.”我不会。单元测试给我的反馈不同于集成测试或一个人的交互测试。
下面是我们所做的测试的类型/好处:
可选但建议测试:
为了理解为什么单元测试比集成测试更有优势,您必须了解需要全面的其他测试的数量级。对于单元A的每一个可能的结果,都需要一个测试。单元B也是如此。现在,如果这两种测试一起为一个更完整的解决方案而工作,那么测试的数量是组合的。简而言之,要测试单元A和单元B之间的相互作用的每一个排列,就需要进行A*B测试。加上单元C,三组测试的次数将为A*B*C。
这就是接口和对象边界的概念变得非常重要的地方。接口表示特定的契约。接口的实现者同意它将以某种方式运行。同样,接口的使用者同意它将以某种方式使用该实现。通过编写收集实现接口的每个类的测试,您可以轻松地测试每个实现是否遵守接口契约。这是等式的一半。另一半是测试消费者方面--这是模拟对象进入游戏的地方。模拟被配置为确保交互始终在规范中。此时,所需要的只是进行一些集成测试,以确保实现者/使用者契约的正确性。
发布于 2011-01-24 12:33:32
这些是具有不同目标的不同工具:
需要记住的一点是,您不能真正使用集成测试进行设计,也不会发现单元测试的回归。
https://softwareengineering.stackexchange.com/questions/39368
复制相似问题