allow configuration of test discovery paths

[psethwick]

use-case: one of our (mono) repos has multiple sets of feature files, and we really only want to run the other tests locally

It seems like it should be possible to inspect the profile to get the paths from that, but .. barring parsing and evaluating both cucumber.yml and cucumber.mjs I'm not sure how. Open to ideas, tho!

Maybe it would be also better to have the setting be [profile]: paths?

[Balrog994]

Hey @psethwick ,

thanks again for your submission to the project. I was reviewing your proposal and looks like a good starting point!

I was thinking about extending your proposal for complex workspaces where there are more test projects and thus more folders to check for changes.

You're checking only the first workspace folder for a configuration, that works for simpler workspaces but not for more complex ones. So the proposed change is to check for a configuration file in each workspace folder and then apply that configuration (if exist) to that specific workspace folder, otherwise default to the global configuration (or default one).

What do you think about that?

[psethwick]

I did tilt my head a bit when I wrote workspaces[0], but I'm not super familiar with vscode workspaces.

I guess you are proposing a .cucumber-test-runner file of some sort?

Personally, I would prefer to keep the configuration in cucumberTestRunner keys in .vscode/settings.json. Reasoning being there are enough kinds of configuration files (esp in web dev) hanging around in projects and I wouldn't want to pile on.

However, configuration per workspace path makes sense, how about something like this:

  "cucumberTestRunner.workspaces": [
{
"workspacePath": ".",
"featurePaths": "features/*feature"
},
{
"workspacePath": "integration-tests",
"featurePaths": "integration-tests/features/*feature"
}
]

Then if more settings are needed per workspace in the future, the object could just be extended with more properties.

Up to you, but I would be up for implementing the vscode settings in this pr.

edit: might be better to choose a key from the WorkspaceFolder to join on Workspace.name is probably the most user-friendly

[Balrog994]

Given that a workspace is a collection of folders that can be anywhere on disk, I was thinking of using vscode .vscode/settings.json files from each workspace folder to load the right filter for that folder.

I need to check if it is possible.

That would remove the need for the workspace folder key and so on.

[psethwick]

ah yeah, that makes sense! That actually sounds better, I incorrectly thought you were proposing a new kind of file

happy to help, or feel free to make changes to the pr. I'm probably not going to find time today, but this week I could