Sharing and managing stubs

If the purpose of a particular HCL OneTest API project is to develop and test a component that requires virtualization (stubbing), that project must own that stub but it can be shared across other projects that need to use it.

A change in stub function can be carried out by the stub owner, unless there are specific reasons why another the project might need a different version. In that case, other projects can develop other versions of the stub. However, coordination between projects will be mandatory and the reason for a different stub version must be logged and traceable.

It is likely that other projects that are joining the system under test will want to interact with a stub owned by another project because they might be sharing components that are unavailable.

Consider the following points:
  • If the same stub version is used, there might be no problem so long as the performance of the stub is satisfactory.
  • If a different version of the stub is required, the different stub version can be created and maintained by the project that requires it.
    Note: Change endpoint parameters, such as queue names, to ensure that they do not clash with the original stub.