使用 Spring 2.5 TestContext 测试框架

出自http://tech.it168.com/jd/2008-04-01/200804011118995.shtml

【IT168 技术文章 】Spring 2.5 TestContext 测试框架用于测试基于 Spring 的程序，TestContext 测试框架和低版本 Spring 测试框架没有任何关系，是一个全新的基于注解的测试框架，为 Spring 推荐使用该测试框架。

概述

Spring 2.5 相比于 Spring 2.0 所新增的最重要的功能可以归结为以下 3 点：

基于注解的 IoC 功能；
基于注解驱动的 Spring MVC 功能；
基于注解的 TestContext 测试框架。
Spring 推荐开发者使用新的基于注解的 TestContext 测试框架，本文我们将对此进行详细的讲述。

低 版本的 Spring 所提供的 Spring 测试框架构在 JUnit 3.8 基础上扩展而来，它提供了若干个测试基类。而 Spring 2.5 所新增的基于注解的 TestContext 测试框架和低版本的测试框架没有任何关系。它采用全新的注解技术可以让 POJO 成为 Spring 的测试用例，除了拥有旧测试框架所有功能外，TestContext 还添加了一些新的功能，TestContext 可以运行在 JUnit 3.8、JUnit 4.4、TestNG 等测试框架下。

直接使用JUnit 测试Spring 程序存在的不足

在拙作《精通 Spring 2.x — 企业应用开发详解》一书中，笔者曾经指出如果直接使用 JUnit 测试基于 Spring 的程序，将存在以下 4 点明显的不足：

导 致 Spring 容器多次初始化问题：根据 JUnit 测试用例的调用流程，每执行一个测试方法都会重新创建一个测试用例实例并调用其 setUp() 方法。由于在一般情况下，我们都在 setUp() 方法中初始化 Spring 容器，这意味着测试用例中有多少个测试方法，Spring 容器就会被重复初始化多少次。

需要使用硬编码方式手工获取 Bean：在测试用例中，我们需要通过 ApplicationContext.getBean() 的方法从 Spirng 容器中获取需要测试的目标 Bean，并且还要进行造型操作。

数 据库现场容易遭受破坏：测试方法可能会对数据库记录进行更改操作，破坏数据库现场。虽然是针对开发数据库进行测试工作的，但如果数据操作的影响是持久的， 将会形成积累效应并影响到测试用例的再次执行。举个例子，假设在某个测试方法中往数据库插入一条 ID 为 1 的 t_user 记录，第一次运行不会有问题，第二次运行时，就会因为主键冲突而导致测试用例执行失败。所以测试用例应该既能够完成测试固件业务功能正确性的检查，又能够 容易地在测试完成后恢复现场，做到踏雪无迹、雁过无痕。

不容易在同一事务下访问数据库以检验业务操作的正确性：当测试固件操作数据库时，为了检测数据操作的正确性，需要通过一种方便途径在测试方法相同的事务环境下访问数据库，以检查测试固件数据操作的执行效果。如果直接使用 JUnit 进行测试，我们很难完成这项操作。

Spring 测试框架是专门为测试基于 Spring 框架应用程序而设计的，它能够让测试用例非常方便地和 Spring 框架结合起来，以上所有问题都将迎刃而解。