After some more evaluation (and distraction by other work) we finally decided to go with the modded Projucer instead of a cmake solution. For anyone interested, here is a patch that can be applied to JUCE 5.4.3, with the following changes:
JUCE_543_AudioPlugin_GoogleTestTarget.zip (917.6 KB)
- Added
GoogleTestConsoleAppas a new plugin format in the projucer - Added googletest sources to the
juce_audio_plugin_clientmodule - adjusted XCode and Visual Studio exporters to
- assign all files with a basename ending on
_gtestto theGoogleTestConsoleApptarget and exclude them from the other targets - link the
SharedCodetarget to theGoogleTestConsoleApptarget so that a full plugin can be instantiated as part of the tests - define the
JUCE_CURRENT_TARGET_IS_GTEST_CONSOLE_APPpreprocessor macro in the corresponding build target
- assign all files with a basename ending on
Now the workflow is like this:
- Create an audio plugin project with the modded projucer
- Set the checkmark for the
GoogleTestConsoleApptarget - Add your test source code as
cppfiles to any folder in the project, but use this naming scheme:<mytestfile>_gtest.cpp. Those files will only be built as part of theGoogleTestConsoleApptarget and will be excluded from the other build targets (this follows the convention for the other special targets like VST, AU, etc where the file ending also determines to which target the file will be added). The google test headers will be included with the juce header when this target is built. - save the project and open it in XCode or Visual Studio
- you will find that there is now a new build target that builds a console app. This app will run all tests that were found in your
*_gtest.cppsourcecode files. Under Visual Studio, they will also appear in the test explorer panel so you can run tests individually.
I’m open to feedback on this. It would be great if something like this could be part of JUCE natively. It would certainly lower the setup hassles and make it easier to develop test driven plugins with JUCE.