On Thu, Sep 04, 2008 at 01:45:41PM -0600, Rob Savoye wrote: > strk wrote: > > >About testcases: self-contained ones would be far superior then internal > >ones. One example is the recent Matrix-related test. > >We have NO self-contained testcase failing, still an internal case was > >failing due to misinterpretation of the requirements (the Flash model). > > All of the libamf and libnet test cases are self contained > executables with few dependencies. This way they can test the classes in > isolation, traditional unit testing style.
By self-contained I mean SWF files that can be run with a flash player and unambiguosly tell whether the SWF file is working as expected or not. See: http://wiki.gnashdev.org/SelfContainedTestcases > >In this reguard, about AMF the only self-contained tests we have are: > > > > - actionscript.all/SharedObject.as (SOL) > > - misc-ming.all/NetStream-SquareTest.c (FLV) > > There is also testsuite/libamf.all and testsuite/libnet.all, which > contain over 150 tests. Where are readAMF0's test cases ? There's none indeed, we'll need to add one, but if we work on self-contained ones, automatically whatever is used will be tested, be it element-based or buffer-based. It'd be a detail. > >A task I'd like to undertake is using the SharedObject.as to test > >circular-references, which may prove on-the-road the appropriateness > >of Element vs buffer based approaches. > > Yes, you are hung up on circular references, but as I've never seen a > reference AMF type in the wild (and I've dug around heavily on the net > for examples), so I'm not so worried about this now. Yes, you can wrote > a test case that'll break SharedObject, but why unless you plan to fix it ? Most of the times producing a self-contained testcase for me is a tool for reverse-engeneering. It helps giving you the bigger picture, helps with modeling the later implementation (xcheck is great for that). > If you are just sending numbers or simple data around, yes, you don't > need Element. But once you start dealing with real AS objects with > properties, etc... you will need something like Element. Why ? > >But it is also important to implement a framework for testing other > >uses and to improve the existing ones (FLV for instance could contain > >lots more meta tags for us to test). > > I have test cases for all my uses of AMF. The current code (see > flvdumper) supports any AMF object in a Meta tag, so I don't see the > point. You're welcome to add more test cases to test_flv if you want > more complex tests. I'm not saying Element-based stuff is broken, just not necessarely convenient to use (and most likely unable to deal with circular refs). > >Testcases needing new frameworks: > > > > - Remoting (needs a simple server running during make check) > > - RTMP (needs a simple server running during make check) > > Which is Cygnal, remember ?. I'll be getting back to Cygnal as soon > as rtmpget fully works. We'll be able to use it for testing as well. That'd be a great step forward. --strk; _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
