Best practices for handling test parameters?

I have looked into the DutSettings class for managing the test parameters for the entire test, but this does not seem to be what this class was really intended for. It seems to be for settings related to the specific DUT instance under test. Am I wrong? Are there any examples of using this to manage a large array of test parameters? Is there a different TestParameter class that I just haven’t seen? Or do I need to roll my own?

2 Likes

@Tim.Cyr your understanding is correct. OpenTAP is less DUT centric than other automation platforms in that regard. I think there are two main options for you:

  1. Test Plan Settings (I can’t remember if I shared this previously or not)
    This allows you to dynamically build up your Parameter List. Either by right-clicking and selecting “Parameterize” or by embedding in your code by using the Parameterize method:
    Engine.UnitTests/AnnotationTest.cs · master · OpenTAP / OpenTAP · GitLab

  1. Create a Custom Component Settings Object
    ComponentSettings are accessible by any TestStep
    sdk/Examples/PluginDevelopment/GUI/ExampleSettings.cs · master · OpenTAP / OpenTAP · GitLab
1 Like

Ah! I will take a look at both. I can’t do it through the GUI as in your first example, but you said it could be integrated into code so I will look. I need to load my ECO controlled test limits either from a file, or more preferably from a PostgreSQL field. Most likely in XML/JSON format and then parse them in my custom class and make them available to my test steps through one of the classes you mentioned.

1 Like

Please clarify if my understanding is correct…things which are tied to the Test Plan will only be loaded once when the test plan is loaded?
So if I wanted to be able to edit test parameters during debug and support “dynamic loading” at the start of each Test Execution then it looks like the ComponentSettings object would be the best to use?

1 Like

I would say mostly correct. The TestPlanSettings will be loaded once by default. Using the API you can reload these, however they exist individually within each Test Step, so in your case where you are doing what sounds more like a bulk update after reading from a Database, the ComponentSettings would be a better option in my opinion.

2 Likes