CMake Instrumentation!
Image below is from default build of https://github.com/steve-downey/optional/tree/cmakeinstrument .
It spends all its time building gtest. :sad:
CMake Instrumentation!
Image below is from default build of https://github.com/steve-downey/optional/tree/cmakeinstrument .
It spends all its time building gtest. :sad:
@Sdowney GoogleTest is one of the worst legacy C++ design. I hate it and won't use it. however, the brand makes it too attractive for the uninitiated.
I also hate some of its features that allow you to write large tests (EXPECT instead of REQUIRE), where in my unit testing philosophy a test function should have a single reason to fail and be named like that.
There are *no* units. Is the metric the number of stumbles along the way?
Instead of Google test I recommend Viktor Kirilov's 'doctest'
"stumbles" is a fairly accurate description of when a new TU was created.
The metric in the chart is number of TU and how long each takes. There are really only 2 units and some integration between them. As well as just some pure examples.
The split into TU is not particularly sound, here, and mostly either parallelism between T and T&, or lexical feature classification.
I'll look at doctest again.
I do have the minor, self-imposed, but nonetheless important, requirement that the headers look sufficiently like std synopsis to render into standardese.
Lest I make mistakes doing so, as I am a bear of very little brain.
I'm also of the opinion that "unit" is a poor term for the critical property of "repeatably testable quickly".