Thread.CurrentPrincipal Set In TestFixtureSetUp Not Maintained Between Tests

[Amy Thorne]

This is very similar to a previous discussion,
http://groups.google.com/group/nunit-discuss/browse_thread/thread/d5b3ff25f02485ed

I don't see a resolution to that, though, and I'm running into the
same issue.

If I run the test class below in NUnit 2.5.2, both tests pass. If I
run it in 2.5.3, the second test to run fails.

Obviously, this is a very contrived example, but it's the simplest
equivalent I have for the more complicated code in the real project
that I'm working on.

Is this as-designed? To use NUnit 2.5.3+, do we need to change our
tests so that if we have code like this, we need to have the
Thread.CurrentPrincipal assignment in SetUp instead of
TestFixtureSetUp?

Thanks in advance,
Amy

using System.Security.Principal;
using System.Threading;
using NUnit.Framework;

namespace ThreadStateTest
{
[TestFixture]
public class ThreadIdentityTest2
{
[TestFixtureSetUp]
public void TestFixtureSetUp()
{
var identity = new GenericIdentity("foo");
Thread.CurrentPrincipal = new GenericPrincipal(identity,
new string[0]);
}

[Test]
public void Test1()
{
Assert.AreEqual("foo",
Thread.CurrentPrincipal.Identity.Name);
}

[Test]
public void Test2()
{
Assert.AreEqual("foo",
Thread.CurrentPrincipal.Identity.Name);
}
}
}

[RJV]

Hi Amy,

If I understand correctly, each test's individual Thread's Principal needs to be different, right? Whereas, TestFixtureSetup is going to initialize the Principal to one value (when the test fixture is run) and this Principal will remain the same throughout the fixture execution.

Jv

--
You received this message because you are subscribed to the Google Groups "NUnit-Discuss" group.
To post to this group, send email to nunit-...@googlegroups.com.
To unsubscribe from this group, send email to nunit-discus...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nunit-discuss?hl=en.

[RJV]

Hi Amy,

I ran it in 2.5.2 as well and both tests pass. I will try to run it in 2.5.3...

Jv

On Thu, Feb 4, 2010 at 8:29 PM, Amy Thorne <amygil...@gmail.com> wrote:

[RJV]

Hi Amy,

The below modified code works in 2.5.3. Yours did not because the CurrentPrincipal's value gets lost after the first test is run but by storing it in an IPrincipal object it is retained through the class.

        [TestFixture]

        public class ThreadIdentityTest2

        {

            private IPrincipal ip;

            [TestFixtureSetUp]

            public void ThreadIdentityTestFixture()

            {

                var identity = new GenericIdentity("foo");

                ip = new GenericPrincipal(identity,new string[0]);

            }

            [Test]

            public void TestFooTwo()

            {

                Assert.AreEqual("foo",

     ip.Identity.Name);

            }

            [Test]

            public void TestFoo()

            {

                Assert.AreEqual("foo",

     ip.Identity.Name);

            }

        }

Jv

On Thu, Feb 4, 2010 at 8:29 PM, Amy Thorne <amygil...@gmail.com> wrote:

[Simone Busoli]

Hi Amy,

I'm not aware of why the behavior changed in 2.5.3, but the point is that you should not rely on undocumented features like this one since they could change with new releases. In particular, you cannot be sure that the TFSU will execute in the same thread as the tests, nor that thread data like principals will be passed to spawned threads.

I suggest you place the code which sets the principal in SU instead of TFSU.

[Charlie Poole]

Hi Simone,

 

That's a really good point. We should stress it in the docs.

 

IMO, we can and should guarantee that SU and TearDown execute on the same thread

as the test itself, even when we introduce parallel exectution. It's not possible to make

the same guarantee about TFSU.

 

That said, this seems like a bug, since I know we have code that intends to maintain

the same Principal set at a higher level through all the lower levels. I suggest that

the OP file a bug report.

 

Charlie

 

