This blog will teach you how to use Oracle SOA 12 Testing Framework to “Unit test” and “System test” your SOA workloads as part of an automated Continuous Integration approach. This will showing how powerful it is to use the out-of-the box SOA Test framework and automate with Maven the full cycle of a SOA Project, including SOA project cleaning, compiling, packaging, deploying, testing and reporting.
Local Automating Testing using the SOA Test Framework and Maven
It is assumed that you have installed Maven and configured it with the SOA Sync plugin that can be used to populate your local Maven repository with all the SOA dependencies that are required to compile, build, package and deploy SOA projects. If not, follow this other blog: https://solutionsanz.blog/2016/12/22/teaching-how-devops-can-locally-automate-your-soa-workloads-deploying-into-soa-cloud-service/ – For this, in the very last section you deployed a SOA Project into a SOA server (locally or remotely)
Build a Testing SOA Application
First, let’s create a brand new SOA composite that we are going to use as the SOA Project to compile, package, deploy and test.
- Open JDeveloper if not already opened.
- Create a new SOA Application and SOA Project in it with an empty composite.
- Drag and drop a BPEL and configured it as synchronous, with a SOAP endpoint and accept the default input and output types.
- Drag another BPEL, but this time without the SOAP endpoint.
- Wire the first BPEL to the second BPEL component.
- For the first BPEL, add the proper Invoke and Assign activities
- For the second BPEL just return the input to the output variables and even concatenate something else if you want to.
Your second BPEL will look like this:
- At the end you should have a composite that looks like this:
-
Using the usual ways, deploy your composite to your testing environment (Integrated WLS in JDev) – for this you will have to start the Integrated server if it is not already started.
For this, on the JDeveloper toolbar click on Run > Start Server… – If it is the first time, it will ask you to enter a WebLogic password and it will take a bit longer to start
Wait until it is “Running…” – The first time might take a bit longer, as it has to install some components.
- Using the EM, send 1 or 2 test cycles to ensure everything is operational as expected.
Input:
Output:
Flow Trace:
Build a Test Suite and Test Case
Now let’s create a simple Test case that we will use as a Test Unit capacity. For this:
- Open JDeveloper if not already opened
- Right click on the SOA Project and click on New > From Gallery
-
Select Composite Test within SOA Tier > Tests > Composite Test – Then click OK
- Enter a sensible name for your test case, also click on the green plus icon to create it under a test suite – Also enter a sensible name – These are the name of tests that are going to be run as part of your automated Unit Test, make sure you enter a name that will be understood and relevant for that particular use case.
Then click Next.
- This step, “Service step” is when in real life you select the input operation that you want to test out of your composite. Given there is only one at this time, just click Next
- The next step is where you have to enter the Input – Normally it is expected that you will already have in mind a potential input – perhaps it is already a “known input” that comes from the calling component. In this case simply “Load the file” – Otherwise, like in this case, you can generate your own sample data and modify it as you wish.
Then, click Next
- Finally, you have to setup the expected Output. Similarly, in real life you are expecting a specific response, based on the actual integration with the other components in your composite. In this case simply load the file. Otherwise, like in this case, you can generate your own sample output and modify it as you wish.
Then click Finish.
- This will generate the Test Case, which looks like the composite but with dotted lines connecting the different components.
-
Also notice that on the first dotted line, between the exposed service and the first BPEL there is a small green arrow.
This means that what you did before automatically generated “2 Assertions” – Double click on the small green arrow in between to open the “Asserts and Emulates” configuration window. You can also see this in the “Wire – Properties” window at the bottom of JDeveloper.
-
Feel free to click on each of the Asserts and select the pencil icon to see the “Assertions” that we configured before.
Notice that when you create or edit an Assertion, you can either choose to Assert on the Input, Output, Callback or even Fault. This is done via the radio button on the top of the “Edit Assert” window.
-
Now click on the second dotted line between the two BPEL components. This time we are not going to add assertions (which you can if you want), but we are going to add an “Emulation” (Mock Service) – For this once click on the “Emulates” tab and click on the green icon to create a new Emulation (mock service). Similarly as with Assertions, you can load it from a file or simply generate one and edit it as required. In this case, click on “Generated Sample” and enter some response such as Hello Back – If you have been following the screenshots, we are expecting “Hello World”, but we will return “Hello Back” – This clearly has to fail at some point. We’ll cover this later on.
Notice that with emulation only the “Emulate Output” is available – This means that ultimately you will hardcode a fixed response as the output for that component, this is also known as a Mock Service. This is very useful in those situations when you want to isolate third party dependencies and fully focus on how a particular component would respond to different types of outputs. Also this is convenient when you still have not created a particular integration, but you can simply assume a specific response and use this to test the components that you have created. The choice is yours!
-
Click OK
-
Your Test case should look like this:
- Save All and click on the Play icon on top of the Test Case to play just this Test Case.
Otherwise if you had more test case that you want to test, you can right click on the Test Suite and select the “Run Test Suite” option
Similarly if you had multiple Test Suites, you can right click on the “TestSuites” level and choose “Run Test Suites” option.
This time, since we only have 1 test case, all options will equal on the same result.
Notice that we are deploying on the “Integrated WebLogic domain” by default – Although this behaviour can be modified as it will be shown below, the reality is that this results a very simple way to unit test your own composites in an isolated way.
-
Make sure that the Integrated WebLogic server is running and click on the Test Case green Play icon.
By default it will ask you on which server, leave localhost or the default for your computers name and click OK
- Then it will ask you to tick the test cases that you want to run, in this case there is only one, so click on OK.
- Since we have modified our SOA Application since the last time we have deployed, then it will ask us to re-deploy, say OK.
Wait for the SOA Project to be cleaned, compiled, built, deployed locally. As soon as it is deployed, the test case will execute and at the end it will show you the report.
- Once the test completes notice the report that it brings on. In this case we can see that something went wrong with one of the Assertions.
- Click on the Expected/Actual XML links and notice the deviation.
-
As you can see clearly, the Assertion was expecting “Hello World“, but it received from the Emulator “Hello Back” – We framed this on purpose to show how an assertion failing. At this point if your test case was part of an automated Continuous Integration framework, for example using Hudson, then the whole Build would be marked as “Failure” and would make sure it is noted with icons, alarms, etc.
- In our case, to fix the test case is simple, simply come back to the Emulator and change the emulate output to “Hello World“.
- Save all and re-test your test case. It will ask you to redeploy.
- This time the report will be totally a success.
- Click once again on the “XML” links for the second assertion and notice how this time the expected and actual payloads are the same.
Notice that when you define the assertions, you can configure whether the XMLs have to match completely or simply they have to be similar:
In our case we chose “XML Similar” – which implies that as long as the XML are equivalents, they don’t necessarily need to match. For example XMLs can have extra spaces, new lines or even the way they treat namespaces can be totally different, but still be schema-based syntactically equivalent.
Pretty cool huh?
If you have any question or comment, please feel free to contact any of the authors in SolutionsANZ.blog
Thanks for your time.
RedThunder.Blog 
Thanks Carlos – thanks for putting this was together. Used it to put together a Developer Cloud Service sample to automate the tests and present test reports as part of the automated build. Will be posting about it soon.
LikeLike
Hi, We have AIA based reference architecture with requestor, EBS and provider services. Most of our flows are triggered by a file and the interactions are one way (i.e. no response). How can we use SOA test cases in such case and automate the testing using maven. Thanks.
LikeLike