Automating your business process application test cases using Java in IBM Business Process Manager

Using the REST API provided by IBM® Business Process Manager, you can start the execution of a business process and drive it all the way to completion. In this article, you will use this capability along with the Java™ REST client API asset to write automated test cases in Java using JUnit and DBUnit. This content is part of the IBM Business Process Management Journal.

Share:

Jorge Rafael Nogueras (rafaeln@us.ibm.com), Advisory Software Engineer, IBM

Photo of Jorge Rafael NoguerasJorge Rafael Nogueras is a Software Engineer in IBM Software Group, where he works as a developer in the IBM Business Process Manager team. He started his IBM career in the System and Technology Group as a kernel developer in the AIX TCP/IP department, and later moved on to the Systems Management group, where he worked on the WPAR Manager component for IBM Systems Director. Rafa has a B.S. degree in Computer Engineering from the University of Puerto Rico, Mayagüez Campus, and a Master's degree in Computer Science from the Massachusetts Institute of Technology.



Ricardo Olivieri (roliv@us.ibm.com), Software Engineer, IBM

Ricardo OlivieriRicardo Olivieri is a Software Engineer in IBM Software Services for WebSphere. His areas of expertise include architecting, designing, and developing software applications (mainly web and database centric applications), administrating and configuring WebSphere Application Server, and distributed software architectures. Ricardo has several years of experience in Java development as well as in Groovy, Perl, and Python development, with a strong background in backend development (server side, business logic, databases, SQL) and frontend development. Ricardo has recently added BPM development to his bag of tricks using Business Process Manager. Through his years at IBM, Ricardo has learned and used many open source frameworks, libraries, and projects such as Drools, Spring, Struts, Restlet, Hibernate, Dojo, and JasperReports. He has a B.S. degree in Computer Engineering from the University of Puerto Rico, Mayagüez Campus.



May 2013 (First published 05 December 2012)

Also available in Russian

Introduction

Using the REST API provided by IBM Business Process Manager, you can start the execution of a business process and drive it all the way to completion. In this article, you will use this capability along with the Java™ REST client API asset, introduced in Integrating a business process application in IBM Business Process Manager V7.5.1 and V8 with an external system using the REST API article, to write automated test cases in Java using JUnit and DBUnit.

Editor's note: The download.zip file has been updated.

Assumptions

Try the Workflow service

Create long-running, stateful workflows that orchestrate tasks and services with synchronous or asynchronous event-driven interactions with the Workflow service from Bluemix. Try it for free!

To understand the topics discussed in this article, you need to be familiar with the basic functions of IBM Business Process Manager and with the general concepts of business process application development. Knowledge of Java, JEE, JUnit, DBUnit, Spring, JavaScript, WebSphere Application Server (including configuration of data sources), web application security, representational state transfer (REST) architecture, integrated development environments (such as Eclipse), programming languages in general, and software test automation are assumed. If you don't have experience writing automated test cases in Java, we recommend that you become familiar with JUnit and DBUnit before reading this article.


Reasons to leverage automated unit test methodologies

It's not uncommon for IBM Business Process Manager (IBM BPM) business processes to execute several SQL queries against one or more databases to collect data at different steps during their execution. For example, a business process design (BPD) starts with the arrival of a message and, as the process moves forward, it queries several database tables and applies business rules and logic to the in-flight data. Also, it is not uncommon for business processes to perform a few updates to a database at the end of their execution.

Using JUnit and DBUnit, you can write integration test cases that automatically populate database tables (with the required data to start the execution of a process) and that perform assertions at different points throughout the execution of a business process. Therefore, you can write test code to ensure that the in-flight data was modified as expected, that the correct human activities were reached, and that the database has the expected values at the end of the execution of the business process.

A sample BDP process and Java code that uses JUnit and DBUnit to drive and test the execution of the business process is provided for download with this article.


The Java REST API library

