Architecture school

Architecture School is the default perspective of HCL DevOps Test Integrations and APIs (Test Integrations and APIs). 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.

Environments

You will probably need to run your tests in different environments. Changing the environment must not affect your test artifacts and require you to make amendments.

Consider the following points:
  • Define all your environments, environment variables (tags), and bindings in the logical view.
  • When modeling, make a note of operations that reference transports. Put any information that you might want to change at run time in environment variables and reference the variables. An example of this would be queue names.

The environment name is also used in HCL DevOps Test Virtualization Control Panel (Test Virtualization Control Panel) when publishing stubs. For example, if one tester labels his development environment "DEV" and another tester labels her development environment "DEV1", problems might be encountered when running the affected stubs in Test Virtualization Control Panel.

Therefore, environment names must be labeled correctly, and it is advisable that the test architect defines the name of each environment.

Logical view

Consider the following points:
  • When modeling operations, put IBM® WebSphere® MQ queue names in environment variables. This enables you to change the queue names at run time when you are, for example, publishing different stub versions.
  • Put as much information as possible into the logical view. The more information, the easier, and quicker it is to create tests and stubs from the wizards.

Physical view

Define a physical artifact for each environment and give it a meaningful name. For example, if you define a WebSphere® MQ connection for your development environment, you must do these things:
  • Create other connections for your other environments.
  • Add the bindings in the environment editor.

Synchronization view

Consider the following points:
  • If the technology under test permits, you can synchronize to create your model of the system under test. For example, in web services tests, you can synchronize against a WSDL document, which imports all the schemas and operations and creates the logical and physical views for you.
  • Synchronize often to make sure that you have the latest imported artifacts.

Schemas

Consider the following points:
  • If any of the schemas associated with Test Integrations and APIs are not located by URL, copy them to a specific folder within the project's folder. Do not reference the schemas as files elsewhere on your computer. Having the schemas within the project has two advantages:
    • It helps to debug any project resources if things go wrong.
    • It makes it easier to move your project to another location.
  • If you are using DFDL schemas, they must be included in the project's folder if you want to use them in a deployed stub.