单元测试 – 关于测试驱动开发的非专利问题

前端之家收集整理的这篇文章主要介绍了单元测试 – 关于测试驱动开发的非专利问题前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我通过测试驱动的开发永远感到好奇,但是当我尝试实际的项目时,我永远都不会跟随它。我有几个哲学问题,在我尝试时不断出现:

>如何处理大的变化?当涉及测试单个功能(一些参数,结果值,很少的副作用)时,TDD是一个没有脑子的。但是当你需要彻底地检修大的东西,如从SAX解析库切换到DOM解析库?当您的代码处于中间状态时,如何保持测试代码重构周期?一旦你开始改变,你会得到一个失败的测试,直到你完成了大修(除非你保持某种类型的使用DOM和SAX的mongrel类,直到你完成转换,但这是非常奇怪的) 。在这种情况下,小步骤的测试代码重构周期会发生什么?在整个过程中,您将不再需要经过小小的,经过全面测试的步骤。人们必须以某种方式处理这个问题。
>当使用mocks测试GUI或数据库代码时,您真正在测试什么?模拟器是为了完全返回您想要的答案而建立的,那么您如何知道您的代码将与现实数据库一起使用?这种事情的自动测试有什么好处?它有助于提高信心,但是a)它不会给您一个完整的单元测试的相同信心,b)在某种程度上,你不是简单地验证您的假设与您的代码一起工作,而不是你的代码与DB或GUI一起工作?

任何人都可以指出在大型项目中使用测试驱动开发的案例研究?令人沮丧的是,我基本上只能找到单一类的TDD示例。

谢谢!

你如何处理大的变化?

随着需要的小。

有时重塑具有很大的表面,但是细节是微不足道的。这些可以在相当大的步骤中完成。投入太多努力试图破坏它们将是浪费的。

我认为XML库更改是在这个类别。您正在将XML放入并获取一些表示。只要您的表示不会更改(从表示状态到事件流的图形),库切换就很容易。

大多数时间重构并不是微不足道的,必须分解。问题是何时做更大的步骤,而较小的步骤。我的观察是,我估计一个变化的影响是不好的。大多数软件都足够复杂,你可能认为它们的改变是易于管理的,但是整个精美的打印件必须重新工作。所以我做了一些改变。但是如果开始变得不可预测,我已经准备好回滚一切。我会说这发生在十分之一的重构中。但这将是艰难的。您必须追踪系统的部分不符合您期望的行为。这个问题现在要分解成多个较小的问题。我一次解决一个问题,检查完成后。 (多次迭代和拆分并不罕见)。

如果您在代码中更改XML解析器和表示形式,那肯定是至少两个单独的重构。

模拟测试

您正在使用模拟对象测试对象/图层之间的通信协议。

整个模拟方法可以作为像OSI model这样的通信模型。当层X获得与参数x的调用时,它将使用参数a和b调用层Z。您的测试指定此通信协议。

与模拟测试一样有用,可以尽可能少地测试功能。最好的选择是基于状态的测试:安装夹具,被测试的调用系统,检查被测系统的状态和纯功能(如功能编程)测试:使用x调用返回a。

尝试以大部分功能松散耦合的方式设计系统。一些功能必须用模拟测试进行测试(完全解耦系统是无用的)。

集成测试是测试系统的选择。它们只能用于测试系统中可能与多个单元的集成中断的方面。如果您尝试使用集成测试来测试系统,您将进入排列赌场。

所以你的GUI测试策略应该是明确的。不能隔离测试的GUI代码的部分应该通过模拟测试进行测试(当按下此按钮时,使用参数y调用服务X)。

数据库浑水一点。你不能模拟数据库,除非你要重新实现你想要支持的每个数据库的行为。但是,当您整合外部系统时,这不是单元测试。我已经与这个概念问题达成和平,并将DAO和数据库视为一个不可分割的单位,可以通过基于状态的测试方法进行测试。 (可悲的是,这个单位的行为与它的MysqL日相比有所不同,而且可能会在中间破裂,并告诉你它不能与自己说话。)

原文链接:https://www.f2er.com/javaschema/282162.html

猜你在找的设计模式相关文章