This is the seventh article in the series on FlexDeploy’s support for continuous integration and continuous delivery, shown with a use case for SOA that can easily be extended to MDS, OSB, and WebLogic Resource Management.
- FlexDeploy Loves Oracle Fusion Middleware: Overview
- FlexDeploy Loves Oracle Fusion Middleware: WebLogic Configuration Setup
- FlexDeploy Loves Oracle Fusion Middleware: MDS Setup
- FlexDeploy Loves Oracle Fusion Middleware: Service Bus Setup
- FlexDeploy Loves Oracle Fusion Middleware: SOA Setup
- FlexDeploy Loves Oracle Fusion Middleware: Continuous Integration and Issue Tracking
- FlexDeploy Loves Oracle Fusion Middleware: Test Automation
- FlexDeploy Loves Oracle Fusion Middleware: Release Pipelines
- FlexDeploy Loves Oracle Fusion Middleware: Integration with ServiceNow
In this post, I’ll discuss how FlexDeploy handles test automation via our test automation framework.
Test Automation provides the ability to define a set of tests that can be executed as part of the deploy workflow or independently on the project. The tests that will execute are determined by the Test Automation strategy configured on the project. (See the FlexDeploy User Guide for more details.)
The ValidateProcessOrder project that has been used throughout this series is configured for Test Automation that will test the return value from the CalculateInvoiceProcess. If the value isn’t valid, the test will fail and the workflow will stop. This will be configured with SoapUI as the testing tool, however, other testing tools such as Postman can be utilized in the same manner. Check out this blog for testing Oracle Integration Cloud using Postman.
Setup
Getting started with test automation requires general configuration of testing tools, types and workflows. FlexDeploy provides integration with several test tools along with associated workflows out of the box, and others can be added as needed. Test types are user configurable and provide a logical grouping of tests. Test workflows are managed from the Workflows screen while test tools and types are managed from the Administration screen.
The ValidateProcessOrder project below will utilize the following test instance, workflow, tool, and type.
Testing Instance
Create new testing instance and associate the appropriate environments/endpoint where SoapUI is installed. The testing tool needs to be installed independently of this setup.
Testing Workflow
We will utilize an out of the box workflow, “SoapUI-runSoapUITestSuite”, to execute the tests, with all of the available workflows can be found in the workflow screen.
Testing Tool
We will utilize the out of the box defined SoapUI testing tool.
Test Type
We can create any test types that are needed based on functionality of the tests, in this article we will be utilizing Smoke Tests.
On the Test Automation tab of the ValidateProcessOrder project, the strategy defines the test types that will be run in any given environment by instance and project stream. Upon execution of the test step, FlexDeploy will attempt to find a strategy match. Once a strategy is matched, the associated tests will be executed.
- Test Type – select “Smoke Tests” from the drop down
- Environment – select the environment where the test will be executed
- Instance – select the instance that the test will be executed against
Now we need to configure a test set, which is a collection of test definitions. In this example, this can be a grouping of OrderValidation tests.
Since the test set is a collection of one or more test definitions, we need to set up a qualifier. At this level, the qualifier determines how many of the test sets need to pass for the overall test type to pass. The qualifier is setup with a greater than condition and there is only one test set in this solution. Setting the value of the condition to “0” indicates that the test set must pass for the overall test to pass.
Each test set can have one or more test definitions that will define the tests to execute. For the ValidateProcessOrder project, we have one test definition (ValidateOrder) that performs a test against the value returned from the secondary process. Other order validation tests can be added as needed. The test definition is configured as follows:
- Workflow – select the pre-configured test workflow for SoapUI test suites
- Arguments – provide the individual test case to run for this definition from the SoapUI Test Suite
- SoapUI Project File – provide the path, relative or absolute, to the SoapUI Test Suite that contains the test case
- Testing Instance – select the appropriate testing instance for where the tests will be executed on
At this level, the qualifier determines how many of the test definitions need to pass for the test set to pass. The qualifier is setup with a greater than condition and there is only one test case in this solution. Setting the value of the condition to “0” indicates that the test definitions must pass for the overall test set to pass.
The final configuration that is required is to execute the test strategy by adding an InvokeTest step to the deploy workflow. The user can either indicate a specific test set to run or by leaving the inputs blank, all tests associated with the matched strategy will be executed.
Execution
Once a successful deployment occurs to the Development environment, the Smoke Tests strategy will be selected and the test definition (ValidateAmount) will be executed.
The overall test execution status can be checked from the project execution screen by selecting the execution id link for the development deployment.
Selecting the Test Results link will show the overall test set status. In addition, you can drill down into the test sets to see the actual results of each test case. In the next blog in the series, we will utilize the test results to drive the next action in the release.
Conclusion
And just like that, we configured FlexDeploy to run tests and utilize the results to drive the next steps in the workflow.
The next post in this series will cover release automation via release/pipeline configuration and execution, and change management.