In a previous developerWorks article titled Integrating a business process application in IBM Business Process Manager V7.5.1 and V8 with an external system using the REST API, it was discussed how you can integrate external Java applications with an IBM BPM business process. In that article, a reusable Java asset and library were introduced that allows for seamless integration between a Java application and an IBM BPM process through the invocation of REST calls. In this article, we build on top of the knowledge gained through the reading and understanding of that article. We will use that reusable Java asset to write JUnit and DBUnit integration test cases for an IBM BPM business process. Note that we are not stating that using JUnit and DBUnit are the only way to test your IBM BPM business process applications. Depending on the complexity of your IBM BPM process requirements, you may opt to execute your tests manually or use a different testing approach. The purpose of this article is to simply make you aware of one approach or methodology that you can use to test your IBM BPM processes.


The test data model

Let's start by familiarizing ourselves with the data model for the database used by the sample business process we are about to discuss. Figure 1 shows the database tables and their relationship.

Figure 1. The data model for the database
The data model for the database

As shown in Figure 1, the data model consists of a request object that is exclusively associated with a single account object. Also, note that each account object has a single category and each request object has a single type.

Let's continue now by describing the sample business process for this article, "Sample BPD". As shown in Figure 2, Sample BPD has five activities: three system activities and two human activities. Figure 3 shows the variables definition for the sample business process. Note that there is one input variable, requestId, of the integer data type, and one private variable, request, of the Request data type (this is a complex data type defined for this process application). Before you continue reading, you should familiarize yourself with the variables and their data types.

Figure 2. BPD diagram for the Sample BPD process
BPD diagram for the Sample BPD process
Figure 3. Variables definition for the Sample BPD process
Variables definition for the Sample BPD process

Let's now discuss the different steps in Sample BPD. To start this business process, a request ID must be provided as an input value. Without this value, the process does not move forward and throws an error. Get Request is the first activity in the process and it uses the requestId variable to perform an SQL query against the database. Using the data returned from the database for the corresponding requestId value, this first activity returns a populated Request object.

Following the Get Request activity, there is a gateway that evaluates the category of the account associated with the request variable. Depending on the value of the category, one of the following three activities is executed next (Figure 4 shows the definition for this gateway) as shown in Table 1.

Table 1. Request categories and associated activities
CategoryActivity
Very Important Account Approve (Automated)
Important Account Full Review
Not So Important Account (default) Quick Review
Figure 4. Definition for the Account Category gateway
Definition for the Account Category gateway

Let's now go over each one of these three activities. As shown in Figure 5, the Approve (Automated) activity simply approves the request (without any human intervention) and populates the comments field.

Figure 5. Implementation for the Approve (Automated) Activity
Implementation for the Approve (Automated) Activity

The Full Review activity is a human service that allows a Checker user to inspect the data in the request object. The Checker user is also supposed to access other systems (for example, the swivel chair approach) and enter any findings into the comments field. The Checker user approves or rejects the request depending on his or her findings.

The Quick Review activity is a human service that allows a Reviewer user to inspect the data in the request object. The Reviewer user performs a cursory check of the request data and decides whether or not the request is rejected or approved. If the Reviewer approves the request, then the request goes to the Checker user's desk for a thorough review.

Once a final decision (for example, approved or rejected) is made regarding the incoming request, the Update Status activity is executed. Figure 6 shows the implementation for this activity.

Figure 6. Implementation for the Update Status service
Implementation for the Update Status service

Note that the Update Status service should invoke a fictitious web service (to collect a system code value) if and only if the type of the request is Type 1. In all other cases, the invocation of the fictitious web service is skipped (and no value is assigned to the system code field). As shown in Figure 7, the implementation for the fictitious web service call sets the value of the systemCode field to a hard-coded value.

Figure 7. Implementation for the fictitious web service call
Implementation for the fictitious web service call

The Update Status service updates the status of the request in the database by persisting the following fields of the request object:

  • comments: These are comments provided by the user reviewing or checking the request (or the system in the case of an automated approval).
  • approved: This is the final decision regarding the request.
  • systemCode: This is the value returned by the fictitious web service that is invoked for all requests whose type is "Type 1".

