BPELUnit Tutorial - Unit Testing BPEL processes with Test Coverage - Part II

Author: Buddhika Chamith
Version: 2009-07-22

In the second part of this two part tutorial, how to unit test a process inclusive partner service calls will be covered. Since this will be an extension of the first part of the tutorial it is assumed you have completed the first part of this tutorial and have the test suite project available for modification.

This time we will be using a different input to the process with different language codes so that the process will invoke the external translator service. The completed test project can be found here.

Course of Action

  1. Open up the test suite file in the editor. It should look like the following from the first part of the tutorial.

    Screenshot: Test suite


  2. Add a new test case: We are going to add a new test case to test the else branch of the process.
    • Click on the Add... button of Test Cases and Tracks section.
    • Give the name of the new test case as Greet2.
    • Click OK.
  3. Add the message sent to the process: We are going to modify the message sent to the process to include different language codes so that process will invoke the TranslatorService.
    • Click on the client in Greet2 test case within the Test Cases and Tracks section.
    • Choose the Add... button in the activities section. Choose the Send/Receive Synchronous activity and confirm.
    • Choose for following in Send/Receive Synchronous dialog if they are not already filled out automatically.
    • Service: Translator
      Port: TranslatorPort
      Operation: process
    • Copy and paste the following in the "Data to be sent" text area of the dialog box.
      <TranslatorProcessRequest 
      xmlns="http://www.se.uni-hannover.de/soa08/tutorial/TranslatorProcess"> <From>GE</From> <To>EN</To> <Text>Gruß</Text> </TranslatorProcessRequest>
      (Greetings translated to German is Gruß)
    • Click Next to enter the assertions for this test case.
    • Click Add and enter //tran:TranslatorProcessResponse/tran:Text as the XPath query and 'Greetings' as the expected value. Please be aware of the quotes that are necessary to denote that Greetings is an XPath string. Your dialog should then look like in the following figure:

      Screenshot: Send/Receive Synchronous Activity specification


    • Click finish to save the modifications.
  4. Add a send activity to TranslatorPartner: This will allow the mock TranslatorService to return a reply when it is going to be invoked by the process.
    • Click on the TranslatorPartner in Greet2 test case within the "Test Cases and Tracks" section.
    • Click on the Add... button in the "Activities" section.
    • Click on Receive/Send Synchronous and click OK.
    • Following dialog would come up.

      Screenshot: Receive/Send Synchronous Activity specification


    • Click Next button. Copy and paste the following to the Data to be sent text area of the dialog.
      		<TranslateResponse 
      xmlns="http://www.se.uni-hannover.de/soa08/tutorial/TranslatorService"> <Text>Greetings</Text> </TranslateResponse>

    • Click Finish button.
  5. Run the test suite: Save the test suite and run it by selecting the suite.bpts file in the Project Explorer and choosing Run as/ BPELUnit Test Suite from the context menu of the suite.bpts file.
    • The BPELUnit view should appear as in the first part, in which you can observe the progress of the test run.

      Screenshot: BPELUnit view showing test run results


    • Also the Test Coverage view should be updated and shows you the new test coverage results. In this case it shows two assignment activities out of three were executed while the single invoke in the process (invoke to TranslatorService) was executed in this test's execution path.

      Screenshot: Test Coverage view showing test coverage


    • You can see the overall coverage of two test cases by checking both test cases in Test Cases section of the Test Coverage view.

      Screenshot: Test Coverage view showing overall test coverage


    • The test coverage is now 100%. This means that both test cases together have triggered all activities in the BPEL process. The test coverage is a good indicator for the quality of a test suite. The nearer it is to 100% the better it should be. However, it is only an indicator. Even if the test suite reaches 100% and no errors are found, there can be still errors in the BPEL process although they are less likely. In the end, the quality of the test data and assertions will determine the quality of your tests and the number of errors you will spot.

Writing automated tests with BPELUnit is simple as has been shown in this tutorial. Together with Apache ODE and the Eclipse BPEL Editor you have very powerful Open Source tools for BPEL development.

Last Update: 2009-07-27 by Buddhika Chamith