[gst-devel] random stuff

[David I. Lehn]

* Thomas Vander Stichele <thomas at urgent.rug.ac.be> [20020103 05:57]:
> * I'd like to move some of the tests out of the core - since they test
>   plugin functionality - and go over all of them to see how we can fix
>   them.  I've had to disable too many of them lately ;) and tests are
>   useless if we don't maintain them.  They should tell us when the core
>   or plugins break, not tell us that we're lazy.  Do we need the three
>   separate test dirs (test/tests/testsuite) or can I put them all in one ?
>   any suggested structure here ?
> 

In theory we could work on a automatic testsuite.  At one point I had
ambitions to create a md5sink so we could push a vob in one end of a
-launch pipeline and calculate md5 sums on the output audio and video.
On EOS print out the sums and compare with known results.  Wouldn't that
be neat?  Could probably write a bunch of automagic tests for various
plugins like that.  Fragile with respect to changes in the codecs but
the md5sums could be compared with results for various codec versions or
whatever.

That would be different than sample/example apps that are more
interactive in nature.

And those are different than just plain simple quick work-in-progress
tests.  Though those should arguably be converted to automatic tests and
added to a testsuite at some point.

So I don't know how to organize it.  testsuite/ for automatic tests,
examples/ for sample high level usage apps (dvdplay, mpeg2parse*.c,
etc), and tests/ for other stuff?  Then I guess need to figure out which
of all these belong in the core vs plugin module.  fun fun fun!

-dave
-- 
David I. Lehn <dlehn at vt.edu>  | http://www.lehn.org/~dlehn/
Computer Engineering Graduate @ Virginia Tech in sunny Blacksburg, VA