15.3.3.1 Command-line arguments for test drivers
--test-name=NAME
The name of the test, with VPATH prefix (if any) removed. This can
have a suffix and a directory component (as in e.g., sub/foo.test), and is
mostly meant to be used in console reports about testsuite advancements and
results (see Testsuite progress output).
If test-name is _mostly meant to be used in console reports_ why is there
any concern for a path? One can use any string in a report, paths are
unnecessary, and you haven't specified any other use.
So let me guess what you might be trying to say. From 15.3.1 Overview of
Custom Test Drivers Support it appears that the test handler (responsible
for test suite summaries and I suspect for executing test drivers) executes
the _custom test driver_ which executes a test program, which must be a
_test script_. The test script usage is directly contradicted in 15.3.2
Declaring Custom Test Drivers where _ext_ may or may not be a script suffix,
but whose counting.
The _custom test driver_ is responsible for interpreting command line
arguments. One assumption is that when this argument is received the _custom
test driver_ executes the NAME given in the command line argument. Of
course, if this were true then it is possible to input a NAME which is not
one of the known tests given by the developer. I don't know that this makes
much sense, to execute a random script not defined by the developer.
So we come back to the original issue. This command line input must be used
only for reports and has no other use. Whew.
Whoops. In 15.3.2 Declaring Custom Test Drivers we can define many test
drivers_. So the implication is that each _test driver_ receives the same
NAME which seems to (again) imply that NAME is meant solely for
documentation (if the test driver(s) use it). If the _test drivers_ are
meant to execute NAME then that places other requirements on NAME with
respect to _ext_ suffixes (to allow the test handler to execute the correct
_test driver_) or requirements on the _test driver_ to be able to determine
whether it is eligible to execute NAME, with the test handler calling every
_test driver_ until one or more suitable execution candidates are found. In
the latter case there is a requirement on the test handler / _test driver_
interface which requires the _test driver_ to return a status indicating
that it is not an eligible receiver for executing NAME.
So, what other uses does this option have, after all the documentation says
_mostly_?
Maintenance turns design into chaos
