Generic Test Fixtures not run from VS Test Explorer

[manfred-brands]

This is using any version of the adapter up to 5.1.0-alpha.3 and either nunit 3.14.0 or 4.3.2.

Given the following test:

[TestFixture(TypeArgs = [typeof(object)])]
[TestFixture(TypeArgs = [typeof(string)])]
internal sealed class GenericFixtureWithProperArgsProvided<T>
{
    [Test]
    public void SomeTest()
    {
        Assert.That(typeof(T).IsClass, Is.True);
    }
}

Running dotnet test gives:

NUnit Adapter 5.0.0.0: Test execution started
Running all tests in D:\Development\3rd\nunit\nunit.issues\IssueXXXX\bin\Debug\net9.0\IssueXXXX.dll
   NUnit3TestExecutor discovered 2 of 2 NUnit test cases using Current Discovery mode, Non-Explicit run
NUnit Adapter 5.0.0.0: Test execution complete
  IssueXXXX test succeeded (0.9s)

Test summary: total: 2, failed: 0, succeeded: 2, skipped: 0, duration: 0.9s
Build succeeded in 1.3s

Right clicking Run Tests in VS Solution Explorer or Running test from Test Explorer gives;

I have traced it down to the NUnit.Prefilter setting:

  <NUnit>
      <PreFilter>true</PreFilter>
  </NUnit>

We have enabled this on all our projects as a suggested performance improvement:
See nunit.docs

Changing prefilter to false causes it to work.

Is this something that can be fixed or do we have to disable the Prefilter and how does that affect performance on our bigger projects.

[manfred-brands]

Reproducible code uploaded to nunit.issues

[OsirisTerje]

The Prefilter functionality was introduced in 3.15. The feature is in issue #529 and implemented in the adapter PR #553 by https://github.com/MatthewBeardmore.

Prefilters require a set of testcases to be sent down to the adapter.

The dotnet test command works because it don't do that, so the prefilter is never active in dotnet test.

The actual functionality of the prefilters are implemented in the NUnit.Engine. What I do see is that the filter is being processed in the adapter where the arguments are stripped. See

I am not familiar with the engine implementation, but could there be a disconnect here ?
@CharliePoole Do you have any insight to this ?

[stevenaw]

I recall there may be prefilter logic in the framework itself too. We should consider looking there as well as part of any investigation

[CharliePoole]

There is no engine implementation. The pre-filter is passed through to the framework, which handles it.

The console runner hasn't recognized the option for a long time, which gave me the false impression that the framework no longer used it. When I discovered it was still part of the framework, I re-introduced the option in the V4 code. However, I can find no issue that was ever raised about its removal.