Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Run integration tests for deployment builds #303

kintel opened this Issue Mar 11, 2013 · 5 comments


None yet
3 participants

kintel commented Mar 11, 2013

Now that the test frameworks supports using the actual OpenSCAD binary, we should have a way of running al such tests using the actual deployment build of OpenSCAD as part of the (snapshot) release procedure.

This should be easy enough to script.

As a start, I'm renaming all such tests to start with the string "openscad".

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.


chrysn commented Mar 10, 2014

currently, most tests use openscad_nogui.

for this to work, all special-casing where the _nogui version behaves differently in order to accomodate the test suite will have to be removed. afaik, that mainly affects how numbers are exported. (normalization for NaN, -0, rounding).

path handling might also be affected; the test script (and not the openscad binary) should handle that, and if required set OPENSCADPATH appropriately.


donbright commented Mar 11, 2014

i agree... and you are correct, some file i/o and command line parsing is affected, mainly due to encoding issues that QT handles automatically, which boost cannot.


chrysn commented Mar 11, 2014

i did not notice differences wrt file handling any more, only numerics
and timestamps.

as the test comparison is already done in a python script, i hooked in
there and added a patch to fuzz over the numbers before comparing.

in detail: all ", timestamp = ..." is stripped, and everything that
looks like a number is converted to a float, printed as "0" if abs <
10e-5, otherwise printed via "%.4g" (ie to four digits).

this allows both openscad and openscad_nogui to be used for the test
cases; only new regression comes from concat being enable or disabled
depending on the build system.

if my patch[1](or patches; i replaced the diff output with something
more html and python-builtin) gets accepted, the specialcasing for
numbers in _nogui can cease, and the precision requirements of the test
can be yanked up to a reasonable value (i'd say 8 digits).

one thing to be considered at that stage will be how much precision to
output when (how much precision in echo, how much in which export
format). my personal opinion is that unless explicitly requested by
rounding or printf (if such a feature exists in openscad), a number
should be represented fully (ie as many digits as required for precise
float representation). python contains an algorithm that finds the
shortest decimal that yields the desired float, that could be copied for
things like echo(0.1) not to behave unexpectedly.

[1] https://gitorious.org/openscad-debian/openscad/source/bb254a4a0d48ca968528a29f5af2443747ab4b8d:


donbright commented Mar 13, 2014

the path stuff shows up on Windows where filenames are UTF16 and handled differently for QT gui vs boost.

do you know the name of the python algorithm? sounds very interesting.


chrysn commented Mar 13, 2014

i don't know what python uses exactly for an algorithm, but it's all
in the docs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment