Run test methods within a fixture in parallel

[CharliePoole]

Currently, we only have implemented parallel execution at the fixture level. It should be possible to run individual methods of a fixture in parallel as well as individual test cases for a parameterized method.

We should be able to specify the exact level of parallelism on the fixture or method.

This issue was previously part of #66

[CharliePoole]

Update: Both this comment and the following one were in reply to an individual who apparently removed his own comments. I'm leaving my answers.

Well it's in the spec and scheduled for post-3.0 implementation. If it were so easy, we probably would have done it. Not sure what connection you see with mbunit. The fact that they had it doesn't help us.

[CharliePoole]

This is getting a bit tiresome. A few points, already stated but apparently missed...

1. There is a plan to implement what you are asking for.
2. We decided as a team to schedule it at a certain point.
3. When it is scheduled has primarily to do with our assessment of the value of the feature as compared with other features.
4. There are several people on the NUnit team who could implement the feature.
5. They would be able to implement it, depending on priorities, out of their heads and would not need to copy it from anywhere.

I find your talk of "reverse engineering" very disturbing. Open source is only possible in a context where copyright is respected. So if you are suggesting that we might ignore the mbunit licensing terms, you are way off base.

[rprouse]

While I did contribute many patches to MbUnit and used it for years, I was
never a key contributor. I wouldn't want my status to be misrepresented :)

As for reverse engineering, there isn't really any use here. NUnit works
entirely different than MbUnit did. We will get to this issue in due time,
but are approaching it cautiously because other similar issues might change
the way we need to implement this or even conflict.
On Apr 19, 2015 2:45 AM, "CharliePoole" notifications@github.com wrote:

This is getting a bit tiresome. A few points, already stated but
apparently missed...

There is a plan to implement what you are asking for.
2.

We decided as a team to schedule it at a certain point.
3.

When it is scheduled has primarily to do with our assessment of the
value of the feature as compared with other features.
4.

There are several people on the NUnit team who could implement the
feature.
5.

They would be able to implement it, depending on priorities, out of
their heads and would not need to copy it from anywhere.

I find your talk of "reverse engineering" very disturbing. Open source is
only possible in a context where copyright is respected. So if you are
suggesting that we might ignore the mbunit licensing terms, you are way off
base.

—
Reply to this email directly or view it on GitHub
#164 (comment).

[CharliePoole]

A much more tactful comment than mine!

Our current priorities in the world of parallel execution are:

1. Parallel process execution
2. Exclusion groups
3. Parallel method (in one fixture) execution.

This seems to represent the order of greatest usefulness to users.

I'll also mention that marking something as post-3.0 does not necessarily mean the feature comes at a later time than it would if we made it part of 3.0. Rather, it may mean that 3.0 comes at an earlier point in time.