Catch2 matchers for JUCE's AudioBlock

I extracted some Catch2 matchers and helpers that I’ve been using with JUCE’s AudioBlock into a module in case it’s useful for anyone else:

5 Likes

I’m about to add this to our in-house unit test helper codebase. Great work! But: Your repository has no license specified, would you mind adding one? Something permissive would be great of course, but I also understand if you prefer something like GPL

1 Like

Very nice. One more reason to get involved with Catch2 :+1:

1 Like

Also, would you mind documenting which catch version your work is based on? Seems like the catch_matchers_templated.hpp is only available on the current catch devel branch but not in the latest release, right?

Thanks for catching this. Both this and the sparklines module (which this depends on) are MIT and I updated their repos. If you get things running, let me know if you find the dependency on the sparklines module useful or annoying… I found it really useful to know what’s in an AudioBlock on failure, so I didn’t make it optional to start…

Ah right…the code was version agnostic until I recently added the matchers. Actually, I think the matchers themselves are also version agnostic but the includes are for v3. I could add a flag for v2 if useful? For context, I’ve been happy on v3 for a year. It seemed common for people to start new projects on that vs. the v2 April 2020 build.

I see. We are still on single header catch 2 – maybe we should update that. For now I decided to create our own set of matchers but using your sparklines module for test output. I fixed a tiny integer conversion build warning and fixed a little flaw (the min/max values reported by summaryOf only check the first channel) – I’d raise a GitHub pull request with those changes if you like :slight_smile:

Ah cool, glad the sparklines are handy.

I’d love and appreciate any PR!

What do you think about modifying the description output from

Block is 1 channel, 441 samples, min -0.999994, max 0.999994, 100% filled
[0⎺‾⎺x⎽_⎽]

to e.g.

AudioBlock<const float> (1 channel, 441 samples, min -0.999994, max 0.999994, 100% filled) with content
[0⎺‾⎺x⎽_⎽]

? I personally like how that reads a bit more like the typename that one actually uses in the code.

Thanks for the PR! I responded to the summary change idea over on github (hopefully that’s ok!).