SOA and DevOps Test Integrations and APIs

HCL DevOps Test Integrations and APIs (Test Integrations and APIs) primary intent is to simplify the process by which the user builds tests (that is, schema-driven message creation, test driven development, and so on).

One of the main ways that Test Integrations and APIs can simplify the process is through recording. You can capture messages and events from an existing system to help you in the rapid creation of regression tests.

Test Integrations and APIs separates the more complex task of learning about the system and configuring the application from the tasks of designing and executing tests.

Test Integrations and APIs makes it easy for you to design tests by recording a series of events and then using a selection of these events to provide the framework for the test steps from which they work.

In a practical setting, different users use Test Integrations and APIs to design, build, execute, and evaluate tests. Test Integrations and APIs uses different perspectives that are intended to be used by these different groups of users. The following topics describe the different phases of testing and include information about the perspective within Test Integrations and APIs that are used during each phase.

Design phase. System Administrators and Architect

The design phase is the main focus of System Administrators and Architects, and they work in the Architecture School and Test Factory perspectives in Test Integrations and APIs. The main focus of the design phase is to create the following information in Test Integrations and APIs so that users can start building tests:

  • The components that make up the system along with the individual operations that are to be tested, including how they are to be invoked.
  • A description of the systems physical infrastructure, including all of the transport and configuration details of the systems testable components.
  • The dependencies between the system components (for example, when you are running Process A, it invokes process B and C and write data to Database D).
  • A collection of schemas that is applied to the messages used in testing the various transports and components within the system.
  • A comprehensive list of requirements, which are built in the form of messages that contain all of the applicable test data. These messages can be used to quickly create tests and stubs that immediately contain realistic data.
  • A list of environments that bind logical components to different physical components. Use them to quickly test different parts of the development lifecycle by using the same set of tests.

Build tests. Software Engineers and SQA Engineers

Software and SQA Engineers build most of the test resources in Test Integrations and APIs, and they spend most of their time in the Recording Studio and Test Factory perspectives.

Once the system to be tested is designed, users can start building their tests (unit, integration, acceptance, and so on). Test Integrations and APIs provides a number of ways in which tests, test suites, and stubs can be created:

  • Operations can be selected for monitoring, and Test Integrations and APIs "listens" on the transports and other components that these operations include. Live messages that are generated by or passed through the selected operation are recorded in Test Integrations and APIs. These can be used to quickly create tests, suites, stubs, or triggers.
  • Users can create tests manually, by using a wide array of "test actions" to create an almost unlimited number of scenarios.
  • Stubs can be created to simulate missing or otherwise unavailable systems upon which other test resources depend.

Execute tests. Software Engineers and SQA Engineers

When the time comes to execute tests, software engineers and testers have numerous options available, both within and outside of Test Integrations and APIs.

Tests, stubs, and suites can be executed in the Test Lab perspective. You use the console to monitor progress and results, and the Test Repair wizard to fix validation errors.

Note: While tests can be executed from other perspectives in Test Integrations and APIs, the Test Lab provides the main functionality for doing so.

In addition to working directly in Test Integrations and APIs, several methods of executing tests are available, including command-line execution and ANT. For more information, see External tools.

Evaluation. Software Test Manager

Throughout the testing lifecycle, the Software Test Manager needs to know how effectively the system is being tested, and the individual results of various tests and scenarios. The Results Gallery perspective provides a comprehensive collection of detailed reports, as well as coverage, and error reports. Additionally, the Results Server provides a web-based view of project results.