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 …or else it gets the hose again
@Sdowney fused gtest is kinda slow to build, I ended up building it with optimizations disabled since it didn’t affect test performance much
@vitaut
I'm split between working on its build time and just switching to something lighter weight.
I really had no idea it was dominating the build time that way. Builds tend to show when things start, not when they end.

@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.

#UnitTesting #TDD

@Sdowney

There are *no* units. Is the metric the number of stumbles along the way?

Instead of Google test I recommend Viktor Kirilov's 'doctest'

https://github.com/doctest/doctest

GitHub - doctest/doctest: The fastest feature-rich C++11/14/17/20/23 single-header testing framework

The fastest feature-rich C++11/14/17/20/23 single-header testing framework - doctest/doctest

GitHub

@DanielaKEngert

"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".

@DanielaKEngert