TO DO - Unit Testing Stages within a Local/Shared Container 🔒

The Given and Then clauses of Unit Test Specs associate Unit Test Data defined by the path property with links within the DataStage Job under test. Links within a Job are uniquely identified by the stage and link properties:

given:
  - stage: sqInput
    link: in
    path: given.csv
...
then:
  - stage: sqOutput
    link: out
    path: expected.csv

Local and Shared Containers complicate this as Stage names in DataStage are only unique within a given Job or Local/Shared Container. Consider writing a Unit Test Spec for the following Job and Shared Container:

given:
  - stage: sqAccounts
    link: inAccounts
    path: GivenAccounts.csv
when:
...
then:
  - stage: sqAccounts
    link: out
    path: ExpectedAccounts.csv

The resulting Unit Test Spec is ambiguous because the Unit Test Harness will not be able to uniquely identify which Unit Test Data file is associated with each sqAccounts stage. To avoid these sort of issues, the stage properties within Unit Test Specs expect fully qualified stage names. A fully qualified stage name is the stage name prefixed with all parent Local/Shared Container names using the following format <container name>.<stage name>.

given:
  - stage: sqAccounts
    link: inAccounts
    path: GivenAccounts.csv
when:
...
then:
  - stage: ContainerC1.sqAccounts
    link: out
    path: ExpectedAccounts.csv

Since the output sqAccounts stage is within ContainerC1, its full qualified stage name is ContainerC1.sqAccounts and the Unit Test Spec is no longer ambiguous (line 8). When working with shared containers, the <container name> within a fully qualified stage name refers to the stage name in the parent Job (ContainerC1) rather than the Shared Container itself (scWriteAccounts).

The MettleCI automated Unit Test Spec generator will handle input/output stages within local containers but not Shared Containers. Due to the design time information available for a job, Unit Test Specs generated for jobs using shared containers will have the inputs and outputs for the job modeled correctly but it will omit any inputs or outputs that are within Shared Containers. The unit test harness can handle inputs/outputs contained within local and shared containers, but inputs and outputs within shared containers need to be manually added to Unit Test Specs.

When Unit Testing stages within Local and/or Shared Containers, developers should be aware of the following requirements and constraints:

Stages in multiple levels of containers can be defined using <container name>.<container name>.<container name>.<stage name> where the left-most container name is the top level container, the next container name is the second level and so on.
When working with Shared Containers, the <container name> is the name of the Stage on the parent canvas rather than the Shared Container name itself.
Input and Output container stages do not exist at runtime and can’t be stubbed during MettleCI Unit Testing.
The Unit Test Spec and Unit Test Harness make no distinction between Shared and Local Containers. Therefore the use of Local and Shared Containers can be used interchangeably or even mixed within a single Job.