Doesn't find NUnit Test project
bernardbr opened this issue · comments
Hello, in this new version, the TestExplorer doesn't find the NUnit test project.
Please see, the image below:
Regards
Hey, was this project working before 0.3? If you go to the output/test explorer terminal what does it say?
Hi @stefanforsberg!
The project was working before 0.3 version.
When I'm go to output/test explorer I got this report:
Starting extension
Executing dotnet test -t -v=q in c:\SVN\net\trunk\alterdata.netcore.framework
[ERROR] Error while discovering tests - Error: Couldn't extract assembly paths from dotnet test output: Build iniciada, aguarde...
Thanks!
Ops! I did a Downgrade to 0.23 version and got the same issue.
Are something wrong on my project?
When I use codeLens the test runs fine...
I reproduced the issue here: https://github.com/bernardbr/vscode-dotnet-test-explorer-issues-77-example
Hey @bernardbr! The code lense integration (if you by that mean the Run test / Debug test above the test method) is actually not from our extension but from the omnisharp one.
I'll take a look at your issues soonish, thanks for the reproduction 🍒
@bernardbr I'm not able to reproduce your error but I have a suspicion that the error stems from the fact that you're running some sort of spanish localisation of the cli. For nunit (and mstest) we have to parsed the actuall dll:s being tested (using the regexp /^Test run for (.+.dll)(.+)/gm) which I guess will not handle the spanish output (or any other language for that matter).
Does this sound like a reasonable error cause @jmansar?
Yes that sounds right. The possible solution might be setting DOTNET_CLI_UI_LANGUAGE to en-US before running dotnet test to override the system language.
DId a quick try of setting the DOTNET_CLI_UI_LANGUAGE to es and that changed the output of dotnet -h to spanish but dotnet build and dotnet test output is still in english.
Upgraded to the latest sdk and now dotnet build is outputed in spanish but dotnet test is still in english.
@bernardbr If you execute dotnet test in your repro-repo, what is the output of that command?
I'm sorry for not seeing the posts before!
In my case, the dotnet framework is working in Brazilian Portuguese, and when I ran the dotnet test command I got this following output:
Build iniciada, aguarde...
Build concluído.
Execução de teste para C:\SVN\net\trunk\alterdata.netcore.framework\test\unitario\bin\Debug\netcoreapp2.0\Alterdata.NetCore.Framework.Teste.Unitario.dll(.NETCoreApp,Version=v2.0)
Ferramenta de Linha de Comando de Execução de Teste da Microsoft (R) Versão 15.7.0
Copyright (c) Microsoft Corporation. Todos os direitos reservados.
Iniciando execução de teste, espere...
Total de testes: 1. Aprovados: 1. Com falha: 0. Ignorados: 0.
Execução de Teste Bem-sucedida.
Tempo de execução de teste: 1,1566 Segundos
@stefanforsberg I've tried to run set DOTNET_CLI_UI_LANGUAGE=en but it didn't work...
I will try to do this: microsoft/vstest#821
Thank you very much @stefanforsberg and @jmansar
Using the solution (remove language folder in SDK path): microsoft/vstest#821
The Test Explorer worked fine!
Glad you found something that works, looks like this is the workaround until we (or rather the cli team) comes up with a better solution then. Thanks @bernardbr.
Hello.
(Adding here since I felt this was the most appropriate place even after being closed...)
Seeing #209 was integrated after 0.7.0, I was hoping this may have been resolved by now, but found the extension still unable to list tests in my Japanese environment, without removing language folder in SDK path mentioned in this issue. The DOTNET_CLI_UI_LANGUAGE is for some strange reason not observed just for the DLL line.
Instead of relying on the English string "Test run for ", how does using the directory path as the key for extracting the DLL sound? I played around editing the extension's .js file directly and below modification got refresh to seemingly work properly without hacking SDK.
function extractAssemblyPaths(testCommandStdout, testDirectoryPath) {
var escapedTestDirectoryPath = testDirectoryPath.replace(/[-^$*+?.()|[\]{}]/g, '\\$&').replace(/[\\/]/g, '[\\\\/]');
const testRunLineRegex = new RegExp(`(${escapedTestDirectoryPath}.+\\.dll)\\(.+\\)`, 'gm');
...
Note that the caller function (discoverTests) have to be modified accordingly. I have only tested this on Win10 JP and in a small test environment, so there's a chance I have overlooked something. Also, I haven't tried porting this change to the original .ts code.
Similar suggestion has been made in #236 ; either ways it would be great if we could remove the prerequisite running dotnet tooling in English listed in the top page.
As an aside, it may help to add --nologo when calling dotnet test, slightly shortening the text to be parsed by regex.
(Edit: Please disregard the above comment. Realized --nologo was an option added in .NET Core 3.0.)
Regards.
I can confirm that with 0.7.4 I still have the issue on my French machine despite #209. When run on CLI, dotnet test -t -v=q with DOTNET_CLI_UI_LANGUAGE=en gives an English list of tests as expected.
@stefanforsberg: can this issue be reopened? Available for tests if needed.
This isssue is still present in 0,7.5. It helps to rename the local language folder in the .Net Core SDK but a permanent solution would be better. Maybe this can help: change language in Powershell
I also offer help in testing.
Upon further research: As the problem seems to be the function "extractAssemblyPaths" maybe it would be enough to change the regex to only find the text in quotes (which should be the same in any language). The testnames at the end of this output are simply all lines intended after the last line without intendation.