Skip to content
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

Open
j3270 opened this issue Apr 22, 2024 · 5 comments
Open

Wildcard support sporatic #55

j3270 opened this issue Apr 22, 2024 · 5 comments

Comments

@j3270
Copy link

j3270 commented Apr 22, 2024

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

@bneumann
Copy link
Owner

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.
my guess is that, from your description, the regex handling is not done for single files now

@j3270
Copy link
Author

j3270 commented Apr 23, 2024

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.

@eMKa94
Copy link

eMKa94 commented Aug 12, 2024

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:

"cpputestTestAdapter.testExecutable": "${workspaceFolder}/build/UNIT_TESTS/test_runners/*",

causes the test explorer to not resolving my wildcard "*"

Screenshot from 2024-08-12 15-13-21

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...

@malsyned
Copy link
Contributor

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.

bneumann added a commit that referenced this issue Oct 2, 2024
bneumann added a commit that referenced this issue Oct 2, 2024
bneumann added a commit that referenced this issue Oct 2, 2024
* 1.3.4

* Refactored Settings to be testable

* Updated npm packages

* Wrote tests and fixed issue #55

* Fixed merge conflicts
bneumann added a commit that referenced this issue Oct 2, 2024
* 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
@bneumann
Copy link
Owner

bneumann commented Oct 2, 2024

Hi all, this should hopefully be done with latest 1.3.9 version

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants