“没有人喜欢bug。”大多数关于单元测试的文章以这句话开篇。的确，我们都希望代码如设计的那样准确地执行，但是就好像叛逆孩子一样，程序在完成之后产生的行为将难以控制。比那些家长们幸运的是，我们可以运用工具以确保程序达到预期效果。 市面上有很多用于测试，分析以及debug程式的工具，其中以JUnit最为有名。这是一个协助软件工程师，QA（品质监管）工程师测试阶段性代码的平台。几乎每个接触过JUnit的人都对它有强烈的感情:要么喜欢，要么讨厌。主要的抱怨之一是它缺少做复杂场景测试的能力。 通过突破传统模式的思考，这一问题可以得到解决。这篇文章将介绍JUnit如何利用Pisces来实现复杂测试。Pisces是一个开源项目，作为JUnit的扩展，它可以让你写出由一些JUnit测试组成的测试单元，每个测试单元可以以串行或并行的方式运行在一个远程主机上。Pisces可以让你构成、运行复杂场景，并在一个地点协调它们。 JUnit基础 JUnit中有两个基本对象，TestCase和TestSuite。TestCase通过提供一组方法来实现一系列测试。例如，setup()方法用来在每项测试开始前建立测试所需的测试环境，而teardown()方法用来在测试后销毁该环境。其他的方法都会完成各式各样的任务，例如，在测试中进行性能检测，判断变量是否为null，比较变量以及捕捉异常。 要创建测试程序，需要继承TestCase类，覆写setup和teardown方法，然后添加自己的测试函数，这些函数通常以“test测试名”的形式命名。 下面是一个测试程序的例子： public class MyTestCase extends TestCase {     /**     * call super constructor with a test name     * string argument.     * @param testName the name of the method that     * should be run.     */     public MyTestCase(String testName){         super(testName);     }          /**     * called before every test         *  在每项测试开始前被调用     */     protected void setUp() throws Exception {         initSomething();     }              /**     * called after every test         *  在测试完成后被调用     */     protected void tearDown() throws Exception {         finalizeSomething();     }              /**     * this method tests that ...     *  这个方法测试……     */     public void testSomeTest1(){     ...     }              /**     * this method tests that ...         *  这个方法测试……     */     public void testSomeTest2 (){         ...     } } TestSuite是由几个TestCase或其他的TestSuite构成的。你可以很容易的构成一个树形测试，每个测试都由持有另外一些测试的TestSuite来构成。被加入到TestSuite中的测试在一个线程上依次被执行。 ActiveTestSuite是TestSuite的一个子类。被添加到ActiveTestSuite中的测试程序以并行方式执行，每个测试在一个独立的线程上运行。创建一个测试单元的方法之一是继承TestSuite类并覆写suite()方法。 下面是一个简单的例子： public class MyTestSuite extends TestSuite {     public static Test suite() {         TestSuite suite =             new TestSuite("Test suite for ...");                          // add the first test         // 添加第一个测试         MyTestCase mtc =             new MyTestCase("testSomeTest1");         suite.addTest(mtc);                          // add the second test         // 添加第一个测试         MyTestCase mtc2 =             new MyTestCase("testSomeTest2");         suite.addTest(mtc2);                          return suite;                      }          } 运行一个测试或测试单元非常简单，因为从JUnit提供的GUI开始，到所有的IDE开发环境，例如Eclipse，都有GUI可以使用。 图1, 显示了TestSuite在Eclipse中是如何表示的。 图1，集成在Eclipse中的JUnit 因为介绍JUnit并不是这篇文章的主题，而且有很多关于JUnit的文章，本文就只提供这些JUnit基础概念的概要。在“资源”小节里有对JUnit更深入介绍的文章。 JUnit的优点和缺点 JUnit是一个易用的，灵活的，开源的，测试平台。就像所有其他项目一样，它有很多优点，但也有不足之处。通过使用无需人工干预的JUnit自动测试平台，我们很容易累积起大量的JUnit测试程序从而保证以往的bug不会重现。另外，JUnit便于和编译单元（如，Ant）以及IDE单元（如，Eclipse）集成。 JUnit的弱点也众所周知。它仅支持同步测试，而且不支持重现和其他异步单元。JUnit是一个黑箱测试平台，因此测试那些不会直接影响功能的bug（例如，内存泄漏）就非常困难。除此之外，它不支持易用的脚本语言，因此，想要使用JUnit就要懂得Java。 JUnit的另一个不足是JUnit测试被限制于一个JVM之上。当要测试复杂或分布式场景的时候，这就变成个大问题。本文剩下的部分，就这个问题及其解决方法进行论述。 复杂场景测试： 我们为什么需要测试复杂的分布式场景？ 1. 那些确保小单元的完整性的测试很有用，但同时也有局限性。经验告诉我们，大多数bug是在完整的测试中被发现的。这些问题从两个模块不能一同正常协调工作，到两个独立应用程序的异常。无论这是两个应用服务，还是客户/服务环境，甚至是点对点模式，对这些复杂场景的测试尤其重要，因为那些难缠的bug往往寄生于此。但是用JUnit对此几乎无能为力。 2. 虽然Java具有平台无关性，但测试一个应用程序在多种操作系统上的表现还是一个明智的选择。你的程序可能在所有的操作系统上都能运行，但是却不一定严格地按照你设计的那样正常工作。在所有的操作系统上重复同样的一组测试程序是一件耗时的工程，而用JUnit你不能进行分布式测试，因此你无法让同样的一组测试同时运行在几个JVM之上，而每个JVM运行在不同的操作系统之上。 3. 一些单元代码，只能在多JVM场景下被测试。例如，测试建立一个连接（TCP socket或者HTTP连接）以及从中取得的信息的完整性。这样的测试不可能（或者说很难）在单一JVM上测试。而这是JUnit给我们的唯一选择。 用Ant协同测试 仅使用JUnit和Ant来协调几个运行在不同JVM上的测试是可能的。Ant可以以并行或者串行的方式执行任务（使用<parallel>标记），而且可以设置当有任何测试失败的时候，就停止运行。 但这种方法有其局限性，首先，使用JUnit和Ant仍然把你限制在一个操作系统之上。其次，随着你的测试程序的累积，你会发现Ant XML文件会变得越来越大，以至于无法管理。第三，我们发现在某些情况下，分支JVM会在Ant任务结束后保留下来甚至继续运行。 Pisces项目就是为了解决JUnit的这些限制而来的，它给予JUnit复杂场景和分布式测试的能力。本文下面的章节将介绍这个开源项目。 利用Pisces打破JUnit的局限 Pisces基础知识 Pisces是一个开源项目，它扩展了JUnit平台。就像许多其他的扩展程序一样，Pisces添加了新功能的同时也保证了扩展前后JUnit操作的一致性。 Pisces的核心是在同一主机或不同主机上实现在远程JVM上运行JUnit测试的能力。这些远程测试程序会封装在本地运行的JUnit测试程序中，因此开发人员或者QA（品质测试）人员可以用通常的JUnit GUI工具来运行这些通常（本地）的测试程序。用来包装远程测试的对象叫做RemoteTestCase，它也是TestCase册子类。 图2显示的是远程测试程序和它的包装器。 图2,远程测试和它的包装器 在每一个远端，我们运行一个Pisces代理程序，并指定唯一的代理名。这个代理负责运行实际的JUnit测试程序并将结果返回到本地。现在，一旦我们能运行一个包装在本地测试中的远程测试程序，我们就能通过组合几个这样的测试来创建一个更为复杂的场景。 图3, 由几个远程测试组成的测试单元 改变默认输出 每个代理运行一组测试程序，而每个测试程序都可能写信息到默认输出。因为保证测试人员或开发人员在测试过程中得到这些信息很重要，所以默认输出被拷贝到本地测试单元的控制台中。这样，便可以避免在测试单元中查看每个代理的控制输出。 Pisces的可扩展通信层 在各个代理及本地主测试程序之间的通信是件复杂的事情，因为Pisces必须能在各种不同的环境以及网络配置下正常工作。为了解决这一问题，Pisces有一个可以扩展的通信层。它的每一个实现解决一个指定的网络环境下的问题。 Pisces提供两个默认的基本通信层，一个是易于配置但只能工作在局域网内的multicast实现，另一个是JMS实现。它需要安装面向消息中间件/消息导向中间件（MOM, Message-Oriented Middleware），可以应付大多数网络环境。 配置并运行Pisces测试 1.配置并运行Pisces代理 正如前面所提到的，Pisces测试单元是由几个运行在远程代理之上的Junit测试程序组成的。每个代理都是一个Java应用程序，它根据从主测试程序接收的指令来运行JUnit测试，并将结果及默认输出返回到主测试单元。 运行代理程序最简单的方式是在Pisces提供的脚本文件夹中配置并运行相关的可执行脚本。此外，你也可以在已经提供的脚本的基础上构建你自己的脚本。脚本文件容许用户配置代理的通用参数，例如唯一标识符，为通信层指定multicast IP地址和端口。 下面是一个代理程序的脚本文件，该代理程序提供了通信层，并运行在Linux系统上：（下面是一个运行在Linux系统上的，具有通信层的代理程序的脚本文件） #!/bin/sh # the folder were the agent can find junit.jar export JUNIT_HOME=/opt/junit3.8.1 # the folders were the agent can find # the junit tests export JUNIT_TEST_CLASSPATH=../examples/ # the multicast port that the communication # layer uses export PISCES_MCP=6767 # the multicast IP that the communication # layer uses export PISCES_MCIP=228.4.19.76 # the unique name of the agent export AGENT_NAME=remote1 java -classpath     "$JUNIT_HOME/junit.jar:../pisces.jar:$JUNIT_TEST_CLASSPATH" \     org.pisces.RemoteTestRunnerAgent \     -name $AGENT_NAME -com multicast \     -mcp $PISCES_MCP  -mcip $PISCES_MCIP 利用JMS通信层的Pisces代理的可执行脚本和multicast方式的差不多是一样的。JMS通信层以装载类的名字作为参数，该装载类返回你的JMS提供者的ConnectionFactory。 2.配置并运行Pisces-Enabled测试单元 在配置并运行了所有相关代理后，我们还需要配置并运行我们的Pisces-enabled测试单元。 首先，我们需要把通信层的配置添加到我们的TestSuite的开头。显示如下： // create the multicast communication layer MulticastRemoteTestCommunicationLayer com =     new MulticastRemoteTestCommunicationLayer(        RemoteTestRunner.name ,"228.4.19.76",6767); // set the communication layer RemoteTestRunner.setCom(com); 接下来，我们需要创建一个TestSuite的实例，并添加想要远程调用的测试。这一步骤可以通过指定JUnit类（有一个可选的测试方法）和将要运行这一特定测试的代理的名字来实现。 下面是一段示例代码： // 创建一个通常的TestSuite实例 TestSuite suite =     new TestSuite("Test for org.pisces.testers"); // 为这个实例创建一个包装器 RemoteTestCase rtc =     RemoteTestCase.wrap(RemoteTestTestCase.class         ,"someTestMethod", "remote1");         // 添加测试实例到TestSuite suite.addTest(rtc); 文章的下一节，将提供一个分布式测试的例子和TestSuite的代码。 示例：并发登录测试 假设我们有一个网络应用程序。一个用户登录后，获得服务，然后退出。我们想确认我们的安全模块能够阻止单一用户在两台不同的电脑上同时登录。 我们创建了一个名字为MyTestCase的测试对象，正如前面所表示的，我们有两个测试方法。第一个，testLogin()，用来确认我们第一次能正确登录。第二个方法，testLoginFails()，用来确认第二次登录时会失败。 下面是利用了Pisces的测试单元： public class RemoteTestSuiteExample extends TestSuite {     public static Test suite() {         // 配置并启动通信层         JMSRemoteTestCommunicationLayer com = null;         try {             com =                 new JMSRemoteTestCommunicationLayer                     (RemoteTestRunner.name,                         new MantaConnectionFactory());         } catch (JMSException e) {             throw new RuntimeException(e);         }         RemoteTestRunner.setCom(com);         // 实例化JUnit         TestSuite suite =             new TestSuite("Test for org.pisces.testers");                  // 在远程代理remote1上运行MyTestCase类中的testLogin           RemoteTestCase rtc =           RemoteTestCase.wrap(MyTestCase.class,                 "testLogin", "remote1");         suite.addTest(rtc);         // 在远程代理remotel2上运行MyTestCase类中的testLoginFails方法         RemoteTestCase rtc1 = RemoteTestCase.wrap(MyTestCase.class,                 "testLoginFails", "remote2");         suite.addTest(rtc1);         return suite;     } } 如果一切正常，远程代理（remote1）将成功登录。当另外一个代理（remote2）试图以同一个用户名和密码登录的时候，将失败，因为该用户已经在另外一台电脑上登录了。 这个测试可以更为复杂。例如，通过添加testLogOut()方法来实现其他的安全测试，但是作为一个示例程序，我希望其保持简单。 在这个例子中，我利用了叫做MantaRay的无服务JMS，它是一个开源的，消息中间件包，基于点对点的技术。在最新一版的Pisces中，你可以找到几个利用JMS通信层的例子和利用multicast通信层的例子。 结论 Bug并不好玩，但是借助JUnit，一个被广泛利用的，开源的，自动测试的平台，运行多重测试变得容易了许多。许多项目扩展了JUnit的功能，但是到目前为止，测试还被局限在一台机器上。有了Pisces的辅助，和一些不同以往的思考方式，我们终于可以创建复杂的，分布式测试了。 转http://www.onjava.com/pub/a/onjava/2005/07/13/pisces.html