Unit Test Sessions window Catch C++ tests inconclusive

Hi

The Unit Test Sessions window is reporting all the tests as inconclusive even though when the catch test program is run on the command line, all tests pass.

If I reduce the tests to one test, with REQUIRE( 1 == 1), it works. But if I add the original tests that calls other functions, it reports inconclusive.

I added code in the tests to report the working directory. It is the same directory I am running the tests 

The logs report:

2018.08.31 08:53:11.169 INFO Run: 72c52591-4f9c-4afa-b740-09b58959a927 - Starting
2018.08.31 08:53:11.169 VERBOSE Provider: Catch
Target Framework: .NETFramework,Version=v4.0
Strategy: CatchRunStrategy
Runtime Enviroment: CppRuntimeEnvironment
Project: rpe_compare_with_fortran
Architecture: X86
2018.08.31 08:53:11.202 ERROR Child process exited with exit code "DLL not found"
2018.08.31 08:53:11.202 INFO Run: 72c52591-4f9c-4afa-b740-09b58959a927 - Finished

I have no idea what DLL is not found.

Microsoft Visual Studio Professional 2017 (15.7.3)

ReSharper Ultimate 2018.2

Intel Fortran XE 2018 Update 1 Composer Edition.

Catch version 2.2.2

Thanks

Tim

 

 

 

3 comments

Hello!

If you run the unit test binary from command-line (not from Visual Studio), which DLL will it complain about? Are you using any third-party libraries in your tests, maybe something from Intel?

0

Hi Igor

Thanks for the response. If I run it on the command line, the tests run fine. They don't run in the Unit Test Sessions window. I wonder if it is an shell environment issue. How is the Unit Test Sessions window running the tests? How is the shell configured? I looked everywhere and I can't find any info on this. 

Regards

Tim

0

There's some info about that at https://www.jetbrains.com/help/resharper/Unit_Testing_in_CPP.html. In a nutshell, R++ uses "Command", "Working Directory", "Environment", and "Merge Environment" properties from debugging project properties. All the DLLs that the unit test binary is linked with should be either in the same directory as the binary, or in one of the PATH components.

We've seen some problems when running tests that use Intel libraries - please see https://youtrack.jetbrains.com/issue/RSCPP-14889#focus=streamItem-27-1435352-0-0 for a possible solution. 

0

Please sign in to leave a comment.