Glen Mazza's Weblog

« Using Message-Layer... | Main | Tracing SOAP calls... »

https://web-gmazza.rhcloud.com/blog/date/20170430 Sunday April 30, 2017

Using JUnit to test SOAP clients

Testing web service providers instead of SOAP clients? See this article instead.

Let's add JUnit test cases to the SOAP client of the web service tutorial created earlier. The finished tutorial source code can be obtained from GitHub by using either the download ZIP button or git clone -v git://github.com/gmazza/blog-samples.git command. Note in the download the group and artifact ID's listed in the poms have been changed to avoid conflicting with the original tutorial, also much of the dependency and plugin configuration information has been centralized into a higher-level POM, so you might wish to follow along with the finished source code.

We'll use a skeleton (stub) web service that will activate during the running of the client tests (the actual web service provider from the original tutorial will be unused during testing.) We'll be making three types of JUnit tests below, namely:

  1. Does the stub web service activate properly? Prior to having the SOAP client that we're testing call the stub web service, we need to make sure the latter is working. Making a web service call within the JUnit test independent of our SOAP client will confirm this.

  2. Is the SOAP client calling the stub web service correctly? Here, we make sure the SOAP client receives the same values that our independent SOAP call in the previous step did.

  3. Does the SOAP client handle the SOAP response correctly? At this stage we check to make sure the SOAP client processes the SOAP response properly. For the DoubleIt client, it's just to check that the response string "The number X doubled is Y" is as expected.

Steps involved:

  1. Modify the client submodule pom.xml for handling the stub web service. In the client pom.xml, add JUnit as a dependency:

    <dependency>
        <groupId>junit
        <artifactId>junit
    </dependency>
    

    Also we'll need the CXF transport dependency used by the stub:

    <dependency>
       <groupId>org.apache.cxf</groupId>
       <artifactId>cxf-rt-transports-http-jetty</artifactId>
       <version>${cxf.version}</version>
    </dependency>
    
  2. Create the stub web service. CXF has a nice feature that creates a skeleton web service implementation that can be used with any JAX-WS runtime. We'll temporarily modify the cxf-codegen-plugin in the service submodule to generate this implementation class and then move it to the client's test folders:

    1. Add the <extraarg>-impl</extraarg> setting to the cxf-codegen-plugin as follows and then run mvn clean install from the project root to generate the DoubleItPortImpl web service implementation:

      <wsdlOptions>
         <wsdlOption>
            <wsdl>
               ${basedir}/src/main/resources/DoubleIt.wsdl
            </wsdl>
            <extraargs>
               <extraarg>-impl</extraarg>
            </extraargs>
         </wsdlOption>
      </wsdlOptions>
      
    2. Once done, move the newly created DoubleItPortImpl.java from target/generated-sources/org/example/contract/ in the service submodule to a new src/test/java/org/example/contract/ folder in the client submodule. Remove the above <extraarg>-impl</extraarg> from the pom.xml so this class won't be created anymore.

    3. Next we'll update the DoubleItPortImpl.doubleIt(int) method in the stub to actually double the number that it receives:

  3. Create the test class. Place the following WSClientTest.java file in src/test/java/client. As you can see it tests the three situations stated earlier:

  4. Run the test case. Very simple, mvn clean install will of course run the tests from Maven as part of the build process. If there's any errors returned, they will be in the target/surefire-reports folder. If you're a fan of green and red bars while testing you can run the tests from IDEs such as IDEA and Eclipse usually by right-clicking the WSClientTest class in the treeview and selecting the appropriate "Run as JUnit test" option.

Notes

  • JUnit offers a Parameterized runner that provides a streamlined way of making the same SOAP call with different request values.

  • Another JUnit option is the timeout annotation on the Test tag. This will fail any test that does not complete within the specified number of milliseconds, and can be used if you wish to test performance of the SOAP client call or its processing.

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed

Valid HTML! Valid CSS!

This is a personal weblog, I do not speak for my employer.