Testing

If you are thorough in your IBM BPM deliverables, then you test your business process when changes are made to its implementation. To test the Sample BPD business process, you can manually set up the data in a test database every time before executing each test case, use Process Designer to execute the business process, and use the Inspector perspective to review the flow of the process and the values of the in-flight data at each human step. Once the process completes, you can manually execute SQL queries to inspect the data in the database tables. These same steps are done manually every time for each test case execution.

An alternative to the testing approach described above is writing Java code that uses JUnit, DBUnit, and the Java REST client for IBM BPM to automate the execution of test cases. Using automated test cases significantly improves the quality of your IBM BPM deliverables and reduces the amount of time needed to manually execute each test case. Let's now go over a complete sample that shows you how to do this.

The name of the sample JUnit test class for the Sample BPD process is SampleBPDProcessTests. Listing 1 shows the implementation for the setUpClass() method of the SampleBPDProcessTests class. Note that this method is annotated with JUnit's @BeforeClass annotation. It creates an instance of the BPMClientImpl class using the IBM BPM credentials and access information contained in the sampleBPMProps.txt file (see Listing 2). Depending on the design of your test cases, you may prefer to create a different instance of the BPMClientImpl class for each test case execution instead. For example, if you run each test case method under the identity of a different IBM BPM user, then you need a different instance of the BPMClientImpl class for each test case. In this sample, we are using the same instance across all test cases since it is sufficient for our test goals (and reusing the same object instance results in faster execution).

Listing 1. Implementation of the setUpClass() method
   @BeforeClass
   public static void setUpClass() throws Exception {
      BPMAccess bpmAccess = new BPMAccess(
            "/sample/process/tests/sampleBPMProps.txt");
      WASAuthenticationTokenHandler handler = new WASAuthenticationTokenHandler(
            bpmAccess.getUser(), bpmAccess.getPassword());
      bpmClient = new BPMClientImpl(bpmAccess.getHostname(),
            bpmAccess.getPort(), handler);
      utils = new TestUtils(bpmClient);
   }
Listing 2. Contents of the sampleBPMProps.txt properties file
# The hostname of the process center/server
hostname=localhost

# The port number of the process center/server
port=9080

# The BPM userid to connect to the process center/server
user=tw_admin

# The BPM password to connect to the process center/server
password=admin

Listing 3 shows the implementation for the getSeedFilesMetaData()and the getDBAaccess() methods. These are called by a method that is annotated with JUnit's annotation @Before. These methods specify the database access and credentials information to establish a database connection (see Listing 4) and the data (see Listing 5) that DBUnit inserts into the database tables at the beginning of each test case execution.

Listing 3. Implementation of the getSeedFilesMetaData()and getDBAaccess() methods
   @Override
   protected SeedFilesMetaData[] getSeedFilesMetaData() {
      String seedFiles[] = { "sampleSeedFile.xml" };
      return new SeedFilesMetaData[] { new SeedFilesMetaData(
            "/sample/process/tests", seedFiles, "SAMPLE") };
   }

   @Override
   protected DBAccess getDBAaccess() {
      return new DBAccess("/sample/process/tests/sampleDBProps.txt");
   }
Listing 4. Content of the sampleDBProps.txt properties file
# The DB2 JDBC driver class
# There should be no need to change this unless connecting to a
# non-DB2 database dbDriver=com.ibm.db2.jcc.DB2Driver

# The JDBC URL of the database
# Make sure the hostname and port number match your database configuration
dbUrl=jdbc:db2://localhost:50000/APP_SOR

# The database userid
dbUser=db2admin

