I tried 8efadd1 and it didn’t exhibit the problem. I suspect the issue comes from some of the plugin client reorganization stuff after this commit (cc @reuk).
Thanks, I see what’s going wrong. We’re currently trying to determine the cleanest solution, but should have something out shortly.
Tangentially-related: when I build your project locally with ClangCL, I get quite a lot of duplicate symbol warnings (ODR violations) when linking the test target. I think the problem is that the JUCE_DEPENDENCIES are linked separately to the plugin target and the test target. JUCE modules are interface targets, which means that they are built separately for each non-interface target that links against them. In turn, this means that the test binary contains two copied of the JUCE modules; one from the plugin shared-code target, and one linked directly to the test target.
To avoid the ODR violations, you could consider only linking JUCE_DEPENDENCIES to the shared-code target, then re-exporting the shared-code target’s preprocessor definitions and include directories. That way, when you add the shared-code target as a dependency of the test target, the test target will still inherit all of the JUCE flags and include directories.