Home
Getting Started
This guide provides an overview and describes the tasks to get you started with HCL OneTest™ API.
Testing methodology
By following four basic guidelines, you can incorporate HCL OneTest™ API into your testing methodology. These guidelines drive efficient and expedient integration testing, and they can be applied to your testing process and infrastructure requirements.
Project structure
When an HCL OneTest™ API project is created for the first time, the project folder structure is created on a disk.
Implementing tests
As the number of tests grows, it is important to be able to differentiate tests. If you can deduce information from the test name, you avoid wasting time while searching for a specific test.

Getting Started
This guide provides an overview and describes the tasks to get you started with HCL OneTest™ API.
- HCL OneTest™ API overview
  You can use HCL OneTest™ API to create, modify, and run service tests.
- Testing methodology
  By following four basic guidelines, you can incorporate HCL OneTest™ API into your testing methodology. These guidelines drive efficient and expedient integration testing, and they can be applied to your testing process and infrastructure requirements.
  - Test approach
    The HCL OneTest™ Studio product suite fits easily into a V-Model approach. The classic V-Model demonstrates each phase in predevelopment and its associated phase in test planning. For example, when the system design is delivered, begin planning for system testing. Testing activities such as design, analysis, planning and execution must happen throughout the entire project life cycle.
  - Test phases
    Apart from being used for driving early test plans, HCL OneTest™ API can be used to shift testing earlier in the software development lifecycle (SDLC) than is traditionally possible with standard test tools that test at the UI level. Soon after you have a local build, you can use HCL OneTest API to do service unit testing.
  - Building tests
    HCL OneTest™ API separates the task of learning about the system from the tasks of creating test resources, designing (building models), creating and recording test assets, and running tests.
  - Project structure
    When an HCL OneTest™ API project is created for the first time, the project folder structure is created on a disk.
    - Folder structures
      As the number of artifacts grows, a project might start to look disorganized and tests and stubs might become difficult to locate. Adding meaningful logical folder structures means that test artifacts can be organized neatly and found quickly.
    - Architecture school
      Architecture School is the default perspective of HCL OneTest™ API. In this perspective, you build the system to be tested in a simple, graphical fashion, and define the logical and physical system components and their relationships to one another.
    - Implementing tests
      As the number of tests grows, it is important to be able to differentiate tests. If you can deduce information from the test name, you avoid wasting time while searching for a specific test.
      - Test data
        Where possible, put test data sets in the project's directory, either under each operation or in a separate data sets folder. This helps with portability and maintenance of your project.
      - Creating test templates and test suites
        You can implement several tests with similar logic. When creating tests, define a template if a test is repeatedly created. Test suites are used mainly to construct reusable, packaged regression tests that can be run across multiple environments, or repeatedly within the same environment.
      - Running tests and test suites
        You might decide to run tests individually or to create a regression suite and then add your tests to the suite.
      - Implementing stubs
        When you implement stubs, you want to consider a few points such as naming conventions and folder structure.
      - Stub performance
        Performance usually matters for stubs because they receive requests with a high level of frequency.
- Service-oriented architecture (SOA) testing
  A SOA consists of business processes that are implemented by linking individual services. The linking can be done programmatically or with tools based on Business Process Execution Language (BPEL). SOA testing can be challenging because there is no GUI; the focus is on testing interfaces and services.
- Getting started with testing
  You can start using HCL OneTest™ API by completing the preliminary tasks such as creating and running a test, creating and running a stub, recording an HTTP proxy, and running a stub in a Docker container.
- HCL® Quality Server overview
  HCL OneTest™ Virtualization stubs designed in HCL OneTest API are published to HCL® Quality Server, which holds them in a repository.
- HCL OneTest™ API accessibility features
  Users who have a physical disability, such as limited vision, can review the available accessibility features to use HCL OneTest™ API.

Implementing tests

As the number of tests grows, it is important to be able to differentiate tests. If you can deduce information from the test name, you avoid wasting time while searching for a specific test.

Consider the following points:

Use good naming conventions to name your tests.
Create logical folder structures to store your tests.
Create parameterized tests that are driven from spreadsheets or other data sources. The data that is defined in spreadsheets can cover as many test cases as possible, reducing the number of tests to implement.
Creating repeating tests can take time. When you are creating tests, define a template if a test is repeatedly created.
Link your tests to message requirements as far as possible. When you are linking requirements to tests, a change in the requirement propagates the changes automatically into your tests.

Some automation tests can become complicated and difficult for your colleagues to understand. They are also more tedious to debug.

Use the following tips to avoid confusion:

Write your tests as generically as possible.
Create common function or subfunction tests that can be called by various parent tests by using the Run Test action. This reduces duplication and errors.
Use the Business View to add meaningful descriptions of what each action in a test does.
Use the Comment action to describe difficult steps in a test and to offer clarity.
Use the Documentation tab of a test to add a description of its functionality.

A new, empty test always consists of three basic phases: initialize, test steps and tear-down. The essential usage of these phases is as follows:

The initialize phase can be restricted to running commands that start or configure plug-ins, servers, or target resources. This phase can be used for test preparation (for example, populating environment variables). However, if these variables are overwritten in the test steps, they are not restored to their original values.
The test steps phase can contain the actions that are used in the test. If the test is part of a repeated or concurrent execution (by using a stub), the test steps phase is the only one that is run for each iteration.
Similar to initialization, the tear-down phase can be used only for deallocation of resources, termination of processes, and so on. The tear-down phase is run only by the last test to be processed when run repeatedly or concurrently.