另外一个唯一需要担心的关于第三方代码的是如果你模拟它，你需要真正的理解它的行为-尤其是对那些错误的情形要真正理解。如果一个API方法返回一个错误状态或者抛出一个异常，而你的模仿程序没有模拟它，你就不能针对这个API很好地测试你的代码。另外一个第三方代码的领域涉及到框架和插件容器。在这些情形下，你应当开发你的代码成尽可能不是主人/容器知论，并且分别测试它。Mind-Reader 用户界面在程序开始执行的时候使用WPF作为第三方代码和框架。WPF通常通过事件处理器与你的代码连接在一起，这个事件处理器可能会被认为是松散连接的，但是它代表你必须处理WPF的签名和数据类型（所以当点击按钮的时候，你的事件处理器机会得到一个
Systems.Windows.RouteEventArgs对象它需要处理的）。IMainWindow界面将Mind-Reader程序在主要窗口上作的操作抽象化为：
……………………
测试跨平台系统
这个部分讨论在不同操作系统上有相同行为的系统。我写过一些跨平台的代码，大多是用C++ 写的。很经常，脏乎乎的跨平台问题证实是一个创建问题（错误的标志，错误的依赖性，错误的版本等等）。做跨平台开发的关键是将平台依赖的代码尽可能最少化。这大部分可以通过使用跨平台库和避免直接系统调用来实现。对可能会出异常的用户界面（这个我接下来会讨论），用一个单独的代码基地去开发一个整个的跨平台系统是可能的。
这使得测试变得简单多了。开发者可以在他们的开发系统上跑测试用例直到他们接触到一些平台特定的代码，他们可以很确定说他们的改动在其他系统上行得通。你创建的系统应当考虑到在所有平台上的测试。这个测试取决于你的开发过程。有些团队对每一个变化都会在每个平台上跑测试用例。有些团队有底层测试政策，这里更有扩展性和穷尽的测试用例会周期性地跑起来（比如说，晚上或者在周末时跑）。有些系统必须用用不同的性能来达到各个平台的目标。它可能是多种硬件设备，不同的浏览器，同一操作系统或者浏览器的不同版本，等等。这种情况通常会导致目标平台的组合式爆炸。
你需要首先以好的设计来发布。通常的一个方法是创建灵活的系统，这个系统的性能能够被动态发现或者配置并且能作为插件整合进主系统。从测试角度来看，这种方法也可能会减少测试的负担。如果你有五个可选的性能，而你的目标平台可以提供这些性能中的任何子集，那么你有32个目标要测。但是，如果你可以单独测试每个性能，那么你只需要测试五个。这是和重要的分别。
......
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
