On Wed, Feb 13, 2008 at 11:59:38AM -0500, Sean McNamara wrote: > 8. Testing layer: I have not written any tests yet. I am unfamiliar > with ALL of the testing frameworks currently used by Gnash, and would > appreciate any help or guidance in getting some unit tests written. > Since I would like to get this committed sooner rather than later, I > would prefer to write what the developers would largely consider > "minimally acceptable" to test this functionality, see that it passes, > and submit the patch for review.
For the configuration part adding tests to testsuite/libbase/TCXXRc.cpp (includes adding to gnashrc.in and gnashrc-local.in) would be enough. The -local one is to test modifications of settings, like 'append' or 'set' for overrides. For the functionality part I think your configurable pipeline might actually be a tool for proper testing, which we currently don't have at all. When tests are run, there's a specific gnashrc being used: testsuite/gnashrc.in. Is it possible to specify a custom element there for the specific task of automated testing ? So far, the only automated testing we do is counting the number of sounds started and stopped. Is more of an AS test then of a sound test. Beside that, we also have only a single test, and probably not testing much... Improving the testsuite should include testing all controllable features of a sound, and all supported encoding. Testcases can be produced in steps. First step is for human analisys, second step is automating it. Of course while writing the test automation is worth keeping in mind. Out current lonely test is made using Ming, but this is not mandatory, we have testing frameworks for other compilers too. IIRC another sound-related test is in misc-swfc.all. --strk; _______________________________________________ Gnash mailing list Gnash@gnu.org http://lists.gnu.org/mailman/listinfo/gnash
