[Q] Creating a test profile with multiple tests

[myxal]

Hi,
I'm trying to combine several tests which use the same (separate internal) framework into a single test profile.
I've noticed, for example, in etqw-demo, that some CLI options are configured as default (xml path .../Testsettings/Default/Arguments and .../PostArguments), while some are configurable (xml path .../Testsettings/Option/Menu/Value).
Questions:

• What exactly is the difference between .../Arguments and .../PostArguments? Where/when is each of them used?
• I assume the entire value of .../Default/Arguments and .../Option/Menu/Value is something that is relevant only to the etqw binary. Is this correct, or are some of those strings (+set) an interface to PTS?

My goal is, I need to define several "tests" in a manner that is similar to the blogbench test profile, (.../TestSettings/Option/Menu/Entry), each of which would pass different arguments to the test script.

As I understand it, I should make multiple Entries under Option and set Option/Menu/Entry/Value to the commandline arguments I wish to pass. Is this correct?

[myxal]

OK, never mind - the behaviour is exactly as expected (entire <value> is posted to the test's executable command line).
I'm having another problem, though, with the pre/post/interim scripts - is the value passed there too? I tried to echo $@ from the script to check, but I'm getting no output whatsoever.

[Michael]

I'm having another problem, though, with the pre/post/interim scripts - is the value passed there too? I tried to echo $@ from the script to check, but I'm getting no output whatsoever.

At the moment I don't believe I am passing it (but it might be exposed via an environment variable like TEST_ARGUMENTS). Otherwise you could always write the arguments to a temporary file from the main test script and then have the pre/post/interim scripts read from those. Would that work for your case? Any new tests are welcome upstream


Thanks.
Michael

[myxal]

At the moment I don't believe I am passing it (but it might be exposed via an environment variable like TEST_ARGUMENTS). Otherwise you could always write the arguments to a temporary file from the main test script and then have the pre/post/interim scripts read from those. Would that work for your case? Any new tests are welcome upstream


Thanks.
Michael

Hi Michael,
I'm not sure how the environment variables work, but I've tried to have pre.sh write down the output of env to a file, and nothing like the test argument I was passing showed up. Sure, passing the arguments of files would work, but I ended splitting the test profile into three separate profiles according to the different actions needed to perform in pre.sh.

The profile I'm working on at this point is a company internal stuff, sorry. I wouldn't mind cooking up some profiles to benefit PTS - is there any TODO list or a particular piece of software you'd like to have a profile for?

[myxal]

Hi Michael,
Sure, passing the arguments in files would work.

No, wait. This actually wouldn't work, since pre.sh is run before any script that actually gets the arguments, so there won't be any file to read the arguments from. Oh well, guess I was right to split up the test profile after all.

[Michael]

The profile I'm working on at this point is a company internal stuff, sorry. I wouldn't mind cooking up some profiles to benefit PTS - is there any TODO list or a particular piece of software you'd like to have a profile for?

There's some possibilities listed @ http://phorogit.com/index.php?p=phor...a58aad4d3b072f

Pretty much any new and useful tests are welcome.