Closed PHameete closed 5 years ago
If you want to repeat a test run, you need to have a place to save the parameter settings. Currently thats our file system. Where would you store it instead?
The other thing about the templates and the option to edit this within the GUI is good idea and will added to our roadmap
It should be possible to provide the basic information that is always needed - regardless of test suite - via env vars. For example:
General information:
$FEDERATIONNAME
)RTI Specific information:
Pitch:
$PITCH_CRCADDRESS
)MaK:
A better approach is a "template" style approach:
If a TcParams value refers to ${VARNAME}, the TC Runner will get the value from the environment variable with the same name.
I do not see the point in using environment variables for TC-specific information. The test engine (JMSTestRunner) will be started without any bindings to specific test case, or even an RTI. After being started, the engine will only wait for JMS messages to start test cases. With these messages the TcParams will be received.
Maybe I'm misssing something, but for the current approach I do not see where environment variables could help. Maybe if we decide to start one test engine per test case, we might better use env variables.
I agree with you here Reinhard. A template approach seems like a good plan. In my opinion the exact parameters should be provided by the IVCT Operator that fills in some sort of form/request on the GUI when requesting the tests to be run.
My proposal here is to wait until the tc.param template mechanism is finished in the GUI, in order to get some experience with that approach. We need to revisit our parameter concept in order to have a more efficient way to deal with multiple locations for parameter settings. I'll create a new issue for Release 3.0
It seems impractical to me that the IVCT that configuration of a specific TestSuite for a specific SuT needs to be present in the file system.
It makes more sense to me that when selecting a SuT + Conformance Statement we know which TestSuites are required. These Test Suites then provide a 'template' of params that needs to be filled in for the test to be started. The params can then be filled in via the Web UI.
These params can have optional and required fields, and default values if possible to make configuration faster. Implementation could be done similar to Java standard Properties by using Key Value rather than hard-coded variables.