PS: Just peeking... my conference starts tomorrow.

---

From: nunit-...@googlegroups.com [mailto:nunit-...@googlegroups.com] On Behalf Of Simone Busoli
Sent: Monday, February 08, 2010 12:52 PM
To: nunit-...@googlegroups.com
Subject: Re: [nunit-discuss] Thread.CurrentPrincipal Set In TestFixtureSetUp Not Maintained Between Tests

[Simone Busoli]

Yes, please Amy, file a bug report on launchpad about this issue.

[Amy Thorne]

Whoops, I looked away for a couple days and suddenly help came to the
rescue :-)

Generally each individual test's principal doesn't need to be
different. We have a system we're testing where you need to be "logged
in" to perform many actions, where if there's no HttpContext, logging
in consists of setting Thread.CurrentPrincipal. We have a lot of tests
around the actions where we're more interested in testing the action
itself than in testing the part about being logged in. And the way we
took care of that in many of our tests was just by logging in as a
default user in TFSU.

I'm not saying that was the best way to do it, it's just what
happened.

I found that when I recently upgraded to 2.5.3, I started getting
failures due to not being "logged in." So, I isolated and simplified
the problem to the code I posted.

Although I never used 2.5.2 in day-to-day use, I did grab it and check
that it didn't happen there, so it seems to be related to a change in
2.5.3. I thought it might be related to the bug fix "Thread principal
is now saved before each test and restored afterward eliminating
failures under .NET 4.0." that's listed in the release notes at
http://nunit.com/index.php?p=releaseNotes&r=2.5.3.

I'd have to go back and check again, but when I was playing with it, I
tried writing out the thread's ID in each test, and I thought it
actually was the same, which I thought maybe meant that the tests were
executing on the same thread. But I should probably play with that
more.

Anyway, I can work on changing our tests not to rely on "logging in"
in TFSU, I just wasn't sure if I needed to, or if it might be a bug in
NUnit that would get fixed, rather than expected behaviour.

And sure, I'll add a bug report on launchpad.

Thanks all,
Amy

On 9 Feb, 06:58, Simone Busoli <simone.bus...@gmail.com> wrote:
> Yes, please Amy, file a bug report on launchpad about this issue.
>

[Amy Thorne]

I added this to launchpad here, https://bugs.launchpad.net/nunitv2/+bug/519912

On 9 Feb, 19:02, Amy Thorne <amygilchr...@gmail.com> wrote:
> Whoops, I looked away for a couple days and suddenly help came to the
> rescue :-)
>
> Generally each individual test's principal doesn't need to be
> different. We have a system we're testing where you need to be "logged
> in" to perform many actions, where if there's no HttpContext, logging
> in consists of setting Thread.CurrentPrincipal. We have a lot of tests
> around the actions where we're more interested in testing the action
> itself than in testing the part about being logged in. And the way we
> took care of that in many of our tests was just by logging in as a
> default user in TFSU.
>
> I'm not saying that was the best way to do it, it's just what
> happened.
>
> I found that when I recently upgraded to 2.5.3, I started getting
> failures due to not being "logged in." So, I isolated and simplified
> the problem to the code I posted.
>
> Although I never used 2.5.2 in day-to-day use, I did grab it and check
> that it didn't happen there, so it seems to be related to a change in
> 2.5.3. I thought it might be related to the bug fix "Thread principal
> is now saved before each test and restored afterward eliminating

> failures under .NET 4.0." that's listed in the release notes athttp://nunit.com/index.php?p=releaseNotes&r=2.5.3.

[Charlie Poole]

Thanks!

> -----Original Message-----
> From: nunit-...@googlegroups.com
> [mailto:nunit-...@googlegroups.com] On Behalf Of Amy Thorne
> Sent: Wednesday, February 10, 2010 8:10 AM
> To: NUnit-Discuss
> Subject: [nunit-discuss] Re: Thread.CurrentPrincipal Set In
> TestFixtureSetUp Not Maintained Between Tests
>