This really belongs in github pull request discussion, so I'll copy my response there.
It also makes sense to continue the discussion there, so that it's easier to find it later.
On 2013-06-26, at 10:14 , chrysn wrote:
> * csgtexttest -- what does that actually do, why is it there, and what
> does it do that csgtermtest together with dumptest can not verify?
The idea of this test is to validate the lower levels of the toolchain, before CSG terms are being evaluated, by writing a simple tree traversal which just outputs strings instead of building object trees. It also serves as a test of the visitor pattern infrastructure.
It was instrumental during earlier development, but it might be covered by the csgtermtest by now.
Instead of removing/porting it, perhaps we could put it into an optional group of tests for now?
See set_test_config() in CMakeLists.txt - not sure how easy that is to adapt though.
> * throwntogethertest -- i'd be glad if whoever did the original png
> exporting thing could add a flag --throwntogether (like --render)
> that provides the export function
That should be doable. It should become a github issue so we don't forget it.
> * cgalstlsanitytest -- is this really all about no NaN showing up? if
> so, a) why don't we just do a regression test on the stl file, and
> if that's because the stl export is volatile, b) would it be
> sufficient to export it to a stl file and verify using grep whether
> or not a NaN occurs?
This was the easiest hack to avoid building more complex stuff in cmake to plug that one hole.
We could move the nan check to a separate script.
I think the original idea was to avoid use of unix tools in the test framework, to make it easier to use on Windows, but I guess we've strayed pretty far away from being useful on a non-cygwin Windows environment by now..
> * modulecachetest and cgalcachetest are built by CMakeList.txt but not
> used -- is that a thing at all, what does it do and can what it does
> be reasonably output by openscad?
I didn't finish that - the idea is to test internal APIs for cache management. As such, it's really a unit test, not a regression test.
..which brings us to the discussion about test drivers in general: Unit tests are not expected to be part of the OpenSCAD binary, so whenever we start introducing these, we still need to build custom binaries, so it might not be feasible to remove all test drivers. However, the work done thus far has greatly reduced code duplication!