dev2dev 首页 > 资源中心 > 技术文章
对WebLogic Workshop 8.1应用程序进行单元测试
--BEA WebLogic Workshop的示例扩展
在本文中，我将描述如何使用JUnit对在WebLogic Platform 8.1上开发的应用程序进行单元测试。我将说明如何在应用程序开发期间为一般WebLogic
Platform应用程序的所有组件编写和运行单元测试。本文面向那些计划把JUnit集成到WebLogic Platform中去的开发人员和架构师精英。
单元测试是迭代开发过程中的关键实践。软件工程师通过单元测试在代码级别上测试代码。单元测试的运行频率通常很高，因此特别适合于自动化运行。在本文中，我将讨论如何使用WebLogic
Platform 8.1编写和运行单元测试。我将说明如何使用JUnit测试所有的WebLogic Platform组件，不论这些组件是位于服务器容器内部还是外部。
我将假定您对单元测试的原理有一些基本的了解，并熟悉JUnit框架。您可以在JUnit的Web站点 http://www.JUnit.org/上找到关于这两个主题的更多信息。
在本文中，我将首先讨论关于如何集成JUnit和WebLogic Workshop的一些基本集成问题。特别地，我将指出JUnit测试用例在WebLogic
Platform应用程序中的位置，并讨论在WebLogic Workshop中运行这些JUnit测试的各种方式。接下来，我将讨论如何测试特殊类型的组件。
文件布局
因为JUnit测试用例只是标准的Java类，您可以把它们放在您应用程序中几乎所有类型的项目中。当对没有直接从服务器的虚拟机中公开给外部的组件进行测试时，您的测试类需要在服务器中是可访问的，这意味着它们应该是构建在您的APP-INF/lib目录中的web项目或Java项目的一部分。
注意，有一点很重要，即将您的应用程序部署用于生产时，您很可能不想把您的测试类包括在内。如果您在单独的测试项目中保留您所有的测试，您可以在编译时把这些项目排除在外。
在WebLogic Workshop中运行JUnit
在Workshop中启动JUnit进程有多种不同的方法。尽管根据您应用程序的设置和使用情况，有一些方法可能多少有些不方便，但是这与您使用的实际方法没有特别的关系。当然，如果您愿意，您还可以从命令行单独启动JUnit。
不论用于启动JUnit的方法如何，它都将在您的主目录中创建一个.Junitsession文件，以记住您先前已经运行过的测试。尽管直接运行测试要比首先启动JUnit然后从组合框选择测试仍然要更加方便一些，但是因为您不必在首次运行测试类之后重新输入它的名称，在启动时将测试类名称传递给JUnit就显得没那么重要了。
使用main() 方法和Start 按钮
如果在Java项目中保存JUnit测试，您可以配置WebLogic Workshop以使用Start按钮来运行您的测试。您必须给测试类一个main()方法，它负责启动您选择的JUnit运行器。如果您尚未为项目配置调试器设置，点击Start按钮，然后Workshop将询问您是否想要把当前类设置为主类。您也可以转到Tool-->Project
Properties…-->[Test project]，然后从列表中选择Debugger。确保Create new process单选按钮被选中，然后填入您的测试类名称。
假定您想要关闭JUnit的重载类装载器，您的main()方法可能是这个样子：
| String[] JUnitArgs = new String[] { "-noloading", TestCase.class.getName()
};JUnit.swingui.TestRunner.main( JUnitArgs ); |
假定您让您的类路径设置包括所有的运行时依赖，就可以运行了。这还允许您调试运行在JUnit进程中的代码，所以当测试失败时，进行跟踪是很方便的。
使用外部工具
Workshop为通过IDE运行第三方程序提供了一种方法。转到Tools-->IDE Preferences… ，并在列表中选择Tools 节点。您可以创建一种新的工具配置来运行JUnit。只要设置用于启动JUnit的完整命令行即可，其中包括一个-classpath参数,
并给它一个可在其中启动进程的可用目录。例如，如果您的应用程序位于c:\wlw_app中，而且您已经在c:\bea 目录中安装了WebLogic Workshop，您可以使用c:\wlw_app
作为该目录。假定您要测试的代码位于一个名叫JavaProject的Java项目中，而您的测试代码位于一个叫做UnitTestProject的单独Java项目中，而且您已经在叫做somePackage.MainTestSuite的类中定义了一个TestSuite，那么命令格式应该像下面这样：
| c:\bea\jdk141_05\java.exe -classpath c:\wlw_app\APP-INF\lib\JUnit-3.8.1.jar;
c:\wlw_app\APP-INF\lib\UnitTestProject.jar; c:\wlw_app\APP-INF\lib\UnitTestProject.jar;
JUnit.swingui.TestRunner -noloading somePackage.MainTestSuite |
通过在IDE中选择菜单Tools-->External Tools-->[JUnit Tool Name]，您可以很容易地运行JUnit。
使用Ant
Ant 为运行JUnit测试提供了另一个可选任务。对Ant的调用可能像下面这样：
<target name="test">
<JUnit haltonerror="yes" fork="true">
<test name="JPFTest" />
<classpath>
<pathelement location="＄{app.local.directory}/APP-INF/lib/JUnit-3.8.1.jar"/>
<pathelement location="＄{app.local.directory}/APP-INF/lib/JPFTestProject.jar"/>
<pathelement location="＄{app.local.directory}/APP-INF/lib/htmlunit-1.2.3.jar"/>
<pathelement location="＄{app.local.directory}/APP-INF/lib/nekohtml-0.7.7.jar"/>
<pathelement location="＄{app.local.directory}/APP-INF/lib/commons-logging-1.0.3.jar"/>
<pathelement location="＄{app.local.directory}/APP-INF/lib/commons-httpclient-2.0.jar"/>
</classpath>
</JUnit>
</target> |
如果您通过External Tools或者Ant方法来运行JUnit，您仍然可以从 IDE 连接到 JUnit 进程以便调试它。首先，在您的Workshop应用程序中创建或选择一个Java项目。它并不一定需要包含用于您的测试的代码。来到它的Project
Properties，并配置调试器设置为连接到一个您选择用于运行JUnit测试的机器端口。然后，启动JUnit进程，将正确的参数传递给它的Java Virtual
Machine，以开始监听调试器的连接进程，一般的格式如下（这里的SELECTED_PORT应该用在其上监听调试器的端口来替代）：
| -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=SELECTED_PORT,suspend=y,server=y |
尽管虚拟机将会启动，它不会开始运行测试，直到调试器连接上为止。在IDE中，打开您已经为其配置调试器设置的Java项目中的一份文档，然后点击Start按钮。调试器应该快速连接到该进程，而JUnit应该开始执行测试。
您还可以使用Ant生成基于您的测试结果的报告。要想了解关于如何集成Ant和JUnit的更多信息，请查看Ant手册(http://ant.apache.org/manual/index.html)中Ant
Tasks主题的Optional Tasks 部分。
禁用 JUnit 重载
默认情况下，JUnit的Swing接口使用类装载器在运行测试之前自动重新装载类。这很方便，因为您不需要在重新编译您的类之后重新启动JUnit。然而，我过去曾在某些情况下遇到过有关类装载器的工作方式的问题，它们引起了假的ClassCastExceptions异常和其他我不愿意看到的问题。从脚本、通过Ant或从External
Tools运行JUnit时，您可以禁用特殊的类装载器，具体方法是传入-noloading参数。如果您在测试类中使用了main()方法，您可以使用下面的代码达到同样的目的（这里的YourTestClass应该用测试类的名称来替代）：
| public static void main( String[] args ) { String[] JUnitArgs = new String[]
{ "-noloading", YourTestClass.class.getName() }; JUnit.swingui.TestRunner.main(
JUnitArgs );} |
对外部可测试组件进行单元测试
现在，让我们转而讨论如何对WebLogic Platform组件进行单元测试。在讨论中，我将指出内部可测试组件和外部可测试组件的差别，这是我要讨论的第一个话题。对于此处的讨论来说，外部可测试组件是指那些可以从J2EE容器外部（通常是通过HTTP）调用的组件。编写测试时，您的测试用例可以初始化一个到服务器的网络连接，把相应的请求发送给它，然后验证服务器的响应是否正确。
Java Page Flows（JPF）、Java Server Pages(JSP）和Servlet
测试Web站点时，您的测试本质上是模拟浏览器从服务器请求一个或一系列页面。根据所涉及的站点，您需要创建正确的HTTP请求，包括相关的URL、头、参数、cookie，等等。一旦服务器做出响应，您将需要检查响应的内容，包括头、HTML本身、客户端的JavaScript和cookie。有两种一般的方法可以完成这项工作。
使用代理
首先，您可以使用代理来记录普通web浏览器和服务器之间的交互。在仔细检查页面的正确顺序和手动验证结果的正确性之后，您可以使用上述记录自动回放同样的请求序列，并验证结果是否相同。有许多使用这种方法的包，包括MaxQ
(http://maxq.tigris.org/)
和QuickTest (http://www.mercury.com/us/products/quality-center/functional-testing/quicktest-professional/)。
这种方法可以非常快速地生成一组测试，但是很不幸它非常脆弱。一旦您修改页面的布局方式，那么测试中断的风险就很高。对于布局不断变化的站点来说，这意味着您很可能不得不定期重新记录您的测试。
对象模型
第二种方法是使用一种更加有计划性的技术，即编写测试来构建对象，该对象用于请求HTTP请求、到达服务器并取回代表HTTP响应的对象。尽管这种方法的工作量比使用代理记录会话要大，但是受到HTML布局影响而中断的可能性更小。包括HTTPUnit
(http://httpunit.sourceforge.net/)、HTMLUnit
(http://htmlunit.sourceforge.net/)和jWebUnit
(http://jwebunit.sourceforge.net/A
在内的几个库都提供用于模拟浏览器交互的API。
页面流示例
为了举例说明对象模型方法，让我们看一看HTMLUnit。它的API为服务器返回的HTML页面提供一个对象模型。每个请求返回一个HtmlPage，然后您可以查询它的内容。找出页面中的链接之后，您可以模拟一个用户在浏览器中点击它，然后它会返回另一个HtmlPage。类似地，您可以定位页面中的表单、找出特定的字段、设置值，然后提交给服务器。
HTMLUnit 使用Rhino JavaScript引擎，让您可以测试页面中的脚本。然而，要注意有一点很重要，即它只支持大多数浏览器支持的JavaScript的一个子集，而且JavaScript的行为总是至少有些依赖于浏览器。
为了演示如何测试一个web站点，我使用了WebLogic Workshop 8.1 SP2 SamplesApp中的multipleForms页面流。在下载的代码中，您可以在JPFWebProject项目中找到它。测试包括的流部分有两个文本字段。在其中输入值并点击提交按钮之后，这些值就会显示在后续的页面中。
用于这个例子的JUnit 测试用例是{JPFTestProject}/JPFTest.java。如上所述，它有一个main()方法，这样您就可以通过点击IDE中的Start按钮来运行它。测试方法的相关代码如下：
public void testPageFlow() throws Exception {
WebClient webClient = new WebClient();
HtmlPage page = (HtmlPage)webClient.getPage(
new URL( "http://localhost:7001/JPFWebProject/multipleForms/multipleFormsController.jpf"
) );
HtmlAnchor anchor = page.getFirstAnchorByText( "Show
the JSP with blank form fields." );
HtmlPage page2 = (HtmlPage)anchor.click();
HtmlForm form = (HtmlForm)page2.getFormByName( "form1"
);
Iterator elements = form.getAllSubmittableElements().iterator();
int count = 1;
while( elements.hasNext() ) {
HtmlElement element = (HtmlElement)elements.next();
assertTrue( element instanceof HtmlTextInput
);
HtmlTextInput textInput = (HtmlTextInput)element;
textInput.setValueAttribute( "Value"
+ count++ );
}
HtmlPage page3 = (HtmlPage)form.submit();
String pageText = page3.asText();
assertTrue( pageText.indexOf( "Field A = \"Value1\""
) != -1 );
assertTrue( pageText.indexOf( "Field B = \"Value2\""
) != -1 );
}
|
测试本身是相当直观的。它首先创建了一个WebClient对象，该对象负责响应Web浏览器。然后，它发出一个请求给页面流的URL所代表的服务器。测试查找带有文本“Show
the JSP with blank form fields”的链接。它点击链接，然后在结果页面中定位表单。在通过表单元素进行迭代和给它们赋值之后，测试提交了表单，并在结果页面中查找这些值。
如果您要在您的站点上使用NetUI，要小心标签库通常不会为表单元素生成非常简单的名称。通常这没有关系，因为无论是作为开发人员的你，还是最终用户都不需要关心名称，但是当编写测试时，您通常需要给特定元素设置特殊值。通过在浏览器中查看页面的HTML源代码，您总是能够找出一个元素的名称。
Java Web Services（JWS）
像基于HTML的组件那样，可以通过HTTP从服务器外部访问Java Web Services。尽管JWS通过其WSDL提供一个更加稳定的API，但它可以使测试变得更加容易，因为输入和输出XML的形状变化的可能性比代表JSP输出的实际HTML要小。从web服务返回的XML没有包含格式信息，而格式信息可以使HTML由于布局影响而发生变化的可能性更大。
您可能想考虑从同一个客户端生产平台测试您的web服务。例如，如果您使用WebLogic Workshop在服务器上实现您的web服务，而且始终从在Microsoft
.NET中编写的客户端调用它们，您可能会想在.NET中至少编写一些测试，以测试跨平台的交互。
假定您想要使用Java编写和运行您的测试，您愿意使用强类型Java对象编写测试，而不是构造一个HTTP请求，然后解析作为结果生成的XML。在8.1中，有两种方法可以创建这类符合JAX-RPC规范的接口。
使用<clientgen>
WebLogic Server提供一个<clientgen> Ant 任务。您在描述Web服务的WSDL上指向这个任务，然后告诉它在哪里放置作为结果的Java类。在http://e-docs.bea.com/wls/docs81/webserv/anttasks.html#1080160上可以找到关于如何使用该任务的文档。
使用Test Client
您还可以使用WebLogic Workshop Test Client来生成代理JAR。只要点击您的JWS文件上的Start按钮，转到Test Client中的Overview选项卡，然后点击Java
Proxy按钮即可。如果您愿意，您可以指定用于在其中放入代理类的包，否则使用默认的weblogic.jws.proxies。
Web服务示例
下面给出一个JWS的例子，您可以在{UnitTestingWeb}/jws/JWSToTest.jws中找到它。它定义了两个非常简单的操作。虽然不是很有意思，但是它们对我们要达到的目的来说已然足够。您还可以看到，我们已经从JWS生成了一个WSDL，Workshop将自动使其在接口变化时与JWS保持同步。
public class JWSToTest implements com.bea.jws.WebService {
static final long serialVersionUID = 1L;
/** @common:operation */
public int square( int i ) {
return i * i;
}
/** @common:operation */
public String hello() {
return "Hello";
}
}
|
用于我们的JWS的测试是{JWSTestProject}/JWSTest.java，下面给出它的一部分：
private JWSToTest _proxy;
public void setUp() throws IOException {
_proxy = new JWSToTest_Impl();
}
public void testJWS() throws Exception {
assertEquals( 25, _proxy.getJWSToTestSoap().square( 5 ) );
}
|
就像页面流测试一样，它有一个main()方法，使您可以通过点击Start按钮来运行它。在setUp() 方法（在运行每个单独的测试之前已经调用）中，我们创建了JAX-RPC代理的一个实例。然后，在我们的测试中，我们可以简单地把相关参数传递给方法，然后验证结果是否正确。
因为代理是从WSDL生成的，它已经知道用于访问web服务的URL。您可以测试一台运行相同web服务的不同服务器，像阶段测试服务器，具体做法是传递一个不同的URL给代理。在http://java.sun.com/xml/jaxrpc/index.jsp上可以找到关于JAX-RPC代理的更多信息。
Enterprise Java Beans（EJB）
把EJB当作外部组件进行测试非常类似于从任何其他客户端调用它。（您还可以把EJB当作内部组件进行测试。更多信息请参见下面的内容。）您需要使用过去习惯用于EJB的基本步骤：
(1) 在JNDI中查找home接口， (2)创建一个bean实例，然后 (3) 调用它的方法。
EJB示例
我们将测试在{EJBProject}/ejbpackage/SampleSessionBean.ejb找到的无状态会话bean。它定义了一个bean方法doSomethingBoring(),
该方法名副其实，功能是简单地返回一个5：
public class SampleSessionBean extends GenericSessionBean implements SessionBean
{
public void ejbCreate()
{
}
/** @ejbgen:remote-method */ public int doSomethingBoring()
{
return 5;
}
} |
对于这个例子来说，测试用例是{UnitTestProject}/EJBTest.java，下面是它的一小段代码：
private SampleSessionHome lookupHome() throws NamingException {
Context ctx = getInitialContext();
// Lookup the bean's home using JNDI
Object home = ctx.lookup("ejb.SampleSessionRemoteHome");
return (SampleSessionHome) narrow(home, SampleSessionHome.class);
}
private Object narrow(Object ref, Class c) {
return PortableRemoteObject.narrow(ref, c);
}
private Context getInitialContext() throws NamingException {
// Set up the environment properties
Hashtable h = new Hashtable();
h.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
h.put(Context.PROVIDER_URL, "t3://localhost:7001");
return new InitialContext(h);
}
public void testEJB() throws Exception {
assertEquals( 5, lookupHome().create().doSomethingBoring()
);
}
|
在我们的测试方法中，我们获得了服务器的初始环境，在JNDI中查找home接口，缩小它，调用创建方法，然后调用bean方法。也可以使用Start按钮来运行该测试。
对内部可测试组件进行单元测试
一些WebLogic Workshop组件只能从服务器容器内部访问。最明显的例子是控件，只能由框架初始化它，而且只能被包含其他控件、JWS、JPF和JPD类在内的组件使用。因此，为了高效地对这些种类的组件进行单元测试，您的测试需要运行在服务器进程内部。
Cactus
针对外部可测试组件运行时，需要把JUnit测试运行为发送HTTP请求给组件的客户端进程。为了在服务器容器内部运行JUnit测试，您需要使用Cactus框架，它是一个免费的开源框架，是Apache
Jakarta项目的一部分。Cactus Web站点http://jakarta.apache.org/cactus/index.html
包含了关于JUnit客户端如何连接到服务器，然后使测试运行的详细信息。下面，我将对该机制做一些总结。
当编写您想要使用Cactus运行在服务器内部的JUnit测试时，您通常想要扩展ServletTestCase，而非扩展TestCase。另外，您可以让您的suite()方法返回一个ServletTestSuite的实例。当您在您的测试上运行客户端JUnit进程时，它将检测到这是一个服务器端的测试，并发送HTTP请求给您指定的URL。在服务器上，Cactus接收到请求，创建您的测试类的一个实例，然后运行测试。接着，它把结果返回给JUnit客户端进程，该进程显示它们的时候就好像是运行标准的JUnit测试一样。
为了使用Cactus，您需要配置您的web应用程序，使其把进入的请求正确地路由给Cactus，编辑web.xml部署描述符可以做到这一点，如下面的代码片断所示：
<servlet>
<servlet-name>ServletRedirector</servlet-name>
<servlet-class>org.apache.cactus.server.ServletTestRedirector</servlet-class></servlet>
<servlet-mapping>
<servlet-name>ServletRedirector</servlet-name>
<url-pattern>/ServletRedirector</url-pattern>
</servlet-mapping> |
此外，服务器和客户端都需要在它们的运行时类路径中包含JUnit、Cactus和测试类。一般说来，您要把Cactus和JUnit JAR添加到您的应用程序的APP-INF/lib目录。您还可以使用Ant任务把运行您的测试所需的所有类都打包成一个EAR文件。启动JUnit客户端进程时，您需要使用-Dcactus.contextURL=SomeURL来指定Cactus在连接到服务器时应该使用的URL。想要了解更多信息，请参见http://jakarta.apache.org/cactus/integration/ant/task_cactus.html。
Enterprise Java Bean（EJB）
如果您调用EJB的生产代码作为EJB实例运行在同一个虚拟机内部，您可以通过使用Cactus使您的测试环境更加近似地匹配您的生产环境。这正如下面的例子所示。
EJB示例
在这个例子中，上面用于外部组件测试的EJB测试已经被转换成在服务器内部运行。您可以在{UnitTestingWeb}/ejb/CactusEJBTest.java
上找到演示Cactus的EJB测试。它位于一个web项目内，以便可以部署给服务器，尽管将JAR文件构建到APP-INF/lib目录中的Java项目也将被部署给服务器。这次测试的一个代码片断如下所示：
public class CactusEJBTest extends ServletTestCase
{
private SampleSessionHome lookupHome() throws NamingException
{
Context ctx = getInitialContext();
// Lookup the bean's home using JNDI
Object home = ctx.lookup("ejb.SampleSessionRemoteHome");
return (SampleSessionHome) narrow(home,
SampleSessionHome.class);
}
private Object narrow(Object ref, Class c) {
return PortableRemoteObject.narrow(ref,
c);
}
private Context getInitialContext() throws NamingException
{
System.out.println( "getInitialContext()"
);
// Set up the environment properties
Hashtable h = new Hashtable();
h.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
h.put(Context.PROVIDER_URL, "t3://localhost:7001");
return new InitialContext(h);
}
public void testEJB() throws Exception {
assertEquals( 5, lookupHome().create().doSomethingBoring()
);
}
...
|
如果您查看该测试的源代码，您会注意到，它实际上与非Cactus的版本完全相同。它扩展的是ServletTestCase ，而非TestCase ，而且有一个不同的类和包名。它还在它的getInitialContext()方法中打印出一些调试输出，这样您就可以了解到，它的确是运行在服务器VM内部，但是没有其他方面的变化。一定要在试着运行测试之前构建和部署应用程序，以确保测试类被真正地部署到服务器。
Java控件（JCS、JCX）
控件或许是WebLogic Workshop 8.1中最难测试的组件，因为用户代码不会直接实例化它们。相反，您必须允许框架让支持控件的组件类型（比如JPF）使用控件实例。下面的例子说明了如何做到这一点。
Java控件示例
在这个例子中，为了能够接收Cactus请求的Java Page Flow，我把一个抽象基类AbstractUnitTestController包含在内。为了测试控件，您需要使用JUnit测试方法创建一个子类。因为您的测试用例扩展了AbstractUnitTestController，它实际上是一个页面流控制器，所以服务器框架将给您的类一个控件实例来使用。此外，您可以在IDE中使用您已经熟悉的设计工具编写您的测试，这可以简化测试的创建过程。注意，您可以轻松地把这个页面流改编成测试任何为WebLogic
Platform应用程序而开发的Java控件。
我们将要测试的控件是一个在前面的web服务例子中自动生成的服务控件。该例子还演示了一种测试不需要构建Java客户端代理的web服务的不同方法。Workshop将自动使服务控件与web服务保持同步。这个UnitTestingWeb}/jws/JWSToTestControl.jcx
控件的一个代码片断如下所示：
public interface JWSToTestControl extends com.bea.control.ControlExtension,
com.bea.control.ServiceControl {
public int square (int i);
public java.lang.String hello ();
static final long serialVersionUID = 1L;
}
...
|
测试{UnitTestingWeb}/jws/newpageflow1/ ServiceControlTest.jpf的代码如下所示：
public class ServiceControlTest extends AbstractUnitTestController
{
/** @common:control */
private jws.JWSToTestControl jwsToTestControl;
/** @jpf:action */
protected Forward begin() throws ServletException {
return super.begin();
}
public static Test suite() {
return new ServletTestSuite( ServiceControlTest.class
);
}
public void testMethod() {
Assert.assertEquals( jwsToTestControl.square(
2 ), 4 );
}
}
|
在这段代码中，有两个元素是使测试在Cactus中正确工作所必需的（余下的部分是标准的JUnit测试代码）。首先，测试需要有一个委托给超类的protected
的begin()方法。因为在WebLogic Workshop 8.1 中，子类不能继承注释，每个测试类需要定义一个jpf:action，以便能够接收HTTP请求。超类可在{UnitTestingWeb}/jwsTestPageFlow/
AbstractUnitTestController.jpf上找到，它将负责处理请求本身和调用相关的测试方法。
接下来，测试需要一个suite()方法，用于把类添加给ServletTestSuite。因为类需要是Controller子类，以从框架获得控件实例，这个标签告诉Cactus在服务器上，而不是在客户端JUnit
VM内部运行测试。
要运行测试，确保您已经构建了应用程序并将其部署到WebLogic Server。然后，使用controlCactus.bat文件启动客户端进程，并使Cactus在服务器中运行测试。和EJB
Cactus例子一样，您可能需要在文件中编辑路径，使其指向您机器上的正确目录。
要为您自己的控件编写测试，您只需把AbstractUnitTestController.jpf 类添加到您的项目中，然后创建您自己的子类即可。帮助您编辑页面流文档的常规设计工具还可以辅助创建使用控件的测试。
结束语
尽管WebLogic Workshop 8.1没有将测试的编写和维护自动化，它没有禁止您编写您的自己的测试。在某些情况下，您可以直接在IDE中轻松地运行您的测试。使用本文中提及的信息，您应该能够快速而轻松地测试您自己的WebLogic
Workshop组件。
辅助阅读
原文出处
http://dev2dev.bea.com/products/wlworkshop81/articles/eckels_BP.jsp
作者其它文章
|
