-
Notifications
You must be signed in to change notification settings - Fork 8
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
Wildcard support sporatic #55
Comments
Oh boy, I indeed changed the behaviour how single test files are handled. Because another user had the problem that a single file was not recognized. |
Sorry for the delayed response, The wildcard char '*' is not recognized for cpputestTestAdapter.testExecutable setting with one path (file in my case). The wildcard works for cpputestTestAdapter.testExecutable setting with multiple paths (files) separated by a semicolon. I am using the wildcard for the .exe extension on Windows. Preferred behavior would be not to use a wildcard at all, have the extension look for .exe files if running on Windows. IDK if that is possibles, as I am not familiar with TypeScript. I observed the exact same behavior on both Windows 10 and WSL2 latest Ubuntu distro (I believe the defaut config for WSL2). Thank you for the timely response and looking into this issue for me. |
Hi! Just popping up this issue because i have the same problem with wildcard. I was just configuring new workspace for my team and copy pasted my setting from another project. My approach was a multiple test suites executables stored in single directory and now:
causes the test explorer to not resolving my wildcard "*" Our projects use to have a lot of rest runners so it will be ultra handy if we wouldn't have to add each one manually to the settings.json file... |
Until this is fixed, you can do this as a workaround: -"cpputestTestAdapter.testExecutable": "${workspaceFolder}/unittest/build/HAL_UnitTests*",
+"cpputestTestAdapter.testExecutable": "${workspaceFolder}/unittest/build/HAL_UnitTests*;workaround", The "workaround" string gets globbed out of existence, but its presence triggers the multi-file globbing behavior. |
* 1.3.4 * Refactored Settings to be testable * Updated npm packages * Wrote tests and fixed issue #55 * Fixed merge conflicts
* 1.3.4 * Refactored Settings to be testable * Updated npm packages * Wrote tests and fixed issue #55 * Fixed merge conflicts * Update do_release.yml * Updated node to latest version * fiddling with release * fiddling with release * workflow * workflow * workflow * workflow * workflow * workflow * workflow * workflow * workflow * workflow * workflow * workflow * workflow * workflow
Hi all, this should hopefully be done with latest 1.3.9 version |
VS Code version 1.88.1
cpputestadapter version 1.3.4
Widcards for unit tests executable extension used to work prior to last weeks release.
With the recent update during the week of 4/17/24 this feature is no longer working the same.
I have a VS Code workspace with a setting like this (in the workspace file),
"cpputestTestAdapter.testExecutable": "${workspaceFolder}/unittest/build/HAL_UnitTests*",
That used to find the unit test executable on Windows and WSL2( Ubuntu) no problem. Now the unit test executable can not be found without removing the wildcard.
Additionally,I have a setting like this,
"cpputestTestAdapter.testExecutable": "${workspaceFolder}/utilities/cmake/UnitTests/build/AppTests/App_UnitTests*;${workspaceFolder}/utilities/cmake//UnitTests/build/SubsTests/PAL/PAL_UnitTests*;${workspaceFolder}/utilities/cmake/UnitTests/build/SubsTests/HAL/HAL_UnitTests*",
Just the opposite is true, the wildcards are still required in this workspace to find my executables.
It appears the wildcard works when there is a list of multiple executables and doesn't work when there is only one.
I am using the wildcard, because I have team members using Linux and team members using Windows.
The preferred functionality would be for no file extension to be required, such as in launch.json files. IDK if that is possible in the way VS Code extensions are written as I am not familiar with that development. If I were pointed in the right direction I would be happy to take a look and try to create a pull request for the feature.
Thanks
The text was updated successfully, but these errors were encountered: