nunit: Running tests directly should never surface a NullReferenceException
We’re gathering a few bug reports around this issue. People try to manually run or debug an NUnit test and get a NullReferenceException. This sends the message to the user that this is a bug we do not know about. It would be better if we surfaced an exception with a helpful message getting the user on the right track.
Even better than that, I wish we could fall back gracefully and continue. That is going to be the user’s expectation and it allows conveniences during development such as ad-hoc debugging into a test on F5 like what’s manually done here:
public static class Program
{
public static void Main() => new TheFixture().TheTest();
}
[TestFixture]
public sealed class TheFixture
{
[Test]
public void TheTest() => Assert.That(...);
}
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 1
- Comments: 29 (25 by maintainers)
@rprouse That’s what I would do as well. But @jnm2 feels like he can make it work when null and I didn’t want to discourage him. 😈
@Robot1que we also have all builds of master available as a MyGet feed to be consumed by people that need it. You will need to modify a nuget.config file to pull from the new feed, but it is there if you need it.
https://www.myget.org/feed/Packages/nunit
@nunit/core-team See previous comment, where I was teasing @Jivko1212 a bit for not reading the labels.
The fact is, however, that you need to read our developer docs to understand our process and interpret the labels correctly. It hadn’t struck me before, but this can be viewed as a fault in our process. Maybe we should re-define labels in a way that it makes the status of any issue crystal clear to any user, without ZenHub and without having read to read any documentation.
I started looking. Seems simple but the test is a tad hard to construct, since we want to run the test outside of a test. 😕 I may just test it externally.