Hi,

Are you certain that the last run of the fixture wasn't a valid failure? There are some valid scenarios where this can happen. For example, if the fixture has (or had) a failed test that is not showing in the list of tests because it's been removed from the test suite or isn't set to show in the tests window. Such a scenario could be more common if the tests are being generated dynamically (i.e. NUnit TestCaseSource) because there is a higher chance of them being removed or renamed as a result of a code change. The next time any test in the fixture is run, the failure should clear.

Under NCrunch, the fixture is considered to be a test result in itself. The failure result of a fixture will always be from the last time the fixture was executed. So you could have one call into the fixture for one of its child tests that passes, then have a later call into the fixture for a child test that fails. The results from the fixture will be from the failed test run and the fixture won't contain any data for the passing test run.

It's notable that a fixture's result is more than just the pass and fail result - it also contains code coverage/performance data and trace output. So for a fixture's pass/fail result to be entirely derived from its child tests isn't really structurally correct. I guess NCrunch could do this in the UI, but it would have the potential to look confusing as in some cases it could present failed result data as passing (or vice versa).

As an experienced user I realise you probably already understand all of the above. I thought it worth adding to this thread in case others get confused by this situation. The relationship between child tests and their parent fixtures gets very complex in the selective execution scenarios used by NCrunch.