按着上面的原则，应付正常模块的测试没有问题了，但是下面三种情况仍会让你觉得比较棘手。
(1) 带有GUI的应用程序。有GUI的程序会给自动的数据输入和结果检查带来麻烦，有些工具可以部分解决这个问题
，特别是针对Win32下的GUI，因为我很少在 Windows下写程序，所以对这方面了解不多。不过最好的办法还是用MVC模型
等方式分离界面和实现，因为界面通常相对比较简单，可以手工测试，而实现的逻辑比较复杂，这部分可以自动测试。
后面我们会专门讲解分离界面和实现的方法。
(2) 有随机数据输入。如果有些输入数据是内部随机产生的（比如游戏中随机的步骤和无线网络信号的变化等），
那你根本无法预测它的输出结果和影响。对于我们可以控制的随机数据，可以提供额外的函数去获取这些数据。对于无
法控制的随机输入数据，可以把它们隔离开，即在自动测试中使用固定的数据。
(3) 多线程运行的程序。多线程的程序也很难自动测试，比如向链表中插入一个元素，当你检查的时候，根本不能
确定链表的长度是否增加，也无法知道处于刚才插入位置的元素是否是你插入的元素，因为这个时候，可能有另外一个
线程已经把它删除了或者加入了新的数据。不过在单线程的自动测试通过之后，多线程的问题会大大减少，剩下的问题
我们可以通过其他方式加以避免。
写自动测试程序会花费一些时间，但这项投资能带来最大的回报：减少后面调试时的浪费，提高代码的质量，更重
要的是，你终于可以睡个安稳觉了。
2.5 Save your work
“Ernst和Young所在的小组决定使用正规的开发理论——他们常用削减法，分阶段进行开发并具有中途交付能力。
他们的步骤包括细致的分析和设计——正如本章描写的基本原则一样。而其他竞争者径直开始了编码，在开始几个小时
里，Ernst和Young小组落后了。但到中午时，Ernst和Young小组却遥遥领先了，而到了这一天结束的时候，他们却失败
了。导致失败的原因不是因为他们使用了正规方法，而是他们偶然出错把工作文件覆盖了，最终他们比午餐时所做的估
计少交付了一些功能，他们败在了没有使用有效的源程序版本控制这个典型的错误上。”
前段时间看探索频道的“荒野求生秘技”（Man & Wild），我很喜欢这个节目也喜欢节目里的那个英国人，甚至连
重播都不会放过。他在这个节目里展示了在沙漠、丛林、冰河和雪山等各种环境的求生秘技，他吃过蜘蛛、白蚁、蝎子
阅读(190) | 评论(0) | 转发(0) |
