search

stulp / dmpbbo

Python/C++ library for Dynamical Movement Primitives and Black-Box Optimization
GNU Lesser General Public License v2.1
224 stars 90 forks source link

core dump for functionapproximator/tests/testTrainingCompareCppPython #39

Closed stulp closed 5 years ago

stulp commented 5 years ago

(splitting #31 into several separate issues)

stulp commented 5 years ago

To be honest, the tests are not really unit tests, but rather programs I wrote for myself to test functionality of the code. As mentioned in the documentation, they are not really documented or supported.

I considered putting them in a separate branch "tests", only to be used by developers rather than users. But this was rather inconvenient in practice.

Any preferences from the user side? 1) Tests included in master branch, with the policy "look but don't touch" 2) Tests included in a separate branch, so that no one is tempted to "look and touch"

(assigned to @graiola to get feedback)

jenskober commented 5 years ago

For me both options are fine. I overlooked the note on the tests in the documentation. If you go for option 1., I'd also add that in the INSTALL.txt for the debug build (or even make that a separate compile flag)

graiola commented 5 years ago

@stulp Does it make sense to compile them only when a TEST variable is defined in the cmake? We could run them with travis afterwards. If you like the idea, I could work on that.

stulp commented 5 years ago

@graiola One one hand I like the idea and flexibility it gives. On the other hand, if someone is compiling in DEBUG mode (tests are only compiled in DEBUG mode), they are probably an advanced user anyway, right? So an alternative might be to not make the DEBUG mode so obvious in the INSTALL file, i.e. move it to the bottom. At that point, it would basically say that this mode is for developers only, that the tests are not supported, use at your own risk, etc.