Closed sbakharev closed 2 months ago
I think your issue relates to #3939. Could you please try the steps described there and let us know?
@Evangelink the issue you've referenced is about VSTest task test assemblies pattern and its default value. I've attached a whole reproduction solution with an example call to just vstest.console.exe (no VSTest task used) which does not use any default assemblies pattern - the test assemblies are explicitly listed in command line arguments. I've also attached the diagnostic logs which show the wrong test adapter being loaded for the net472 assembly. So these are seemingly different issues.
@Evangelink my issue is only connected to VSTest task due to the task's strange /TestAdapterPath
argument setting behavior. But if the problem in vstest.console.exe would get fixed, the VSTest task would also stop failing in the described cases.
This is caused by azdo vstest task which sets the default adapter path to the root of the project. This is source of numerous issues, yet we are unable to the responsible team to remove it. https://github.com/microsoft/azure-pipelines-tasks/issues/16915
Description
Hello.
The Azure DevOps VsTest task executes tests from multiple found test dlls via a single
vstest.console.exe
call.One interesting point is that the task allows you to use directory wildcards to search for test libraries, e.g.
*\*.UnitTests.dll
. So if the search directory has a structure like this:Then the
vstest.console.exe
call looks like this:Notice the
/TestAdapterPath
argument which for some reason points to the search directory though in my pipeline (classic release) the parameter "Path to custom test adapters" is left blank. It's description states "Adapters residing in the same folder as the test assemblies are automatically discovered". So this task's behavior is probably a bug by itself but it has also uncovered a problem invstest.console.exe
.When you run multiple test libraries with different target frameworks and the
/TestAdapterPath
points to their parent directory, then the netframework tests are reported as not found by NUnit and don't run.Another detail is that if you filter all tests out with a
/TestCaseFilter
argument then the output would no longer say that there are no tests found in netframework libraries, but that all of the tests in all libraries do not match the filter criteria. So seems like it matters whether any tests have actually been executed./Parallel
and/InIsolation
arguments do not affect this behavior.Steps to reproduce
Debug
configuration.Expected behavior
Actual behavior
By the way it's also a significant problem that this test run is considered successful. This easily results in false positives during CI/CD executions. I've only found the problem by manually reviewing logs because I'm already cautious about different-framework runs after I've faced this similar issue some time ago.
Diagnostic logs
VsTestNUnitNoTestsRepro-VsTest-logs.zip
There we go, the net472 testhost uses the net6 test adapter (the first found via recursive search?):
Environment
P.S. I've also retested this with the newest
NUnit 3.13.3
andNUnit3TestAdapter 4.3.0
and the issue persists.