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.