Each runner decides what to pay attention to in the output. Historically, the console ignored setup and teardown errors of all kinds and only reported on test cases. At some point (?) we decided to report assertion failures in setup and (I believe later) in teardown.

Also, fwiw, at one time we decided that any assertion failure in a teardown was an error, rather than a failed test. That is, it was considered a mistake to have assertions in a teardown, although it wasn't something we could enforce. I'm not sure if that notion has been consistently maintained, however.

Thanks for that historical context @CharliePoole
Avoiding assertions in teardowns is something I've seen consistently recommended here, though as you say, it can't be enforced.

Within the framework side, in response to @OsirisTerje 's point 1, I wonder if we should perhaps rewrite these tests a bit.

We also have #937 as an older issue which aims to remove direct Explicit usage in our tests. If that were still desired then one (untested) option here could be to simply move much of the structure into the TestData project in order to run and assert against the results within the framework tests themselves. That would also allow us to keep the implicit validation that the Explicit test doesn't run - if that were still desired or needed of course.

Interesting. It appears that the SkipCount line was added specifically to validate the Explicit handling... at least according the the commit message: 043ec55

Perhaps then something has changed to prevent Explicit tests being "skipped"?

it was considered a mistake to have assertions in a teardown

At our work we have a base class that in the OneTimeSetUp subscribes to UnobservedTaskExceptions and in the OneTimeTearDown unsubscribes.

Our base class asserts in the per test TearDown that no exceptions were caught, rethrowing them if there were any.
This correctly fails the test and output is logged in TestExplorer.

If any tasks are still running when NUnit thinks the test is finished, it won't be reported.
We also have a check in the OneTimeTearDown for such case.
But that doesn't break the tests.

NUnit itself, at the moment, doesn't see any exceptions raised in different threads.
Those actually can cause NUnit to be killed.
That could be something to consider adding.

I'll check a few early versions tomorrow, but I am beginning to suspect that behavior may've changed prior to NUnit 3.0's launch. A likely solution would be to use ExplicitCount here instead, in addition to any other modifications we may want to remove the assertions from a OneTimeTearDown.

I had a hard time understanding the intended SkipCount behavior but what I can glean is that the Explicit test may've been "skipped" at one point whereas now it is never processed or included in result counts at all. I'd think any adjustments on the framework side should probably adjust the count accordingly rather that removing the assertion.

Interestingly, moving the tests into the testdata project seems to allow the same assertions to pass
main...onetimeteardowntests

EDIT: I'll try and get some PR up soon, including something to validate that failed asserts in these lifecycle methods result in errors

I'm back from vacation. One of the main reasons I haven't pushed a PR here yet is I would like to see if VS is passing in any filters here which could explain the difference in behavior. I'll be trying to investigate that soon