C++ tests, Invalid path to the test executable

Upgraded to the latest Resharper, 2018.3 and my C++ tests are no longer working. I get a message

"Invalid path to the test executable. Please specify test run configuration via the project debugging properties..."

Has been working for the last 2 years

They are using GoogleTestAdapter 0.13.4 - what do I need to specify and where?

15 comments
Comment actions Permalink

Hello Paul,

R++ usually uses the "Command" debugging property of the test project to determine which test binary to run. Could you please check what it is set to for the project that contains the tests?

0
Comment actions Permalink

Same as your image

0
Comment actions Permalink

What does $(TargetPath) expand to? (Click "Edit" in the dropdown menu to check this.) Could you please also check that the project configuration/platform in the properties dialog are the same as you have active in the editor?

If you could send us a sample solution where this happens, that would be great. 

0
Comment actions Permalink

Had this same problem.

Checked out $(TargetPath) macro and it was expanding to a path with multiple back-slashes in it.

Turns out I had defined my Output Directory to be `$(SolutionDir)\$(ProjectName)\$(Configuration)\`. (note the slash between $(SolutionDir) and $(ProjectName)

The problem is that $(SolutionDir) already includes a back-slash, so the path was invalid.

This configuration used to work, however, so perhaps R++ no longer normalizes the path where it used to.

0
Comment actions Permalink

Hey Dan,

Redundant backslashes should not be a problem. Are you saying that after you've changed $(TargetPath) to the full path everything works?

Would be great if somebody could share a project with us where this issue happens.

0
Comment actions Permalink

Yes, once I removed the extra slash, everything worked correctly. I will try to make a demo project today.

0
Comment actions Permalink

Is there any real solution on this topic?
I encounter this problem again and again.
There are two workarounds to solve the problem temporarily:
1. Change $(TargetPath) to the full expanded path (afterwards you can change back to default $(TargetPath) and the executable is still found)
2. Run the test project once from the Visual Studio Solution Explorer, afterwards tests can be started from Unit Test Explorer

But after some time the problem returns. Unfortunately, I cannot say what actions/changes cause the problem to appear again.

Path:

Thanks for any help

0
Comment actions Permalink

We haven't been able to reproduce this so far. If you can come up with a demo solution, we'll be happy to investigate.

0
Comment actions Permalink

Hi,

 

Using 2019.2 EAP 6 I have the same issue trying to run unit tests. I am using CMake 3.15.0 to generate my project, and google test to implement unit tests, and using visual studio 2015.

I have the Debugging parameters the same as Igor Akhmetov posted above.

TargetPath resolves to D:\mylibrary\test\Debug\mytests.exe

ProjectDir resolves to D:\mylibrary\test\

Note that I did not have this problem with 2019.2 EAP 5

0
Comment actions Permalink

Hello Dennis,

Sorry about this. We've added some heuristics so that R++ can automatically deduce how to run tests in CMake projects in EAP 6, and they took precedence over the debugging parameters. This will be fixed in the final 2019.2 release.

Regardless, we'd like to investigate why the tests could not be run. If possible, could you please attach a sample solution where this happens to https://youtrack.jetbrains.com/issue/RSCPP-27282? If not, please run Visual Studio with the /ReSharper.Internal command line argument, open your solution,  then run "ReSharper | Internal | Project Model | Dump C++ IntelliSense info", attach the generated file to the same issue, and please also mention where the tests you cannot run are located.

Thanks a lot!

0
Comment actions Permalink

Hi Igor,

It is not just 1 test that doesn't run, no tests run, I get the error once for each test executable.

There is no Dump C++ IntelliSenseo info option:

0
Comment actions Permalink

Dennis,

Sorry, disregard my previous comment, I missed that you were using VS 2015 and were generating a VS solution with CMake.

Let's take a single failing test in a single project. How do "Debugging properties" for that project look like? Can you run the command that is specified there from the command line?

0
Comment actions Permalink

 

I will attach a sample project for you on the link above, it uses cmake 3:15.0, and as noted, I'm generating the vs2015 x64 solution with it.

The expanded paths of TargetPath can be copied into a console and ran without problem.

0
Comment actions Permalink

I have the same problem with Visual Studio 2013 in Windows 8.1 using catch (version 1) unit tests. They have been working via the Resharper Unit Test Window fine for over a year. This morning I upgraded to the latest Resharper version 2019.2.2 and now I get the "Invalid path to test executable." error. I cannot get any unit test to execute inside Visual Studio 2013 anymore.

"Command" under "Configuration Properties --> Debugging" is set to "$(TargetPath)" which expands to "W:\MyProject\\_Binary\Release\MyProject_UnitTests.exe". Please note the double backslash.

I get said error dialog even if I expand $(TargetPath) manually and remove the backslash. However, I can execute the unit tests fine by hitting Ctrl+F5 and running the console app manually. The exe-file is located in the directory specified by $(TargetPath), too. So why can ReSharper not find the exe-file? This is slowing down my development process significantly. :(

 

Edit:

When I download the evaluation version of Visual Studio 2019, the same project works perfectly, i.e., all unit tests can be executed as usual within the ReSharper UI. So it seems to be a problem limited to older versions of Visual Studio, in my case Visual Studio 2013.

0
Comment actions Permalink

Hello Joerg,

Sorry about that, this is a bug - https://youtrack.jetbrains.com/issue/RSCPP-27579. Please disable "ReSharper | Options | Environment | General | Read solution model directly from project/solution files" and reopen the solution as a workaround.

Thanks!

0

Please sign in to leave a comment.