# The database password
dbPassword=dt3t55r6s
Listing 5. Content of the sampleSeedFile.xml
<?xml version="1.0" encoding="UTF-8"?>
<dataset>
   <table name="ACCOUNT_CATEGORY">
      <column>CATEGORY_ID</column>
      <column>CATEGORY_NAME</column>
      <row>
         <value>1</value>
         <value>Very Important Account</value>
      </row>
      <row>
         <value>2</value>
         <value>Important Account</value>
      </row>
      <row>
         <value>3</value>
         <value>Not So Important Account</value>
      </row>
   </table>

   <table name="REQUEST_TYPE">
      <column>TYPE_ID</column>
      <column>TYPE_NAME</column>
      <row>
         <value>1</value>
         <value>Type 1</value>
      </row>
      <row>
         <value>2</value>
         <value>Type 2</value>
      </row>
      <row>
         <value>3</value>
         <value>Type 3</value>
      </row>
   </table>

   <table name="ACCOUNT">
      <column>ACCOUNT_ID</column>
      <column>ACCOUNT_NAME</column>
      <column>EMAIL</column>
      <column>CATEGORY_ID</column>
      <row>
         <value>1</value>
         <value>ABC</value>
         <value>sales@abc.com</value>
         <value>1</value>
      </row>
      <row>
         <value>2</value>
         <value>XYZ</value>
         <value>sales@xyz.com</value>
         <value>2</value>
      </row>
      <row>
         <value>3</value>
         <value>CBA</value>
         <value>sales@cba.com</value>
         <value>3</value>
      </row>
   </table>

   <table name="REQUEST">
      <column>REQUEST_ID</column>
      <column>ACCOUNT_ID</column>
      <column>DESCRIPTION</column>
      <column>TYPE_ID</column>
      <row>
         <value>1</value>
         <value>1</value>
         <value>A new request for account ABC.</value>
         <value>1</value>
      </row>
      <row>
         <value>2</value>
         <value>2</value>
         <value>A new request for account XYZ.</value>
         <value>2</value>
      </row>
      <row>
         <value>3</value>
         <value>3</value>
         <value>A new request for account CBA.</value>
         <value>3</value>
      </row>
   </table>
</dataset>

Note the relationships between the records across all the tables specified in Listing 5. For example, note that request record with ID "1" is associated with accounts "ABC" and "Type 1" and the "Very Important Account" category.

Listing 6 shows the implementation for the first test case method, testVeryImportantRequest(). Note that this method is annotated with JUnit's @Test annotation. The testVeryImportantRequest() method starts an instance of the Sample BPD process by passing a request ID. Since the category associated with this request is "Very Important Account", no human step is required in this execution (see Figure 4).

As described earlier, at the end of the execution of the process, the request record in the database is updated (for example, the approved, comments, and systemCode fields are persisted). Therefore, the implementation of the testVeryImportantRequest() method performs JUnit assertions to verify that the outcome of executing the process matches the expected results. Note that some of these assertions are performed against data returned from invoking the IBM BPM REST API calls, while others are made against the data returned from executing an SQL query (thus, verifying that the business process updated the corresponding request record as expected). Also, note that a system code value is expected in this scenario given that Type 1 is the type associated with this request record.

Listing 6. Implementation of the testVeryImportantRequest() method
   @Test
   public void testVeryImportantRequest() throws Exception {
      int requestId = 1;

      // Create input argument to start the business process
      JSONObject bpdArgs = new JSONObject();
      bpdArgs.put("requestId", requestId);

      // Start the business process: Sample BPD
      JSONObject results = bpmClient.runBPD(BPD_ID, PROCESS_APP_ID, bpdArgs);
      int processId = results.getJSONObject("data").getInt("piid");
      Thread.sleep(waitTime);

      // Verify process completed as expected
      Assert.assertTrue(utils.isProcessCompleted(processId));

      // Verify that after executing the business process, there are still
      // three request records in the database
      int count = getJdbcTemplate().queryForInt(
            "select count(*) from sample.request");
      Assert.assertEquals("Wrong number of request records!", 3, count);

      // Verify corresponding request record was updated as expected
     String sql1 = "select approved, system_code, comments from" +
       "sample.request where request_id=" + requestId;
      getJdbcTemplate().query(sql1, new RowCallbackHandler() {
         @Override
         public void processRow(ResultSet rset) throws SQLException {
            String approved = rset.getString(1);
            String systemCode = rset.getString(2);
            String comments = rset.getString(3);
            Assert.assertEquals("System code mismatch!", "ABCD", systemCode);
            Assert.assertEquals("Approval value mismatch!", "Y", approved);
            Assert.assertEquals("Comments mismatch!",
                  "System automated approval", comments);
         }
      });
   }

