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.
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 ?
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 ?
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.
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.
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.
- rob -
_______________________________________________
Gnash-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnash-dev
