All the tests pass because this change is untested. That's because the latest release of nunit.framework is 3.13.2. Version 4 is under development and will eventually be supported by the engine, although possibly in a future NUnit4DriverFactory rather than NUnit3DriverFactory. That depends on whether the final NUnit 4 API is similar to the NUnit 3 API or different.

If you accompanied this with a test, I'd be willing to merge it into the dev-4.0 branch rather than master. I'd also be willing to accept a PR against master, for inclusion in the 3.13 release, giving a cleaner error message - if you're interested.

For now, I'm marking this PR as Blocked until we know what will be happening with NUnit 4 and when.

@CharliePoole I agree with your comments, but shouldn't this have been considered when nunit 4 developement was started?
If nunit4 is not ready for main, why is it not in an 4.0.0-dev branch with main still pointing to 3.13.2?
Now we cannot run tests from within VS on the main branch of nunit, resulting in various issues raised against nunit and slowing down developing PRs there.

I'm happy for moving this into a 4.0-dev branch which is referenced in nunit3testadapter (5.0.0-dev?branch) to be used in nunit4.

Regarding a PR in master for a better error message, I'm not sure if we can. Yes we can improve the message in the SkippedAssemblyFrameworkDriver but that doesn't seem to bubble up to the user.

@manfred-brands A few years back, we decided that the NUnit Project was too big and split it into individual key projects, like NUnit framework and NUnit Console. (The NUnit test adapters had already been separate for a long time.)

This allows us to move ahead in each project without necessarily worrying about the others - at least most of the time. :-)

In this case, both the NUnit Framework and the Engine/Console Runner are at the point of building toward a major release at the same time. That's kind of awkward, obviously, and each project made the best decision it could based on the info available to it. The original issue, which triggered the PR, seems to be more about the adapter than anything else. You should be aware that any change to the engine will have no impact on the adapter until a new adapter version actually uses that new engine version.

I no longer work on the framework, so I'm not aware of how the framework team actually runs the framework tests. My guess is that they are not using the engine, because somebody would have complained by now if they were. :-)

If you can think of something I can do in version 3.13 to make things easier for you, let me know. We are not currently releasing dev builds of the console runner or engine from the dev-4.0 branch, but we could conceivably do that if it would help.

Not sure what you mean by a 5.0.0 branch. That's farther ahead than I can even think right now. :-)

The original issue, which triggered the PR, seems to be more about the adapter than anything else.

I know, that is where I started searching, but then it called into nunit.engine to find tests and hence I got here.
Locally indeed, I had to make changes to 3 repositories to get the tests showing up again.

how the framework team actually runs the framework tests
They use nunitlite console runner.

Not sure what you mean by a 5.0.0 branch. That's farther ahead than I can even think right now. :-)

That was referring to NUnit3TestAdapter which is currently at version 4.1.0. If this has to going into a new main branch it would have to be 5.0.0

If NUnit 4 is compatible with the NUnit3 engine at least for now, then all we need is my change (plus a new unit test), followed by updated references in the NUnit3testadapter and nunit repositories. They could be called a fix iso a feature.
I would need to get input from @rprouse to see what the way forward is. Is this an accidental oversight of increasing the version to 4.0.0 or deliberate due to possible incompatibilities.

As an alternative is to tell everyone to make nunit PRs against 3.13.2 and future port it to nunit4 iso backport.

There are some issues in nunit that also affect my developments and if I can I wouldn't mind assisting in fixing some if I can.
But being able to step through some unfamiliar code in tests is handier than adding Debugger.Launch() at places.

AFAIK the change to 4.0 in master branch is deliberate. That's a decision the team and team lead need to make, of course. It basically has to do with what you want your focus to be. Whichever is not the main branch tends to get less attention.

WRT the adapter, adding a new feature (running 4.0) isn't a breaking change, so I assume Terje would just go to 4.2 or 4.3 when upgrading the adapter, unless the 4.0 engine were actually missing some features he uses.

I thought I would be able to edit the PR to change the merge target, but apparently not. See if GitHub will allow you to do it as the author. The branch we want is dev-4.0. Otherwise, if you delete this and start over, we lose all the discussion.

Re-directed the branch to dev-4.0 and added unit test for the NUnit3DriverFactory.IsSupportedTestFramework method.

@manfred-brands Because the dev-4.0 branch has drifted quite a bit from main, this can't just be merged into main. So I'll be replicating your changes separately. See #1102.

Thanks @CharliePoole As I don't know the state of nunit 4, I do my fixes on nunit 3.13 where I can run the tests properly, then cherry pick to 4.0

I should probably have one system-level test for the console runner where it runs using the latest nunit 4 build.

This issue has been resolved in version 4.0.0-beta.1

The release is available on:
GitHub.
NuGet packages are also available NuGet.org and
Chocolatey Packages may be found at Chocolatey.org