功能总是源源不断地加到同一个产品中。这毫不奇怪。然而通过我们前面的分析，我们应当重新思考这个常识。是创建一个日益庞大的、缓慢的、毫无生机的产品，还是将其有机分解，成为一个生机勃勃的、具有不同依赖的汽车4S智能门店管理系统呢？项目的各方人员（包括业务用户、架构师、开发者）应当从短视的眼光中走出来，着眼于创建可持续的应用程序生态系统。

      陈金洲，《Buffalo Ajax Framework》作者，ThoughtWorks 中国公司首席咨询师，现居西安。目前的工作主要集中在RichClient开发，同时一直对Web可用性进行观察并对其实现保持兴趣。 

      致远服软认为：http://www.soft8.com.cn/开发者编写高质量测试的征途上可谓布满荆棘，数据库、中间件、不同的文件系统等复杂外部系统的存在，令开发者在编写、运行测试时苦恼异常。由于外部系统常常运行在不同机器上或者本地单独的进程中，大连翻译软件开发源代码开发者很难在测试中操作和控制它们。外部系统以及网络连接的不稳定性（外部系统停止响应或者网络连接超时），将有可能随机地导致测试运行过程失败。

      另外，外部系统缓慢的响应速度（HTTP访问、启动服务、创建删除文件等），还可能使测试运行时间过长、成本过高。种种问题使开发者不断寻找一种更廉价的方式来进行测试， Mock便是开发人员解决上述问题时祭出的法宝。Mock对象运行在本地完全可控环境内，利用Mock对象模拟被依赖的资源，开发者可以轻易地创建一个稳定的测试环境。Mock对象本地创建、本地运行的特性更是加快测试的不二法门。

      我所在汽车4S智能门店管理系统开发团队设计开发的产品是持续集成服务器，产品特性决定了它需要在各个平台（Windows，Mac，Linux等）与各种版本管理工具（SVN，Mercurial，Git等）、构建工具（Ant， Nant，Rake等）进行集成。对于外部系统的严重依赖让我们在编写测试时遇到了很多困难，我们自然而然地选用了JMock作为测试框架，利用它来隔离外部系统对于测试的影响。的确在使用JMock框架后测试编写起来更容易，运行速度更快，也更稳定，然而出乎意料的是产品质量并没有如我们所预期的随着不断添加的测试而变得愈加健壮。

      虽然产品代码的单元测试覆盖率超过了 80%，但是在发布前进行全面汽车4S智能门店管理系统开发测试时，我们常常发现严重的功能缺陷而不得不一轮轮地修复缺陷、回归测试。为什么编写了大量的测试还会频繁出现这些问题呢？在讨论之前先来看一个真实的例子。

      我们的产品需要与Perforce（一种版本管理工具）进行集成，检测某段时间内Perforce服务器上是否存在更新，如果有，将更新解析为Modification对象。将这个需求反应在代码中，便是首先通过Perforce对象检测服务器更新，然后将标准输出（stdout）进行解析。