Listing 7 shows the implementation for second test case method, testImportantRequest(). Since the category associated with this request is "Important Account", the Full Review activity is executed (see Figure 4). Therefore, the implementation of the testImportantRequest() method performs a JUnit assertion to verify that the Full Review activity is reached. Just as the testVeryImportantRequest() method, the testImportantRequest() method performs assertions against data returned from querying IBM BPM via the REST API and against the data returned from querying the database. Note that a system code value in this scenario is not expected, given that Type 1 is not the type associated with this request record. Also, note that this method asserts that the comments and approved fields in the database have the expected values.

Listing 7. Implementation for the testImportantRequest() method
   @Test
   public void testImportantRequest() throws Exception {
      int requestId = 2;

      // Create input argument to start the business process
      JSONObject bpdArgs = new JSONObject();
      bpdArgs.put("requestId", requestId);

      // Start the business process: Sample BPD
      JSONObject results = bpmClient.runBPD(BPD_ID, PROCESS_APP_ID, bpdArgs);
      int processId = results.getJSONObject("data").getInt("piid");
      Thread.sleep(waitTime);

      // Get user's inbox
      results = bpmClient.getInbox();

      // Find & execute expected task
      JSONObject checkTask = utils
            .findTask(results, processId, "Full Review");
      Assert.assertNotNull(checkTask);
      int checkTaskId = checkTask.getInt("taskId");
      results = bpmClient.startTask(checkTaskId);
      HumanServiceDetails hsDetails = utils.parseStartDetails(results);
      Assert.assertFalse(hsDetails.isCompleted());
      Assert.assertEquals("Full Review", hsDetails.getCoach());

      // Verify in-flight data
      JSONObject vars = hsDetails.getVariables();
      Assert.assertNotNull(vars.getJSONObject("request"));
      Assert.assertEquals(requestId,
            vars.getJSONObject("request").getInt("requestId"));
      vars.getJSONObject("request").put("approved", true);
      vars.getJSONObject("request").put("comments",
            "Approving request for XYZ account.");
      bpmClient.setData(checkTaskId, vars);
      results = bpmClient.resumeService(checkTaskId, "buttonGrp1_ok");
      hsDetails = utils.parseResumeDetails(results);
      Assert.assertTrue(hsDetails.isCompleted());
      Thread.sleep(waitTime);

      // Verify process completed as expected
      Assert.assertTrue(utils.isProcessCompleted(processId));

      // Verify that after executing the business process, there are still
      // three request records in the database
      int count = getJdbcTemplate().queryForInt(
            "select count(*) from sample.request");
      Assert.assertEquals("Wrong number of request records!", 3, count);

      // Verify corresponding request record was updated as expected
     String sql1 = "select approved, system_code, comments from" +
       "sample.request where request_id=" + requestId;
      getJdbcTemplate().query(sql1, new RowCallbackHandler() {
         @Override
         public void processRow(ResultSet rset) throws SQLException {
            String approved = rset.getString(1);
            String systemCode = rset.getString(2);
            String comments = rset.getString(3);
            Assert.assertNull("System code mismatch!", systemCode);
            Assert.assertEquals("Approval value mismatch!", "Y", approved);
            Assert.assertEquals("Comments mismatch!",
                  "Approving request for XYZ account.", comments);
         }
      });
   }

