【IT168 评论】

　　1、测试数据/运行数据的互不影响

　　在做测试时，通常都需要生成测试数据，在测试运行完后又要进行测试数据的删除工作，当测试和运行用的是同一个库的情况下就很容易出现测试数据和运行数据互相影响的现象，这个时候在写测试的时候就要特别的注意了，既不能让运行数据影响了测试的结果，又不能让测试数据影响到了运行数据。

　　通常来说，为了解决这个问题，会采用测试库和运行库分开的方式，采取这种方式的情况下就比较简单了，不过有些时候还是挺麻烦的，毕竟要创建数据、删除数据。

　　还有一种特殊的情况，例如一个这样的项目：

　　项目已经上线运行了，这个时候做了一个新的流程，在部署了新的流程到运行环境后，通常需要在运行环境中测试一下，这个时候问题就出现了，测试数据和运行数据并行，这个时候就要充分的考虑测试数据和运行数据的互不影响。

　　当然，上面的项目的情况是一个比较特殊的情况，就像有些朋友说的，项目规划的好的话是会有测试环境和运行环境的不同的，测试环境需要和运行环境完全一致，在有新增的东西需要部署到运行环境时先在测试环境进行测试，测试没问题后再通过升级脚本部署到运行环境中。

　　这些方法确实是可以解决测试数据/运行数据的互相影响的问题，不过觉得还是有些的麻烦，觉得如果有一个工具可以帮忙避免测试数据/运行数据的互相影响，同时又可以让你在写测试的时候很容易的创建测试数据，又不用担心其他测试数据或运行数据对它造成影响，最后测试数据又可以安全的被清除，^_^，有个这样的工具就好了.........

　　或者说大家在实际中碰到测试数据/运行数据并行的情况下会怎么办呢?……

　　2、单元测试

　　一直以来都实行TDD，不过发现我做单元测试的方法仍然不正确，尽管在测试的基本原则——"测试一定情况下单元的执行是否和预期一致"上是正确的，但进行单元测试的方法并不正确，就像有的朋友所说，我做的是集成测试，因为我做单元测试时会去把该单元依赖的其他的对象所需要的东西也去进行模拟，这样说起来可能过于生涩了，举个例子吧：

　　有一个服务类，该服务类依赖一个Dao类，通过Dao从数据库中获取相关的信息后进行处理，我以前做单元测试的做法就是首先产生出测试数据，由Dao先将测试数据进行持久，之后再通过调用服务类的方法去执行，"一定的情况"通常都是由测试数据来控制，这点没什么不对，就是控制所测试的单元的输入。

　　测试的基本原则都是检查在一定的输入的情况下输出是否符合预期，作为单元测试而言上面的做法不正确的地方就是去产生测试数据并由Dao先持久，其实作为单元测试而言，只需要测试当前对象执行的正确性，也就是说它已经假设了它所依赖的其他的对象产生的结果，这样的单元测试才是有意义的，而且也变得更容易写了，之前我所采用的那种测试其实是集成测试……

　　这样说了后其实就很容易理解单元测试了，仍然是上面的服务类，它的单元测试的写法应该是去Mock出Dao执行的结果，当然，这个时候就要模拟Dao在返回几种情况下服务的执行情况了，这个是正常的，就是去控制服务的输入，这样可以看到，其实在单元测试中是不会出现多少测试数据的情况的，除了 Dao，而且也不用去关心其所依赖的对象的执行的正确与否，以及所依赖的对象是不是还依赖别的对象，可以保证测试的范围就是本单元。^_^

　　这样做的潜在好处还在于会促进面向接口的编程……

　　3、集成测试

　　集成测试就是需要创建出所依赖的对象的环境的一种测试方法，其实在有了单元测试的情况下，集成测试就可以完全的从系统的入口进行测试，例如B/S系统来讲，它的入口都是页面，也就是我们可以通过页面来进行测试，这个时候可以看到，测试数据的问题又产生了……

　　当然，对于有些集成测试是需要编写代码的，这个时候就需要创建出入口对象所依赖的对象(以及它所依赖的对象)的环境，最后才能调用入口对象的方法进行测试，这样就完成集成测试了。