Closed Wallacoloo closed 9 years ago
Another thing to consider is that this may eventually run on embedded devices with small program space / ram. There's a discussion on this here. CATCH currently uses at least 100kb+ of program space, whereas lest is targeted to be more lightweight.
lest doesn't appear to be suitable for use across multiple source files though, since it appears to lack automatic test registration.
The devel branch now features CATCH test integration that is run by Travis CI after every push, although no tests have yet been written xD
This project needs some sort of automated testing. Currently, the only thing tested is that all the machines will compile under various compiler versions/modes.
So I'm thinking of some sort of unit test framework. This StackOverflow post suggests the CATCH framework and another few suggest lest.
Both are contained in a single header. lest appears to be CATCH altered for c++11 use.
Catch appears to me a very natural way to do things, and is almost self-documenting using constructs such as
It's not immediately clear to me how it works across multiple files. It's important that the test suite doesn't add bloat to non-test builds. At the same time, is it important to be able to define tests inline with the source? Printipi uses a lot of templates (source in header). This blog post puts their tests in separate .cpp files, and even in a different directory, although this blog puts the tests in the same source file.
Besides unit testing, another option is to place many assertions in the normal (debug targeted) code and test the binary by throwing gcodes at it. While this approach can test the system as a whole, it doesn't test the logic of each part individually, especially local edge-cases. On the other hand, it might provide more realistic input.