Unit Testing J2EE platform components with JUnit and JUnitEE frameworks in IBM Rational Application Developer Version 6.0.2: Part 2: Unit testing Web services

Learn how you can use the JUnit and JUnitEE open source test frameworks within IBM® Rational® Application Developer V 6.0.2 to test Web service units in an application server.

Share:

Abraham WoldeMichael (awmichael@us.ibm.com), Software Engineer, IBM

Abraham WoldeMichael started his career with IBM as part of a technical test team for various IBM products that used J2EE platform and Web services technologies. Currently, he is part of an IBM Systems and Technology Group development team that provides security services for IBM Virtualization Engine, which is part of IBM’s On Demand initiative. He has a systems and computer science degree from Howard University, as well as various IT professional certifications.



15 May 2007

Context of this article

The Java™ 2 Platform, Enterprise Edition™ (J2EE™ platform) has evolved to include Web services, which are built on a powerful distributed computing technology. Web services handle loosely coupled and interoperable communication between heterogeneous applications over a network. This communication between different systems and programming languages is achieved by using technologies based on service-oriented architecture (SOA) along with sets of open source Extensible Markup Language (XML), such as:

  • Web Services Description Language (WSDL)
  • Simple Object Access Protocol (SOAP)
  • Universal Description, Discovery, and Integration (UDDI)

Service-oriented architecture provides the core mechanism for publishing, finding, and binding Web services. Within SOA, a Web service is an interface that describes a collection of operations that are implemented by the service provider for requesters to use over a heterogeneous network. Like any other software application, these interfaces must go through rigorous unit testing to prevent undesirable behaviors and outcomes. Although you can test Web services in various ways, unit testing in the early stage of development helps generate correct Web service client stubs, which helps ensure that service interfaces are properly described in a WSDL document and faults are handled properly and gracefully.

The IBM® Rational® Application Developer platform integrate tools to build, deploy, test, discover, and publish Web services. Although it provides the mechanism to unit test Web services interactively, it falls short when it comes to automating unit tests.

This is Part 2 of a series of two articles that show how you can use IBM tools for unit testing by using JUnit and JUnitEE test frameworks to test Java™ applications, Enterprise JavaBeans™ (EJB™), and Web services. The series covers these topics:

  • Part 1 conveys the importance of unit testing Java and EJB applications and demonstrates how to develop and run a unit test of a stateless session bean by using JUnit and JUnitEE test frameworks.
  • Part 2 extends Part 1 by using the JUnit and JUnitEE test frameworks within the Rational Application Developer platform for unit testing Web services.

Prerequisites

To benefit from this article, you need a basic understanding of Web services and of Rational Application Developer. The IBM® developersWorks® Web site and Resources at the end of this article provide introductory materials.

This tutorial was developed and tested using using the final release of JUnitEE Version 1.10 and Rational Application Developer Version V 6.0.2. You can download the trial version of Rational Application Developer and the binary files for this example (see Resources).

Overview of Web services architecture and technologies

Web services have been around since 2000. They were originally developed by IBM®, Microsoft®, Ariba, and many others, and then submitted to the World Wide Web Consortium (W3C). There are several definitions, but for this article, a Web service is a technology that allows different applications to communicate with each other in an interoperable manner. More specifically, a Web service is an interface that describes one or more operations that can be accessed over a network through standardized XML. The key characteristic, interoperability, is enabled by a set of XML-based standards and protocols. For example, as Figure 1 illustrates, a Web service written in any platform or programming language, such as Java, .NET Framework, Perl, Apache Axis, Python, or C++, can be available to any type of Web service client by the taking advantage of open source Web and XML technologies.

Web service predecessor technologies, such as Common Object Request Broker Architecture (CORBA), Microsoft® DCOM, and Java™ Remote Method Invocation (RMI) have had some distributed computing capabilities. However, each technology has certain limitations. CORBA is tightly coupled between the client and server and relatively difficult to program. DCOM is propriety to Microsoft technologies, which inhibits interoperability. RMI is Java-to-Java object distribution, thus lacks language neutrality. Web services technology overcomes all of those limitations, in addition to offering several design merits:

  • Simple to program
  • Standards-based
  • Vendor-, platform-, and language-neutral
  • High level of interoperability and openness
  • Loose coupling

As the key attribute of Web services, interoperability is the ability of two heterogeneous software applications to communicate seamlessly. It is archived by XML, WSDL, SOAP, and UDDI standards. Although IBM developersWorks provides a great deal of information, Table 1 briefly summarizes these standards.

Table 1. Summary of Web service technologies and standards
TechnologyDescriptionContributionWhat it defines
XMLSimple, flexible, text-based markup languageProvides a common language for communication between applicationsXML document contains custom tags
WSDLAn XML-based language for Web servicesDescribes Web servicesWSDL documents contain these elements:
  • Types, which define data types
  • Message, which defines messages in the Web services exchange
  • PortType for the operation of the Web service
  • Binding, which binds port types to transport protocol and to message formats
SOAPXML-based protocol for sending and receiving messages over the InternetEnables exchange of messagesSOAP defines an envelope that contains:
  • SOAP header (optional)
  • SOAP body (to contain message)
