How to use Google Test with JUCE projects?

Can anyone give me some help using Google Test in my JUCE project? I’m on Windows using Visual Studio 2019. I can’t really tell what I’ll need to do in Projucer. Surely someone’s using gtest in their JUCE project?

1 Like

Are you doing audio plugins?
In this case I would suggest to take a look at this patch for the Projucer. We added a GoogleTestConsoleApp build target that oyu can enable just like any other plugin format.

If you’re doing standalone apps: I guess the most simple way would be to use a separate Projucer project.

I’m planning a plugin. I’ll take a look at this thanks!

You might have an easier time using CMake instead of the projucer if you are using JUCE 6. Much easier to handle multiple targets.

2 Likes

Yes, absolutely!

We did this modification to JUCE5 because we had our whole CI system already setup around the Projucer workflow. At the time we did this, a CMake workflow was already available but switching to CMake would have meant a huge change to everything so we decided against it.

You might have an easier time using CMake instead of the projucer if you are using JUCE 6. Much easier to handle multiple targets.

I have a CMake project that uses gtest. It’s divided into a number of targets, and I just added JUCE to make a standalone app. I’d like to test this new integration code with gtest, but I’m having trouble figuring out how to get it set up properly. For non-JUCE code, I would typically make a library out of the code I want to test, and then have two executables defined (one for gtest and one that actually builds the app). Have you made that work with JUCE before?

You would keep the code under test in its own juce module (a juce module gets built as a library) and then you can link your tests executable to that. Seee this post

Hi
Sorry to open this old post, but I’m struggling to understand best practice here.

You would keep the code under test in its own juce module (a juce module gets built as a library) and then you can link your tests executable to that. Seee

Given that I have a target for an app (juce_add_gui_app) and want to run tests on some of the code.

  • Does the above mean that I should create a Juce Module for all of the the main app code?
  • Or does it mean that the test files, (like mytest.cc, etc) should be a juce module?
  • Also from the links, I don’t understand what JUCE_UNIT_TESTS has to do with all of this.

I would be very grateful if anyone has a clear guide on how to make a cmake file with all the juce extras and then add gtests to test the same code.

I’m not sure there are many best practices but I’ll try to answer some questions.

JUCE_UNIT_TESTS is only relevant if you want to use JUCE’s unit test runner. For example on usage, see the demo or pluginval (a standalone app which optionally runs the tests when a flag is passed)

However, that’s not relevant if you know you will be using Google Test or Catch2 — in this case you will build and run a different target executable for the tests, it won’t care about JUCE_UNIT_TESTS, etc…

You could look at how I’m doing Catch2 tests with CMake here. I have a separate test target that depends on the shared plugin target. For plugins, things get a bit messy, as the test target will need access to the shared plugin target’s code/dependencies (see here for details).

For standalone apps (which it sounds like you are talking about?) I don’t have any direct experience but it does sound easiest to bundle shared functionality you want to test into a juce module and have tests inside a .cpp file guarded by a HEY_RUN_MY_TESTS define, like I have in one of my modules here. Then both your app and the test target can consume this module, the test target definining HEY_RUN_MY_TESTS.