Now SetUpFixture doesn't work at all

[Max Guernsey, III]

In 2.6.2, with the 2.6.2 runner, it used to be that a test suite with a SetUpFixture could not be used in flat list mode, which was no major inconvenience. Now I get that same error message no matter how I have my runner configured. This is true whether I use the 2.6.2 runner or the 2.6.3 runner.

I know you aren't accepting bugs in V2. If that's really true, I'll have to go back to 2.6.2.

[Max Guernsey, III (p-max)]

I found a workaround for this. It's bizarre. I switched to the "load each assembly into its own process" setting and the problem went away. The workaround is probably all anyone really needs.

[Charlie Poole (charlie.poole)]

In spite of my intentions, if a major feature has stopped working, I'll do
a dot.one release.

However, according to NUnit's own tests, SetUpFixture is working fine. My
guess is that there is some specific factor in your case that we are not
taking into account and that it doesn't come into play when running only
one assembly.

Even though you have found a workaround, it would be helpful if you could
supply a simple repro of this bug. At a minimum, I'd like to avoid it in
NUnit 3.0!

Charlie

On Sun, Oct 20, 2013 at 7:59 PM, Max Guernsey, III <email address hidden> wrote:

> I found a workaround for this. It's bizarre. I switched to the "load
> each assembly into its own process" setting and the problem went away.
> The workaround is probably all anyone really needs.
>
> --
> You received this bug notification because you are subscribed to NUnit
> Extended Testing Platform.
> https://bugs.launchpad.net/bugs/1242502
>
> Title:
> Now SetUpFixture doesn't work at all
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/nunitv2/+bug/1242502/+subscriptions
>

[Max Guernsey, III (p-max)]

I tried to use the code to test & fix it myself but there are a bunch of missing files in the code download so I couldn't diagnose the problem. To be clear: the problem happened with one and only one assembly and I still had to set it to load "one per assembly." I'll work on trying to define a repro for it.

[Max Guernsey, III (p-max)]

I cannot easily reproduce the problem. I'll have to wait until I have access to the code and try to pare something down for a repro. This is probably not a big deal, since it seems to work in the general case. I suppose the other alternative is that it was because I was using VS2013/.NET 4.5.1. Either way, it seems like you should just ignore this until at least one other person cares about it. It's a pretty minor inconvenience to overcome and it seems like it's not likely for many people to experience it between now and when 3.0 arrives.

As far as avoiding this in 3.0, I thought you were splitting things out so that the GUI basically had no impact on how tests would be run any more. That error is probably going away altogether in the course of that refactor, right?

[Charlie Poole (charlie.poole)]

Well, the GUI will no longer change how files are loaded in 3.0. So any bug
that shows a failure when displaying the full tree is relevant while bugs
when showing the flat list of fixtures are not.
On Oct 21, 2013 12:11 PM, "Max Guernsey, III" <email address hidden> wrote:

> I cannot easily reproduce the problem. I'll have to wait until I have
> access to the code and try to pare something down for a repro. This is
> probably not a big deal, since it seems to work in the general case. I
> suppose the other alternative is that it was because I was using
> VS2013/.NET 4.5.1. Either way, it seems like you should just ignore
> this until at least one other person cares about it. It's a pretty
> minor inconvenience to overcome and it seems like it's not likely for
> many people to experience it between now and when 3.0 arrives.
>
> As far as avoiding this in 3.0, I thought you were splitting things out
> so that the GUI basically had no impact on how tests would be run any
> more. That error is probably going away altogether in the course of
> that refactor, right?
>
> --
> You received this bug notification because you are subscribed to NUnit
> Extended Testing Platform.
> https://bugs.launchpad.net/bugs/1242502
>
> Title:
> Now SetUpFixture doesn't work at all
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/nunitv2/+bug/1242502/+subscriptions
>

[Max Guernsey, III (p-max)]

Got it: Make two set up fixtures in the same namespace. All the other variables I was investigating were red herrings. Is it supported t have two SetUpFixtures in the same namespace? If not, it wasn't apparent to me from the documentation.

Maybe the documentation should be changed from "Only one SetUpFixture should be created in a given namespace" to "Only one SetUpFixture can be created in a given namespace; if more than one fixture is specified for a namespace, <however you decide which one gets used>."

In 3.0 can we lift those kinds of cardinality restrictions? It is irritating to have to merge two set up fixtures that control different resources just to satisfy a rule like that.

[Charlie Poole (charlie.poole)]

No, it's not supported. The action when two are specified is "one of them will be ignored." It's not possible to predict which will be ignored in this situation, because we cannot predict the order in which fixtures are returned by use of reflection.

Probably, we should use stronger language in the warning, since what was really meant was "Dont' do this!"

Yes, this restriction will be lifted in 3.0.

[Charlie Poole (charlie.poole)]

Marked "Won't Fix" meaning "Won't fix here" The projext is on GitHub now, as indicated in the launchpad project page. I'll shut down bugs here to keep people from posting.