UDDXML-based standard for registration, description, and discovery of Web servicesInterface for discovering Web servicesUDD shows:
  • Names of services available
  • Location of WSDL

Figure 1 shows the three key elements of the SOA model:

  • Web service provider
  • Web service directory
  • Web service client (service requester)
Figure 1. The 3 key elements of the SOA model
Diagram of the 3 key elements of the SOA model

First, the service provider publishes the service (for example, the WSDL) to the Web service directory (UDDI, for instance). Then the Web service requestor discovers services that are published in the UDDI. When the service is discovered, the WSDL generates a Web service client. Lastly, the Web service client can interact in an interoperable way by sending and receiving XML-based SOAP messages.

Example of unit testing Web services

Part 1 of this series of articles demonstrates how you can unit test EJBs by using the JUnitEE test framework in Rational Application Developer software. This part demonstrates how you can use the same test framework to test the BasicAdd operation used as the example in the first article.

To unit test Web services in Rational Application Developer software, you follow these steps:

  1. Deploy BasicAddBean into the Web service and generate service client artifacts.
  2. Develop JUnit test cases to test Web services.
  3. Configure the JUnitEE Web module to test, and then deploy and run the unit test in the WebSphere Application Server environment.

Step 1. Deploy BasicAddBean into the Web service and generate client artifacts

There are two approaches for developing Web services: bottom-up and top-down. With the bottom-up approach, you create a Web service from a Java bean, enterprise bean, URL, DADX file, or ISD, With the top-down approach, you create the Web service from a WSDL file. Jeffrey Liu and Lawrence Mandel's developersWorks article, "Top-down Web services development with WebSphere Studio," clearly demonstrate the top-down approach. (See Learn in Resources for a link to their article.)

Web service development is the preferable approach, because it can eliminate possible interposable problems. However, for simplicity, this article takes the bottom-up approach to quickly deploy the BasicAddBean stateless session EJB from the Part 1 article into a Web service. The Rational Application Developer platform provides a step-by-step wizard for deploying EJBs into a Web service, and it generates all of the necessary client artifacts. JUnit test programs use those client artifacts to invoke remote Web services.

Step 2. Develop JUnit test cases to test Web services

Although the actual JUnit test remains the same here as in Part 1, the setup() method changes, as code Listing 1 shows.

Listing 1.
package com.ibm.operation.add.test; 

import java.rmi.RemoteException;

import junit.framework.TestCase;

import com.ibm.operation.add.BasicAddBeanProxy;

public class BasicAddWebServiceTest extends TestCase {
	
protected BasicAddBeanProxy add=null;

public BasicAddWebServiceTest(String name)
  { super(name); }
	
protected void setUp() throws Exception
	{
       add = new BasicAddBeanProxy();
	}
	
protected void tearDown() throws Exception
	{
	 this.add = null;
	}

public void testSimpleAdditionNotSame() throws RemoteException
	{  
	  String actual = "4";
	  double result=this.add.addTwoNumbers(1,1);
	  String expected=Double.toString(result);
		 assertNotSame(actual,expected);
	}
	
public void testSimpleAddtionNotNull() throws RemoteException
	{ 
		String result=Double.toString(this.add.addTwoNumbers(1,1));
		 assertNotNull(result);
	}
public void testSimpleAddition() throws RemoteException
	{   
	String result = Double.toString(this.add.addTwoNumbers(70, 100));
	assertTrue("Result is " + result + " but comparing with 171",    
      result.equals("171"));
	
	}

}

}

Step 3. Configure the JUnitEE test module, and then deploy and run unit tests in WebSphere Application Server

In Part 1 of this series, you saw how the JUnitEE test module (BasicAddJUnitEEWeb) is configured to execute unit tests from the BasicAddUnitTest JAR file. To avoid reinventing the wheel, we include the Web service unit tests in the existing BasicAddUnitTest project.

Note: BasicAddUnitTest is a Java project that contains a Java application, an EJB, and, now, Web service unit tests.

  1. First, you put the BasicAddUnitTest.jar file in the WEB-INF/lib folder.
  2. Next, you deploy the EAR file (BasicAddEAR) into the application server.
  3. Finally, you launch a Web browser and navigate to TestServlet, which displays the JUnitEE TestRunner servlet shown in Figure 2.
Figure 2. JUnitEE TestRunner servlet
JUnitEE TestRunner servlet

You need an explanation of this screenshot here that includes a reference to the next screenshot Figure 3.

Figure 3. JUnitEE Test Results display
JUnitEE Test Results screen capture

Benefits of this testing method

Web services are published, discovered, and accessed within the service-oriented architecture environment. The JUnit and JUnitEE test frameworks enable developers to quickly and easily develop and run automated unit tests within the J2EE platform container. Ultimately, this helps you to publish services that are superior in quality.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational, Information Management
ArticleID=219096
ArticleTitle=Unit Testing J2EE platform components with JUnit and JUnitEE frameworks in IBM Rational Application Developer Version 6.0.2: Part 2: Unit testing Web services
publish-date=05152007