Listing 8 shows the implementation for the third and last test case method in the SampleBPDProcessTests class, testNotSoImportantRequest(). Since the category associated with this request is "Not So Important Account", the Quick Review activity is executed after the Get Request activity (see Figure 4). Therefore, the implementation of the testNotSoImportantRequest() method performs a JUnit assertion to verify that the Quick Review activity is the first human activity reached in the process. The method also performs assertions to verify that the Full Review activity follows the Quick Review activity, (given that the Reviewer user approves the request). Just as the two previous test case methods, the testNotSoImportantRequest() method also performs assertions against data returned from querying IBM BPM via the REST API and data returned from querying the database.

Listing 8. Implementation for the testNotSoImportantRequest() method
   @Test
   public void testNotSoImportantRequest() throws Exception {
      int requestId = 3;

      // Create input argument to start the business process
      JSONObject bpdArgs = new JSONObject();
      bpdArgs.put("requestId", requestId);

      // Start the business process: Sample BPD
      JSONObject results = bpmClient.runBPD(BPD_ID, PROCESS_APP_ID, bpdArgs);
      int processId = results.getJSONObject("data").getInt("piid");
      Thread.sleep(waitTime);

      // Get user's inbox
      results = bpmClient.getInbox();

      // Find & execute expected task -> Quick Review
      JSONObject reviewTask = utils.findTask(results, processId,
            "Quick Review");
      Assert.assertNotNull(reviewTask);
      int reviewTaskId = reviewTask.getInt("taskId");
      results = bpmClient.startTask(reviewTaskId);
      HumanServiceDetails hsDetails = utils.parseStartDetails(results);
      Assert.assertFalse(hsDetails.isCompleted());
      Assert.assertEquals("Quick Review", hsDetails.getCoach());

      // Verify in-flight data
      JSONObject vars = hsDetails.getVariables();
      Assert.assertNotNull(vars.getJSONObject("request"));
      Assert.assertEquals(requestId,
            vars.getJSONObject("request").getInt("requestId"));
      vars.getJSONObject("request").put("approved", true);
      vars.getJSONObject("request").put("comments",
            "Approving request for CBA account.");
      bpmClient.setData(reviewTaskId, vars);
      results = bpmClient.resumeService(reviewTaskId, "buttonGrp1_ok");
      hsDetails = utils.parseResumeDetails(results);
      Assert.assertTrue(hsDetails.isCompleted());
      Thread.sleep(waitTime);

      // Get user's inbox
      results = bpmClient.getInbox();

      // Find & execute expected task -> Full Review
      JSONObject checkTask = utils
            .findTask(results, processId, "Full Review");
      Assert.assertNotNull(checkTask);
      int checkTaskId = checkTask.getInt("taskId");
      results = bpmClient.startTask(checkTaskId);
      hsDetails = utils.parseStartDetails(results);
      Assert.assertFalse(hsDetails.isCompleted());
      Assert.assertEquals("Full Review", hsDetails.getCoach());

      // Verify in-flight data
      vars = hsDetails.getVariables();
      Assert.assertNotNull(vars.getJSONObject("request"));
      Assert.assertEquals(requestId,
            vars.getJSONObject("request").getInt("requestId"));
      vars.getJSONObject("request").put("approved", false);
      vars.getJSONObject("request").put("comments",
            "Rejecting request for CBA account.");
      bpmClient.setData(checkTaskId, vars);
      results = bpmClient.resumeService(checkTaskId, "buttonGrp1_ok");
      hsDetails = utils.parseResumeDetails(results);
      Assert.assertTrue(hsDetails.isCompleted());
      Thread.sleep(waitTime);

      // Verify process completed as expected
      Assert.assertTrue(utils.isProcessCompleted(processId));

      // Verify that after executing the business process, there are still
      // three request records in the database
      int count = getJdbcTemplate().queryForInt(
            "select count(*) from sample.request");
      Assert.assertEquals("Wrong number of request records!", 3, count);

      // Verify corresponding request record was updated as expected
     String sql1 = "select approved, system_code, comments from" +
       "sample.request where request_id=" + requestId;         
      getJdbcTemplate().query(sql1, new RowCallbackHandler() {
         @Override
         public void processRow(ResultSet rset) throws SQLException {
            String approved = rset.getString(1);
            String systemCode = rset.getString(2);
            String comments = rset.getString(3);
            Assert.assertNull("System code mismatch!", systemCode);
            Assert.assertEquals("Approval value mismatch!", "N", approved);
            Assert.assertEquals("Comments mismatch!",
                  "Rejecting request for CBA account.", comments);
         }
      });
   }

