上一篇已经就准备环境谈了很多，清理环境就显得轻松一点，但是问题和影响还是会出人意料。
占用有限资源的测试尤其容易出问题。一个接一个的测试用例如果没有恰当的释放占用的资源，就会让后面的某个测试用例失败，而且是随机的一个，这种失败让人摸不着头脑。例如数据库的连接，注册表项，甚至是临时文件忘了删除也是个问题。
跟准备环境一样，清理环境也有类似的测试模式。
● 永久准备
■ 道理跟准备环境时一样，把环境重设为一个固定状态。很多时候根本就是准备环境和清理环境的代码是共享的。
● 回滚清理
■ 这个跟数据库里面的回滚（rollback）原理是一致的，如果准备环境时执行的步骤之间存在依赖，清理环境时就得顾及这个依赖。
■ 你可以理解为反洋葱头清理，如果准备环境时以ABCD…的顺序初始化，清理的时候就以…DCBA的顺序清理。通常洋葱头类的协定是先执行基类的函数，那么反洋葱头类的协定则是最后执行基类的函数。
● 垃圾收集清理
■ 运用类似垃圾收集的原理，测试用例执行过程中产生的各种资源占用都会被登记在册，直到清理阶段逐一清除。
■ 比如为了调试和诊断产生了不少文件，虽然这些文件是需要保留的，但多个测试用例执行之后它们产生的文件就会相混淆，所以产生的文件需要被归档整理后删除，哪些文件需要这么做呢？可以用垃圾收集方法登记起来，最后统一处理。
不好好做清理环境的后果可以是
● 单个执行测试用例没问题，全部一起执行则无法全部完成。
● 增加、删除测试用例或者改变测试用例的执行顺序则无法全部完成。
● 某些测试用例失败之后其它不该失败的测试用例也失败了。
● 一次全部测试用例执行之后无法再全部执行一次。
● 对于同一个测试用例的集合分散在多台机器上执行时，有些测试机器能全部完成，有些则不行。
调试和诊断这类问题费心费力，而且没有任何价值，因为设计良好的清理环境就可以避免这些问题。
相关链接：
