StrutsTestCase是基于JUnit的Struts动作测试框架。Struts将为测试应用程序的Struts动作类提供简便有效的方法。
典型的J2EE应用程序是分层构建的，其结构如图1所示：
◆DAO层封装数据库访问。其中包括Hibernate映射、Object类、Hibernate查询、实体EJB或其他实体－关系持久化技术。
◆业务层包含更多高级业务服务。理想状态下，业务层相对独立于数据库实现。这一层常常用到EJB事务。
◆表示层向用户展示应用程序数据，并解释用户请求。在Struts应用程序中，该层通常使用JSP/JSTL页面显示数据，并借助于Struts动作解释用户的查询请求。
◆客户端层主要是用户机器上运行的web浏览器。客户端逻辑（比如JavaScript）有时候就置于该层，尽管很难对其进行有效的测试。
视具体架构，DAO及业务层可使用JUnit经典测试法或者各种JUnit扩展工具进行测试。DbUnit就是进行数据库单元测试的好选择。
另一方面，通常很难对Struts动作进行测试。即使业务逻辑完全限定于业务层，Struts动作通常还是会包含重要的数据验证、数据转换和数据流控制代码。如果不对Struts动作进行测试，那么将在代码覆盖率方面留下很大空白。而StrutsTestCase将填补这些空白。
对动作层进行单元测试还会带来其他的一些好处：
◆视图层及控制层设计起来更容易，通常也更为简洁明了。
◆更易于重构动作类。
◆有助于避免冗余和无用的动作类。
◆测试用例有助于编写动作层文档，这些文档在编写JSP页面时可以起到帮助作用。
这些是测试驱动开发的一些常见优点，这些优点适用于Struts动作层，也适用于其他的一些地方。
StrutsTestCase简介
StrutsTestCase提供了在JUnit框架内测试Struts动作的灵活便利的方法。可以通过设置请求参数并检查调用动作后生成的Request或Session状态的方式，来对Struts动作进行白盒测试。
StrutsTestCase支持使用框架来模拟web服务器容器的模拟测试方法，或者在服务器容器（如Tomcat）内使用Cactus框架进行测试的容器内测试方法。一般来说，我更喜欢模拟测试方法，因为这种方法更为轻量级，运行更快，从而可以实现更紧凑的开发周期。
所有StrutsTestCase单元测试类均由模拟测试的MockStrutsTestCase或者容器内测试的CactusStrutsTestCase派生。由于模拟测试方法设置更简单，运行更快，所以在这里我们将主要关注模拟测试方法。
StrutsTestCase实践
为了使用StrutsTestCase测试该动作，我们将创建一个扩展MockStrutsTestCase类的新类。该类提供一些方法，用于构建模拟HTTP请求，调用相应的Struts动作，并在动作完成后验证应用程序的状态。
设想一个用于安排住宿的在线数据库，它带有一个复合条件搜索函数。搜索函数通过/search.do动作来实现。该动作将根据特定条件执行复合条件搜索，并将搜索结果列表置于名为results的属性中，该属性的作用域为请求范围内。比如，下面的URL将会显示法国的所有住宿地列表。
/search.do?country=FR
现在假设我们使用测试驱动方法来实现该方法。编写动作类，更新Struts配置文件。编写测试用例，测试该动作类(空)。采用严格的测试驱动开发方法，首先编写测试用例，再实现符合测试用例的代码。在实际情况中，具体顺序视测试代码不同而有所不同。
初始的测试用例看起来应该如下：
public void testSearchByCountry() {
setRequestPathInfo("/search.do");
addRequestParameter("country", "FR");
actionPerform();
}
在这里，我们设置调用路径(setRequestPathInfo())，并添加请求参数(addRequestParameter())。
接下来，使用调用动作类。这样将会验证Struts配置并调用相应的动作类，但是并不会对动作的实际功能进行测试。为了测试动作的实际功能，我们需要验证动作结果。
public void testSearchByCountry() {
setRequestPathInfo("/search.do");
addRequestParameter("country", "FR");
actionPerform();
verifyNoActionErrors();
verifyForward("success");
assertNotNull(request.getAttribute("results"));
}
文章来源于领测软件测试网 https://www.ltesting.net/