Reputation:
I have about a hundred of simple tests done with boost unit test library. Not only I get very long compile times (in order of half a minute), but the size of the resulting executable gets really big - 4MB for just a hundred simple tests. If the tests are done without using boost test, the executable size is a mere 120kB.
How can I lessen the bloat? This question is just because of interest, not that I need test code to have shiny performance :)
The debugging info is already stripped. I've tried all optimization options with no success.
EDIT:
Each test is basically as follows:
PlainOldDataObject a, b;
a = { ... initial_data ... };
a = some_simple_operation(a);
b = { ... expected_result ... };
BOOST_CHECK(std::memcmp(&a, &b, sizeof(PlainOldDataObject)) == 0);
Upvotes: 1
Views: 555
Reputation: 37
Try using Loki library instead: it also has many common-used generic components (including a static assertion macro, similar to BOOST_CHECK).
Loki is known to be lightweight, but even more powerful than boost is, because it uses a policy-based approach to class design. However, it doesn't have all that variety of tools, only most common ones: smart pointers, small object allocator, meta-programming helpers, factories and a few others. But if you don't need any of those monstrous boost libs like serialization for ex, you may find it satisfying for your needs.
Upvotes: 0
Reputation: 1945
I. Which usage variant do you employ? If you employ single header variant of unit test framework, you should switch to offline variant (either static or dynamic)
II. If you suspect that BOOST_AUTO_TEST_CASE macro is at fault, you have several options:
Give up single assertion per test case policy and use number of "themed" test cases. I personally find this acceptable.
Use manual test case registration. You can probably automate it with your own macro to avoid tedious repetition.
Split into multiple test files. You might see at least some compilation time improvement (or might not).
III. If you suspect BOOST_CHECK statements, there is not much you can do, but I'd be rather surprised to see this much overhead from them. Maybe you should investigate further.
Upvotes: 3