This is the mail archive of the
mailing list for the GCC project.
Re: QMTest and the G++ testsuite
--On Wednesday, May 22, 2002 09:28:19 PM -0300 Alexandre Oliva
> On May 22, 2002, Mark Mitchell <email@example.com> wrote:
>> In QMTest, there's a bit more structure; there are objects call "tests"
>> and the system calls their "run" methods to run them.
> What if the test consists of a number of steps. In GDB, a larger of
> features are tested using a single program, built out of a single
> source file. This is particularly important because uploading a
> program to a board is very often extremely slow, so you don't want to
> artificially increase the number of programs you have to upload.
> OTOH, you want separate results for each of the features tested in the
> testcase. How can you do this with QMTest?
What you can do is have the test database give you (say) five tests.
The "run" methods for these tests, however, checks cached global
information about what happenned from the single monolithic run.
(The first test to run can actually run it.) So, you get all the results
as separate tests, but you don't have to actually do the expensive step
There are other mechanisms as well, but that's one that will work.
(There's also a notion of "resources" designed for, again, avoiding
performing expensive steps multiple times.)
>> In the reduction-to-absurdity case QMTest test cases can invoke
>> DejaGNU and report the results.
> But IIUC the final result will be a single PASS or FAIL, which is not
> all that useful.
If you do it that way, yes. One of the strengths of QMTest is the
ability to provide detailed results information in a structured form.
If you want that detail, you have to interface through Python -- or
get the thing that you are invokving to provide that detail in way
that you can read it back in from your Python code.
Mark Mitchell firstname.lastname@example.org
CodeSourcery, LLC http://www.codesourcery.com