Figure 8 shows the outcome of executing, in Rational® Application Developer, the three test cases defined in the SampleBPDProcessTests class.

Figure 8. JUnit test cases results
JUnit test cases results

Running the test cases on your system

The complete source code for the sample JUnit and DBUnit test cases that execute and verify the Sample BPD business process is provided with this article. The sample business process is also provided with this article in a TWX file.

Figure 9 shows the structure in Rational Application Developer for the Java project that holds the JUnit and DBUnit test cases for the Sample BPD process. In Figure 9, you can see the JAR dependencies that the project has (these are all included in the downloadable zip file). These JAR files are included in the classpath of the JVM for running the test cases in the SampleBPDProcessTests class (if they are not, you get ClassNotFoundException errors). Note that among these dependencies, we have the Java REST API client for IBM BPM (bpm-rest-client.jar) that was introduced in a previous article, Integrating a business process application in IBM Business Process Manager V7.5.1 and V8 with an external system using the REST API.

Figure 9. Java project in Eclipse
Java project in Eclipse

The download.zip file is an archive that contains all the source code and binary dependencies required to run the examples mentioned in this article. It also contains the DDL file necessary to create the test database and the TWX file containing the process application BPD.

Note that before running the test cases defined in the SampleBPDProcessTests class, you need to:

  1. Create the sample database using the provided create-db.sql file. This DDL file was successfully tested on a DB2® database. This DDL creates a database named APP_SOR. We do not claim or guarantee that it will work on other database products (we only tested it on DB2). In theory, it should work just fine (check your database product's documentation).
  2. Create a data source (using the WebSphere Application Server console) that references the database created in the previous step. The JNDI name for this data source must be jdbc/SampleDS.
  3. Import the provided Sample_App_for_JUnit-DBUnit_testing - SAJD_1052012_121_PM.twx file. It contains the Sample BPD business process.
  4. Import the provided download.zip as a project into Eclipse.
  5. Update the content of the following two property files accordingly: sampleBPMProps.txt and sampleDBProps.txt.
  6. Run the SampleBPDProcessTests class as a JUnit test.

Exercise

We leave the following exercise for the reader to create a fourth test case method (in the SampleBPDProcessTests class):

  1. Start an instance of the Sample BPD business process with a request ID of "3".
  2. Verify that the Quick Review step is the first human step reached.
  3. Execute the Quick Review step by rejecting the request and providing comments. Note that in the testNotSoImportantRequest() test method, the Reviewer user approves the request.
  4. Verify that the process completes after the Quick Review activity is completed (for example, no other human steps are reached).
  5. Verify that the system code field in the database does not have a value (for example, it should be NULL).
  6. Verify that the "comments" and "approved" fields in the database contain the expected values.

Conclusion

This article showed you how to write automated test cases for your IBM BPM business processes using JUnit, DBUnit, and the Java REST API client. By writing automated test cases for your IBM BPM processes, you can ensure that your processes run as expected. You can implement test cases to try out all the different execution paths that exist in your process and you get a test suite for performing regression testing when changes are made to the implementation of a process. Automated tests cases allow you to assert that expected human steps are reached, inspect the in-flight data, verify that the process ends successfully without errors, and verify the state of the data in the database.


Download

DescriptionNameSize
Code sampledownload.zip7068KB

Resources

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 Business process management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Business process management
ArticleID=848832
ArticleTitle=Automating your business process application test cases using Java in IBM Business Process Manager
publish-date=05052013