-
-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extension fails to capture some of the executables #213
Comments
Hello, And what is the output in case of calling the exec with |
The log actually contains it but you cut it. |
Hello matepek. The output is the following:
The full output of the error line is the following:
(apologies for removing it, it was my mistake) I have also noticed a new error, after restarting visual code:
This shows up several times in the logs. |
This line should match: https://github.com/matepek/vscode-catch2-test-adapter/blob/master/src/RunnableFactory.ts#L71 Is that your stdout or stderr? |
The regex seems to match, at least in regex101. I copied the full output there and it matched on the expected line. Yeah, it's going to stdout, I just confirmed stderr is empty. |
I guess the new error is unrelated but thanks for it. I will improve that part. Honestly I run out of ideas currently. If thats stdout and parseable than it should work.. Further investigation requires more time. Let me know if you really wanna fix this issue and we can talk about it but first.. Before I suggest to try the following workaround: Keep me posted. |
Yes, I'd really love to fix it :) Unfortunately I can't just send you the executables since I don't own them but I could try to debug it. I've added First, the configuration file is now like this:
And the logs:
|
Now it is recognised but the output is still empty. Try adjusting and executing this:
|
Yes, I am familiar with nodejs. I will try that and get back at you |
Interesting... I ran that with my UT executable and the stdout is indeed empty! That's quite strange. I tried with one of my UTs that are captured and the stdout contains the expected output. stderr is also empty (in both cases). When I execute it on the terminal I can redirect the output to a file with > though... I believe (I could be wrong) that should only work with stdout, so I'm not sure what's happening here. |
I think it's not that your nodejs is wrong, since vscode uses its own engine. I suspect some system related issue. |
I believe I have found the issue. So, in our dev environment we have a batch script we run that sets up a bunch of paths and environment variables to find all the needed dependencies and dlls. We have to run this before compiling and executing most of our execs. It turns out that most of the UTs execs fail due to missing dlls without this. All the UTs your extension is able to capture do not need this batch script to be run first. This is very likely the issue. The only way for me to get this to work would be if I could set a custom cmdline command to be run before running the execs. Is this something that would be hard to implement? Another solution would be to run the search with the env variables that are set in the advancedExecutables already set |
Easiest: Star vscode from your dev environment. In this way it will inherit all the environment variables. Use wrapper: example [here] Set up environment variables manually in the (And you don't need the |
I decided adding a new feature under |
Also check this issue: #116 |
Thanks, I'll give it a shot and get back to you on those :) |
So when I start code from my dev environment the look-up for tests seems to get stuck in an infinite loop as it never finds anything but the "loading arrow" keeps spinning forever 🤔 I had the variables set in |
Yes, Something else should be the problem. |
I think I need to do some debugging to get to the bottom of this issue. What is the easiest way to attach a debugger to an extension in code? I've never developed one, so I'm unfamiliar with the process. I'm assuming I have to clone the repo and install a dev version? |
Easier. Also I can give you a hand with vscode remote. You can share a debugging session with me online. |
Awesome! That'd be great. I'll keep you posted. I'm quite busy these next days so I might only have time next week. |
Hey, I finally have some time to debug this issue. I've followed your steps but all my break points become "unbound" when I open my folder so I guess I am missing something. Even setting one on When I launch the "manual cpp" I get the following error: I also ran
In the |
So you are committed to solve this. 👍 |
Yessir! :P |
Ping ^^ |
@Sol1du2 @matepek Has this been resolved? I have a very similar observation. I have two test executables. One is being discovered, the other is found, but the log says
Then the log stops. Another test executable has been discovered and the tests show in the test explorer. Platform is Windows 10 x64 |
@daniel-kun this issue turned out to be an issue with my setup not the plugin |
@Sol1du2 Thanks for the reply! I found out that the "C++ TestMate Legacy" extension works just fine for me. |
Checklist
Describe the bug
I am trying to use this extension with GTest.
The extension seems to fail to capture most of my unittest executables, although the pattern seems to be ok. The log file shows it going through all of the right executables but it is only able to capture a couple. Here is the error message I get for the ones not captured:
[2020-07-23 12:13:02.828] [DEBUG] Not a test executable: c:\local\hulloncos\sources\unittest\cos_unittest\cos_unittest.exe reason: [Error: Not a supported test executable: c:\local\hulloncos\sources\unittest\cos_unittest\cos_unittest.exe
I can confirm the executable works fine and running
cos_unittest.exe --gtest_list_tests
shows a list of all tests. I can't really see the difference between this executable and one that the extension is able to capture. I wonder what is the procedure to capture a "supported test executable"? Maybe that could help me find what I need to do.To Reproduce
Nothing special, just hitting the reload button in the test tab. Here are my settings:
All unittest executables have the suffix _unittest and are inside sources/unittest (yes I realize that's a silly place to put executables, not a decision that's up to me 😛)
Desktop
Log (optional but recommended)
The relevant log message I can see is this one:
[2020-07-23 12:13:02.828] [DEBUG] Not a test executable: c:\local\hulloncos\sources\unittest\cos_unittest\cos_unittest.exe reason: [Error: Not a supported test executable: c:\local\hulloncos\sources\unittest\cos_unittest\cos_unittest.exe
Let me know if more is needed though.
The text was updated successfully, but these errors were encountered: