3 proposals to solve the pending "tooling language must be english" problem / requirement

1. Check the known issues -> https://github.com/formulahendry/vscode-dotnet-test-explorer#known-issues
2. Check for other opened or closed issue matching yours?

see #77 , #96 , #107 and maybe others.

Deleting the relevant language folder solves this issue, but it seems to be a rather blunt measure.

a comment in #310 pointed me in the right direction. Obviously the problem stems from the regex in the function “extractAssemblyPaths” in the module / file testDiscoveries.ts. This is usually the first line after the call of the command: dotnet test -t -v=q <foldername>

One solution often mentioned is using the environment variable DOTNET_CLI_UI_LANGUAGE set to “en”. This works only on all following lines, but the first line still stays in the current language of the system / powershell instance.

I also tried [System.Threading.Thread]::CurrentThread.CurrentCulture = "en" but this is ignored completely, obviously language settings are not inherited from the calling shell.

So I went with the regex. I changed the line from: const testRunLineRegex = /^Test run for (.+\.dll)/gm; to const testRunLineRegex = /^.*\"(.+\.dll)\"/gm;

and it worked as far as I can check on my german set system. I build a test solution with all kind of tests (MSTest, NUnit, xUnit) and all are found succesfully.

If this regex is used elsewhere and needs to capture the part “Test run for” for other reasons, this change will probably break something else later on.

• So proposal 1 is to change this line, usually I would create a pull request, but I’m not familiar with TypeScript nor this project, so I’d rather not imposing something I cannot keep up with.

• In case this is needed as it is, proposal 2: create a list of strings, in the given languages. This might expand over time, but you could adapt the regex depending on the detected language of the environment.

• and no. 3: make a setting, where the user can enter this part “Test run for” from his language. This might be tricky as I was unable to get it to work in German, where it is called “Testlauf für” and I did not find the correct codepage to represent the “ä” umlaut.

[nohwnd]

I agree that the message should be fixed, but (and please correct me if I am wrong), is this project relying on parsing the output? If so, you’d have much easier time either registering your own logger via the logging extension point, which would post the data back to VSCode via net pipes. Or using our interfacing layer to get the data programatically and posting that to your vscode via pipe.

For the pipe stuff, (and also integrating with the new test UI in vscode) you can check out this repo, where Justin does this from a powershell instance for powershell tests (powershell is also .net so the communication code is similar except for few extra [] and :😃.

https://github.com/pester/vscode-adapter

https://github.com/pester/vscode-adapter/blob/4287a281f5d8d5830ec865af06f6f7aec9a69005/Scripts/PesterInterface.ps1

For programatic integration with vstest console you can use IVSTestConsoleWrapper, see for example how stryker integrates with it to run tests on the code it mutates: https://github.com/stryker-mutator/stryker-net/blob/fff096f54c3cb469221b282b888a39d57a7e4bb5/src/Stryker.Core/Stryker.Core/TestRunners/VsTest/VsTestRunner.cs#L95

[nohwnd]

Let’s just say that the number of people suggesting how we should do it is greater than working implementations in pull requests 😅

I know that feeling. Feel free to remind me in January to have another look at this. From a brief look, you would be able to benefit from the custom logger, without having a huge impact on the project architecture. The logger dll can be built against netstandard and added as an additional parameter to the test run.