This is the mail archive of the
mailing list for the GCC project.
Re: QMTest and the G++ testsuite
> Unit testing may be better in QMTest's model but do you have any
> comment on how it will cope with interactive testing? Without using
> expect or something like it, CAN it cope with interactive testing?
QMTest works at approximately at the same level as DejaGNU.
In DejaGNU, you call various routines "fail", "pass", etc. to say what
tests passed and failed.
In QMTest, there's a bit more structure; there are objects call "tests"
and the system calls their "run" methods to run them. They return
PASS, FAIL, etc. (This structure is an advantage; it means that the
system can intelligently manipulate your test database, and it gives
you ways of connect the test database to bug-tracking software, etc.)
In neither case is their really *built-in* support for much more than
that. DejaGNU comes with a useful library full of routines that help
you do various things, including interactive testing and funky
cross-machine magic. As Alexandre has pointed out, QMTest's library
is smaller at the moment.
The answer to "can it cope with interactive testing" is "yes". In the
reduction-to-absurdity case QMTest test cases can invoke DejaGNU and
report the results. (There are actually reasons to do that, but
we don't need to get into them here.) Yes, you can use expect. Or,
you can do something else -- whatever you like.
There is, as with any tool, a migration cost.
Note that the cost, however, is not linear in the number of test cases;
it's linear in the number of kinds of testing you're doing. For example,
converting the G++ testsuite didn't involve touching the tests at all;
it wasn't really very much work.
As a measure, it took fewer than 1000 lines of code to support the entire
G++ testsuite; it took only a couple of afternoons. Much of that work
will also be useful in the GCC testsuite, and some in GDB as well.
(There are bits that know how to compile code, for example, that can be
sahred.) Some of that work has also given us ideas about how to provide
more features in QMTest directly; when we do that, even more of the
code will disappear.
Mark Mitchell firstname.lastname@example.org
CodeSourcery, LLC http://www.codesourcery.com