Test discovery fails randomly (when using solution settings file (?)) about googletestadapter HOT 3 CLOSED

Sorry, just saw this... thanks for the great bug report!

From what I can see, your conclusions appear to be correct. Since you seem to be able to run GTA from source: Might it be an idea to add a "retry functionality" to the point where the DTE is received? I'm thinking about retrying for a couple of times (and e.g. once every second) in the hope that the DTE becomes available in time...

For what it's worth, a workaround might be to set the env variable as mentioned in the log output. This had been introduced because of a different (and now fixed) VS regression - the DTE is used to figure out the location of the solution settings file if I remember correctly, and by setting that variable you tell GTA where to find that file without reyling on the DTE object. I'm aware that this is not nice at all, but maybe better then having to live with the occasional problem.

from googletestadapter.

Thank you for your reply.

I've implemented the suggested retry mechanism (actually more like a brute-force while loop), which solves this particular error (so does the fallback file specified via the environment variable btw.).
Unfortunately my overall goal was to get the test adapter running with 3rd party dependencies not present in the test targets $(OutDir) via placeholders in the PathExtension setting, as proposed in #170.
There seem to be several places where the information which platform and configuration is selected does not get updated or populated in the first place properly. Two cases could be identified:

• Switching between Debug and Release configuration (no update of the settings seems to get triggered), platformName and configurationName in the settings will keep the previously set value.
• Starting up VS without opening a project and waiting several seconds (waiting for GetVisualStudioConfiguration() in GoogleTestExtensionOptionsPage being called, which will not enter the if (dte.Solution.Projects.Count > 0) branch and thus not populate the platformName and configurationName fields).

As the PATH variable does not get updated properly in these cases, loading the correct 3rd party dependencies fails and the test runners cannot be queried by the test adapter.

I gave up and will stick with the good ol' copy-all-the-dlls-to-the-output-directory method.

from googletestadapter.

Ok, thank for letting me know... I don't think that I have any influence on when platformName etc. are updated by VS - I just take what I get from the VS platform :-)

Closing this now - feel free to reopen...

from googletestadapter.