Identify all plugins required to run a test plan

Technical
1

Hi!

I’m currently developing a system for automated testing, based on OpenTAP and Runner. As part of this, the system shall create an image (using Runner functions) consisting of all plugins required to run the selected test plan(s), then set up a session based on the image and execute the tests. To do this, the system must be able to identify all package dependencies for all selected test plans before proceeding with image creation. Unfortunately, I haven’t found any good solution to this and would be thankful for any help and ideas on this matter.

I have explored a couple of options:

  1. Use the packages (name + version) specified in the test plan under the <Package.Dependencies> tag in the test plan. This would be a neat solution, but it requires all package dependencies to always be present and correct in the test plan XML file. Unfortunately, I’m not sure how to ensure this, as it doesn’t always seem to happen automatically when saving a test plan in the Test Automation application. Is there a setting or similar to have Test Automation always save all package dependencies in the test plan? Or any other means of achieving this?
  2. Loop over all test steps present in the test plans and try to map their types () to the names of all available plugins. This is not a preferred option I figure, as it seems shaky to rely on this kind of comparison.

Does anyone have any suggestions to this?

Thanks in advance!
Tomas

2

Hi @gortom,

1 sounds like the option you should use. It seems like you are experiencing that Package.Dependencies are not correctly written, is that the case? This can happen if a plugin does not exist in package yet, for example in debug builds, but there are way around this.

3

Hi @rolf_madsen,

Thanks for the swift response.

Yes, that is exactly the case. After reading your response, I created a test plan from 1) Test Automation as part of the installation and 2) Test Automation in a debug build. Saving a test plan with 1) seems to generate the package dependencies correctly as expected, whereas (as you mentioned) 2) doesn’t generate the package dependencies (this is probably the way I have done it previously).

Does this mean that using alternative 1) guarantees that package dependencies are always saved as part of the test plan?

You mention that there are ways to get 2) to work as well. Could you please elaborate on this? Would be nice to get that option to work as well, if possible.

Thanks again!

4

The problem is detecting which package a plugin comes from. During debug builds, by default there is no package, since it takes a bit extra time to build that. So in the deployment (setup 1) there should not be a problem, but during development (setup 2) there can be, although the problem only really arises once you start sharing your test plan.

To fix this for development builds you can add the following to your csproj file:

    <OpenTapPackageDefinitionPath>package.xml</OpenTapPackageDefinitionPath>
    <CreateOpenTapPackage>true</CreateOpenTapPackage>
    <InstallCreatedOpenTapPackage>true</InstallCreatedOpenTapPackage>

This will create and install a package for your plugin, but this also means it has to run ‘tap package create …’ after the build.