Add unit tests for all serializers & deserializers

[kaosat-dev]

We currently have NO unit tests for any of the sub packages in this repo
We need:

• the boilerplate for unit testing & CI (travis) needs to be in place for all serializers & deserializers (working on it)
• we need minimalistic input files for the deserializers: we want to avoid repository bloat AT ALL COSTS (been there, it is not an easy fix after that)
• we also need to keep in my that we will be changing the output format of the deserializers from jscad code to objects (CAG/CSG or other)

List of things to do/ done :

• amf-deserializer
• amf-serializer
• dxf-serializer
• dxf-deserializer
• gcode-deserializer
• json-deserializer
• json-serializer
• obj-deserializer
• stl-deserializer
• stl-serializer
• svg-deserializer
• svg-serializer
• x3d-serializer
• io-utils

[z3dev]

I f I remember correctly then most samples came form other repos or websites. Not sure that helps or not but we might want to download samples rather then store them.

[z3dev]

For pure meshes, direct conversion to CSG/CAG makes sense.

But there are formats which describe shapes, e.g. lines, circles, arc, etc. By supporting source code then those objects can be used as such.

I really don't want to favor one or the other, because there's value to both. The users of the applications should decide.

[kaosat-dev]

• downloading samples on the fly from other websites is neither reliable nor efficient for testing, thought I get what you are saying. Even if it is more work I tend to favor manually crafted files created for the specific purpose, or alternativelly 'maxmimal' sample files which contain ALL different variations in a single file, even if that makes testing harder.

• supporting multiple outputs from a tool adds a lot of work, mostly as , for example even for svg , we cannot have 1 to 1 match , but I guess we can keep the current source output available somehow.

Hmm perhaps they (the svg/dxg etc to source code versions) represent some completely different use cases and should be optional tools, as they somewhat like that the openscad-openjscad translator (ie : can be useful, but should not always be bundled ?)

[z3dev]

That's an interesting idea. Source code generation is another library, but not really core. Hmm... I'll think about it.

[drom]

@kaosat-dev @z3dev Thank you for the wonderful tool.
I am new to 3D but probably can help with JS testing.
Do you have test plan in order or priority?
Do you plan to run these tests under code coverage tool (nyc)?

[kaosat-dev]

Thanks @drom ! that would be great !
we did experiment with nyc for the CSG part and it would make sense to do this here as well , good call !

On top of my head as far as priority goes:

• stl-serializer (so we have tests for CSG => STL and STL => CSG)
• svg-serializer (same)
• dxf-serializer (same)
• obj-deserializer
  the others I am not sure about to be honest

What do you think @z3dev ?

[z3dev]

Yes. That's about right.

STL needs some extensive testing as that format is by far the most popular. This should be easy to test.

It would be great to get some tests around OBJ formats. Does anyone have access to the application?

[kaosat-dev]

I am adding tests for stl deserializer as part of the import as CSG option.
I have sample files for:

• obj
• 3mf
  I will add them to the samples repository

[drom]

@kaosat-dev I am looking into svg-serializer code and testing I see only initial implementation.
Do you mind if I will improve the code itself while doing tests?
For the testing strategy, I thinking to implement reverse operations to the svg-deserializer
Do you mind if I use my library https://github.com/drom/onml to construct SVG ?
Alternatively we can use React server to do so.

[z3dev]

Sure. Please try.

The tests just need to,run across platforms and versions, otherwise we will probably accept anything. :)

[drom]

@z3dev
...across platforms. I see travis-ci running only node 6 and 8 on Linux.
Do you test on MAC, Windows?
Node 4,5,..7?

[z3dev]

I work with MACOS but sometimes run on Linux.

The discussion about going backwards with NOEDEJS was already held. There's really no point as project dependencies demand higher versions, I.e 5,6,7

And I don't want to spend time and energy supporting old standards, etc..
Let's move forward. There's already a large set of browsers and OS to test.

[kaosat-dev]

Node 4 has just been deprecated, and does not support most es6 features.
Only 6 + is acceptable : and as z3dev said we need to focus on less and on the future ;-)

[kaosat-dev]

btw @drom I am not sure I understand what you mean by

to construct SVG ?

Do you mean creates SVGs to compare with ?

[drom]

@kaosat-dev right now in svg-serializer you construct output SVG as string, by concatenating smaller strings. As code grows it will be harder and harder to maintain string concatenation approach.
Here are three possible improvements I see from here:

1. use xmldom like you do in x3d-serializer
2. construct JSONML http://www.jsonml.org/ like object and then serialize it into string. I have simple library that would work: https://github.com/drom/onml
3. use React to construct component structure and then use https://reactjs.org/docs/react-dom-server.html to renderToString()

[kaosat-dev]

ok, in that case, please open a seperate issue , as that has nothing to do with unit testing, but a totally different implentation :) (please just copy & paste your code above to keep it simple)

[z3dev]

Done as part of V2.