Funny you’d ask. It was the fact that I kept running into your composites that I started searching for testing methods. That, and let’s be honest here, I’m quite fed up with running into my own numerous bugs, often without a clue where to start.
In an old thread, you asked for a way to link to Rack for testing purposes (before v2). @Vortico responded: “…you want to link to Rack with your own executable with its own entry point (main()) but not call Racks functions.”
This triggered the thought to use Rack’s own entry point. The upshot is that all of the Rack API is available and running. The tests run after the scene is loaded, so maybe you could even grab a fully patched module instance and use that for testing.
To answer your question: It’s not gtest, it’s Catch2
I picked Catch2 over gtest (and others) for several reasons.
One of them is the fact that it is already used by devs like @Baconpaul, @qno, @valley.audio to name a few.
Some people over at JUCE use Catch2. Here’s an example of a a sexy custom Matcher for audio blocks:
REQUIRE_THAT(myAudioBlock, isEqualTo (someOtherBlock))
with expansion:
Block is 1 channel, 480 samples, min -0.766242, max 0.289615, 100% filled
[0—⎻—x—⎼⎽_⎽⎼—]
is equal to
Block is 1 channel, 480 samples, min -1, max 1, 100% filled
[0—⎻⎺‾⎺⎻—x—⎼⎽_⎽⎼—]
That and some other reasons (learning curve, features, little boilerplate, GENERATORS()) made me pick Catch2.
I’m at the beginning of learning TDD, BDD, Unit testing, and its idiosyncrasies. But I figured if I shared this hack, perhaps others adopt/improve it and implement tests in their plugins I could learn from.
WARNING: These green lines yelling “All tests passed” at you, with ever-growing numbers, can become addictive to our monkey brains. Get out while you still can.