[x3d-public] Possible effort + paper for X3DJSAIL and friends

[John Carlson]

Mostly, I'd like to test adder/remover methods for children, fields,
fieldValues, connect, and meta.  These are the low hanging fruit right
now.   I suggest we use some variation of xmldiff.js for comparing nodes
and node children...maybe statements too.  Probably the tests would leave
the scene graph in the same shape it was before the test.  Just thinking
out loud.  Also suggest we create assertEquals() which may just compare XML
strings.  It looks like we can add many more asserts as is found in x3d.py

Lots of stuff we can discuss.   Probably a lot has already been discussed
years ago before I got seriously involved in X3D.

We'll also need to discover which properties start with uppercase instead
of lowercase for es6.  Is there any guidance from the standard on
JavaScript/JSON property name casing?  I know that es6 may require first
letter uppercase in some cases, but at this time, I am unsure why...type
comparison?

Firstly though, I'd like to create some roundtrip tests for XML generation
from JavaScript.  That is, XML -> Serializer/Stylesheet -> JSON -> XML DOM
Document -> ES6 structure -> XML.   If we had a way to convert XML to ES6
in a single step (Jeff?), the roundtrip test would be easier.  I have one
serializer which takes a DOM document and produces JSON.  Is XML to ES6
warranted?  Should we do it in JavaScript (SAX parser?
DOM2ES6Serializer.js?), Python or XSLT?

Thanks,

John

On Mon, Aug 31, 2020 at 5:46 PM Don Brutzman <brutzman at nps.edu> wrote:

> John, thanks for the good thinking here.
>
> Creation of unit tests for full code coverage is always worthwhile.
>
> As a way to integrate this with how we currently do business, have taken
> the following approach with X3DJSAIL (Java), X3DPSAIL (Python) and X3D
> Ontology (Turtle).
>
> a. Conversion of .x3d scene into respective source code (.java .py and
> .ttl) for loading.  This checks most syntax and expressive correctness.
> b. Addition of simple self-validation test, a scene tests itself that the
> values and relationships are all valid.  This checks most accessor methods
> (getters/setters).
> c. Regression testing reporting these results for all models in X3D
> Example Archives is produced automatically as part of each build release.
>
> So we could add further autogenerated tests the mix, but we should figure
> out "what itch we are scratching" since a lot is in place already.
>
> Of note is that the Web3DUX User Experience is looking at how user
> navigation and interaction can be measured.  Theoretically each X3DOM/X_ITE
> conversion of an .x3d scene might be used with a selenium test harness to
> check scene capabilities from within an HTML page.  How such tests might
> define metrics and success criteria are open questions that might become
> very interesting as we integrate further with the Web.
>
>
> On 8/30/2020 8:44 PM, John Carlson wrote:
> >
> > Don, et al: would it be reasonable to take X3dToJava.xslt and extend it
> to produce/generate full code coverage tests for X3DJSAIL?  Would you be
> interested in such an effort? We can use X3DUOM and X3DJSAIL generation
> code as well.
> >
> > Let me know where you might see this fitting into your schedule, if at
> all.  I'd like to lay down some patterns which can be used in python, es6
> and C/C#/C++ as well.
> >
> > So we're not only validating the apps/scenes, but also validating the
> whole X3DJSAIL library including getters and removers, not just testing
> adders, setters and constructors.
> >
> > Let me know if anyone wants to join the effort.
> >
> > Thanks,
> >
> > John
>
> all the best, Don
> --
> Don Brutzman  Naval Postgraduate School, Code USW/Br
> brutzman at nps.edu
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
> X3D graphics, virtual worlds, navy robotics
> http://faculty.nps.edu/brutzman
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200831/1456e1fc/attachment.html>