Build/Test Issues

Don't know how to fix constant "This test was not executed during a planned execution run."

Started by jnm236 on 7,063 views

If you were regularly getting this message on 200 tests:

This test was not executed during a planned execution run. Ensure your test project is stable and does not contain issues in initialisation/teardown fixtures.


but any individual test you run succeeds, how would you go about diagnosing?
There is no other error message in the tests window.

Using NUnit 3.7.1, some tests with TestCaseSource, some non-parameterized, all behaving the same.

No setup or teardown methods. No errors in ReSharper's runner or NUnit console runs.

Edited

Something is going seriously wrong in the test process when it tries to execute your tests.

If you can send through a bug report after you've had this happen, I should be able to advise further. If there's an error, this should show up in the logs. If you set your 'Log Verbosity' setting to 'Detailed', there should be more detailed information available about the run inside the test tasks in the Processing Queue Window.
Sent the bug report.

I don't see anything obviously wrong in the processing queue log with the verbosity detailed, but then again it is huge.
Thanks for the report.

Something is going seriously haywire in the way that NUnit is reporting results here. Everything is being reported very badly out of sequence.

Are you using any NUnit plugins? Do you have any specially coded settings that might cause NUnit to try to implement concurrent or parallel execution?
Oh yes! There is that. I have [assembly: Parallelizable(ParallelScope.Children)] and I very definitely like it that way. It's terribly convenient when using ReSharper and when using NUnit Console.

So that makes sense. I would expect NCrunch to be fine with that, though.

Edited

You'll need to disable this attribute when working under NCrunch. For example:

#if !NCRUNCH
[assembly: Parallelizable(ParallelScope.Children)]
#endif

Tracking code coverage data is impossible when tests are being run concurrently in the same process, because there is no way to differentiate one test run from another. Code coverage tracking is heavily reliant on global state (think multi-threaded tests), so when you have multi-threaded state being updated by different tests at the same time, there's no way to know which test is actually responsible for touching the code.

Because NCrunch parallelises things at a much higher level, it's fairly useless to do this in-process anyway. For these reasons, NUnit parallelization cannot work with NCrunch and never will.

I've made a note to add an error when this attribute is detected under NCrunch, so that these problems are bit less cryptic.

Edited

That's understandable and that'll work. Thanks for the help!

Post a reply

Log in to reply.