看到了TestApi的东东。 http://www.codeplex.com/TestApi。好像是用于测试和调试WPF的工具。可能是在程序中实现snoop类似功能的东西。
功能点：
1. Input Injection（输入注入？）
模拟用户输入。以下五种模拟方式的拟真度依次递增。
a. Direct method invocation: 通过编程直接调用目标UI Element方法触发事件的测试。比如，用一个能够调用Button.IsPressed方法的测试模拟一个WPF的按钮。
b. Invocation using an accessibility interface (UIA, MSAA, etc. 不知道这些缩写代表什么)： 先创建一个AutomationElement实例用来代表目标UI Element。然后编程调用这个AutomationElement实例上的方法触发事件进行测试。
c. Simulation using low-level input: 这个测试通过使用下层输入模块（facility)来模拟输入。这种下层输入模块是由宿主操作系统（host OS）提供的。Windows上的这些模块的例子有：SendInput Win32 API， Raw Input Win32 API，他们可以直接将输入注入到OS的input stream中。
d. Smulation using a device driver: 使用设备驱动模拟输入。
e. Simulation using a robot：控制一个机器人模拟直接的人类输入行为。（还不如直接用人，测试手机按键的耐久度例外）
TestAPI library 提供了b和c的功能。使用了 AutomationUtilities, Mouse, Keyboard 类.
有几个例子：http://blogs.msdn.com/ivo_manolov/archive/2008/12/15/9223397.aspx
Example 1：发现按钮并点击。Mouse类可以进行鼠标移动操作。
Example 2：发现TextBox并且在其中打字（不知道中文能模拟Typing吗？）
总结：
原文的总结是这个功能很好很强大。
我的总结是：看了一下Example，感觉测试和源程序是混在一起的。不知到能不能将测试单独放在一个工程中。原文中说要设计多层架构，尽量保持Thin UI。我觉得开玩笑，WPF不就是为了设计Rich UI的吗？
TestApi （2）
命令行解析器。感觉似乎和WPF没关系。跳过。
TestApi （3）
界面验证器。有一点用。其实就是抓图，可以抓整个界面，也可抓一个矩形。然后和给定的图片（可以来自文件）一个像素一个像素的对比。
工作量太大，而且不准。可用性不高。
