TestContext.CurrentContext.Result throws NullReferenceException

This is working in 2.6 and 2.6.1 as far as I can tell. The NUnit tests
contain exactly
this scenario in TestContextTests.TestCanAccessTestState_IgnoredInSetUp()

I suggest you run the NUnit tests to verify that this test passes in
your system.
If it fails, then we have a bug depending on your particular platform. If it
passes, then the problem may reside in some specific combination of features
you are using or in your test itself.

In either case, please add a simple test case to reproduce this bug and include
info about your environment.

Charlie

On Fri, Sep 7, 2012 at 3:26 AM, Pavel Spacil
<email address hidden> wrote:
> Public bug reported:
>
> We are using stable NUnit 2.6 for testing using C# .Net code mainly due to new /runlist command line option.
> Before each test in method with TestFixtureSetUp attribute we check if the test shouldn't be skipped. If so Assert.Ignore is called.
> Later in method with TestFixtureTearDown attribute we are used to check TestContext.CurrentContext.Result for actual test result and report it. In version 2.5.8 it worked correctly and Status in Result was properly set. Since 2.6.0 it throws NullReferenceException. Is it something planned and we should call Assert.Ignore or check for the Result somewhere else? Thanks
>
> ** Affects: nunitv2
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are subscribed to NUnit
> Extended Testing Platform.
> https://bugs.launchpad.net/bugs/1047272
>
> Title:
> TestContext.CurrentContext.Result throws NullReferenceException
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/nunitv2/+bug/1047272/+subscriptions

Just note: TestContext.CurrentContext.Result contains correct test result after execution of method with Test attribute, it happens only when the Assert.Ignore is called during SetUp

Understood. That's exactly the situation I verified. Can you provide more info about your test? Have you tried to run the NUnit tests themselves?

So, I tried your nunit.core.tests and all in TestContextTests passed. Next I've created small class to reproduce my bug, please see attachment. It's the minimal version of your tests which we use and where you can reproduce the exception. Please remove SolarWinds.Logging to get it work, it is just internal dll to log using log4net. Thanks for your previous prompt response.

Environment: Win 7 x64 Enterprise, NUnit 2.6.0 stable, .Net 3.5 & 4 (CLR is .Net 2.0), CPU Core 2 Duo

ah, typo: your tests -> our tests, and add to Environment: Visual Studio 2010 Premium

Any progress here? It's some kind of show-stopper for us. Thanks!

I'm afraid I got a little confused between the 2.6.1 release and the work I'm doing for NUnitLite and NUnit 3.0. In the latter, newer, versions, full test info is made available to TestFixtureSetUp and TestFixtureTearDown methods. In 2.6.1, the information is really only available for the test itself and for Setup and TearDown.

I'm changing this to a feature request for 2.6.2. It's actually not clear if we will be able to do it, however. Both NUnit 3.0 and NUnitLite use a completely new design for executing tests, which has made it possible for us to provide this feature. I'll have to check and see if we can make the info available using the 2.6 codebase, without major design changes.

One comment: you indicate you use the TestFixtureSetUp method before each test to determine if the test should be executed. This isn't possible, because the TestFixtureSetUp method doesn't run before each test. It only runs once, before all the tests.

Charlie

Hi Charlie, I've just tried your fix and it does not work as we expect. About your comment: we have one .cs file per one test so we can do that by this way.

Hi Pavel,

I assume you mean you built from the source, right?

Can you supply some info about what's not working?

Charlie

I've tried 2.6.1 RC2 which include your patch as I read from changelist. Attached AssertTest.cs still does not work as expected, ie. we can't get the result in TearDown after exception in SetupFixture.

I'm not sure what bug you noticed on the changelist, but it wasn't for this one.

In my earlier (9/24) note, I said this would be fixed in 2.6.2. The fix has now been committed, so you can get it if you pull the latest source and build it. Otherwise, you have to wait for 2.6.2, which will be out sometime this month.

After sending the last note, I looked at your comment again: "we can't get the result in TearDown after exception in SetUpFixture." Before now, unless I missed something, the reported problem was with TestFixtureSetup and TestFixtureTearDown, not with SetUpFixture.

The current code works correctly for the test method itself and the SetUp, TearDown, TestFixtureSetUp and TestFixtureTearDown for the TestFixture. There's a good chance SetUpFixture will work as well because the fix was made in a base class. However, without a test I can't be sure, so I'll add one and reopen the bug if needed.

It's very difficult to discuss the different kinds of setup and teardown without getting lost!

Oh, sorry, my mistake! I've tried 2.6.1 RC2 and I thought that it is 2.6.2 RCx. And yes, I'm still talking about TestFixtureSetup and TestFixtureTearDown. Sorry again for confusing, I will try build from sources on Monday and try it again.

I verified that the current Test and Result can be accessed in a SetUpFixture. Neither of them seem very useful there, but someone may find a way to use the info.