[qmtest] List test ids at command line?

[Stefan Seefeld]

Mark Mitchell wrote:
 > Andrew Funk wrote:
 >
 >> Hi,
 >>
 >> Is there a way to list all the test ids in a database from the qmtest
 >> command line interface?  I realize this would essentially be a listing
 >> of the directory tree, but for my application (generating tests at
 >> runtime) it would be a helpful feature.  I think it will be simple for
 >> me to implement but I thought I should check first in case it is already
 >> in there.
 >
 >
 > No, there's no way to do that.
 >
 > Yes, that could be useful, but it would be much nicer if it would work
 > as follows:
 >
 > (1) Accept a --kind parameter that allows you to say what kind of
 > extensions you want displayed (tests, suites, resources, etc.).  If no
 > --kind parameter is displayed, show everything.
 >
 > (2) Accept a series of optional arguments (e.g, "test1
 > suite1.subsuite2") and show information only for those entities.  In
 > other words, operate like "ls -R" with no arguments, and like "ls -R foo
 > bar" for arguments "foo" and "bar".
 >
 > You could call the new command "qmtest list".


Hi there,

I'd like to follow up on this thread as I'm looking for this very feature
in my own test suite right now. Re-reading the above, I'm a bit confused
as I don't understand the relationship between 'list of all tests in a
test database' and 'list of all extensions'. Is the former really a special
case of the latter ?

For me, the former is a feature that I would expect as part of the functionality
offered by test databases. I.e. instead of 'qmtest run' iterating over all
tests and running them, 'qmtest list' would iterate over them displaying
tests with various attributes associated with them (id, test class, etc.).
I do understand that the test instances I would need to inspect are objects
of type 'Extension'; however the way to access them seems to me very specific.

How can we provide a generic 'list all extensions' API if that requires
radically different implementations (and even semantics) depending on the
'kind' of extension ??

And, on another argument discussed in this thread related to multiply associated
tests, where you suggested 'implicit suites' would be the way to pick unique
tests, isn't that restricted to specific test database implementations that
use these suites ?

Thanks for any clarification,

		Stefan