From: Stefan S. <se...@sy...> - 2004-08-10 23:19:37
|
Gilles J. Seguin wrote: > Tests for the occ binary on the PATH environment variable > <http://www.infonet.ca/segg/occ.tgz> > will unpack in occ directory. > $ cd occ > $ qmtest run # will run everything. > $ qmtest run parse # will do the same as 'qmtest run' > since we have only one directory. > $ qmtest run parse.access1 # will run only one test. > > The tests examine results from 'occ -p -s myfile.cc' nice ! Some suggestions, though: you hardcode the path '/usr/bin/occ' in each single test descriptor. I'v just changed one to see that it works, and I'm not going to edit all these files :-) What I'd suggest to do instead is defining a new test (python) class that is then registered with the database and used for all tests. Then you can configure paths and other stuff right into this class *once*. Second I think it would be good to substructure the tests. In fact I'd suggest to write a new 'test database', and then use the subdivision into test suites to set up test types for each suite separately. That will allow to tailor the test types, for example one suite/folder to test the Encoding class, one to test ptree generation / manipulation, etc., etc. Note that this is exactly the approach I'v taken in synopsis, i.e. I wrote my own database and a handfull of test classes to do various things (one test class compiles a C++ file and executes it, another runs a particular synopsis processor on a specific input file, you get the idea...) That said, I think what you'v done is a nice starting point ! May I integrate it into my existing testing harness ? Regards, Stefan |