>如何处理大的变化？当涉及测试单个功能(一些参数，结果值，很少的副作用)时，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日相比有所不同，而且可能会在中间破裂，并告诉你它不能与自己说话。)
