On Mac OS, latest JUCE develop branch, I tried the Unit Tests from CMake, and needed something like the following change to proceed:
diff --git a/modules/juce_audio_formats/codecs/juce_WavAudioFormat.cpp b/modules/juce_audio_formats/codecs/juce_WavAudioFormat.cpp
index 20f0f4925..93f20bda6 100644
--- a/modules/juce_audio_formats/codecs/juce_WavAudioFormat.cpp
+++ b/modules/juce_audio_formats/codecs/juce_WavAudioFormat.cpp
@@ -1148,7 +1148,9 @@ namespace WavFileHelpers
// 'source' field in the INFO chunk, set the
// WavAudioFormat::internationalStandardRecordingCode metadata field to the
// empty string to silence this assertion.
- jassert (ISRC.length() == 12);
+ if (ISRC.length() != 12) {
+ std::cerr << "*** juce_WaveAudioFormat.cpp: ISRC not set\n";
+ }
xml << "<ebucore:ebuCoreMain xmlns:dc=\" http://purl.org/dc/elements/1.1/\" "
"xmlns:ebucore=\"urn:ebu:metadata-schema:ebuCore_2012\">"
We regularly build the JUCE UnitTestRunner with CMake as part of our automated checks. We haven’t seen any issues in this area, so the problem is likely due to some quirk of your setup. To diagnose, it would be helpful to know the following:
What’s the full text of the error message produced?
Have you made any custom changes to the JUCE source, or are you building from the plain develop branch?
Did you need to change all instances of jassert in the codebase, or just the one in WaveAudioFormat.cpp?
How are you building the project? (Full CMake invocation, build command, OS version, compiler version)
Edit: Because you mentioned CMake, I’d assumed this was a build-time failure, but is it actually a run-time failure? If so, you can keep going after an assertion by hitting “continue” in your debugger. If you’re not running in a debugger, the program should continue automatically.
Thanks for your reply! I should have assumed you do CI on all platforms and would catch something like this automatically right away. So, something indeed must be strange in my world (wouldn’t be the first time…). I do have some minor edits in my branch from develop, so I switched back to an unmodified develop branch and it still happens. Here is what I see from UnitTestRunner:
...
-----------------------------------------------------------------
Starting tests in: Wave audio format tests / Setting up metadata...
Completed tests in Wave audio format tests / Setting up metadata
-----------------------------------------------------------------
Starting tests in: Wave audio format tests / Metadata can be written and read...
JUCE Assertion failure in juce_WavAudioFormat.cpp:1151
Completed tests in Wave audio format tests / Metadata can be written and read
-----------------------------------------------------------------
...
I use both Xcode and CMake, and the error is at runtime in UnitTestRunner.
I only made that one jassert change (although in my branch I had also allowed param->getVersionHint() to be 0).
Yes, continuation in Xcode works fine, and UnitTestRunner continues as if nothing is wrong.
I’m not even working with .wav files. - I just thought it might be helpful to relay the observation.
That’s exactly what we do, but we don’t guarantee that our unit tests are assertion-free. If you run the tests from additional JUCE modules under a debugger you’ll see other assertions firing when we deliberately do things like request strange bus layouts to simulate odd hosts and plug-ins.