nunit-console: In nunit3-console you cannot pass parameters containing ';' because they always get splitted

I think --testparam or -runparam would be fine.

To the whole not breaking the API and SemVer, I think it is a nice ideal and we shouldn’t introduce subtle hard to diagnose behavior changes, but I think we should be free to break things in obvious ways in order to fix things. To me, incrementing the version to 4.0 to do that isn’t realistic or practical and I don’t think the majority of ‘dark matter’ developers even realize the significance of it. If our experience moving from 2.x to 3.x is anything, developers will still complain that you moved their cheese even if you’re yelling the breaking changes to the world 😄

I find these long back and forth discussions a bit overwhelming and hard to keep track of especially for such a small issue. We have enough work keeping up without adding to it ourselves.

@jnm2 Quite confusing, I’d say!

I’m not sure that such a feature would be any easier than what we can do already. Plus, we would still have to handle all other (non NUnit 3) frameworks differently. Better to have one approach that works for all. Seems to me that the concept of a driver is what gives us the capability to “recognize” and give an error for anything the framework we are driving won’t handle. The driver is the only part of the engine that knows what framework it is using and what it is capable of.

@jnm2 Note that you can’t use -rp, as that would be equivalent to -r -p. It would have to be --rp, just as you do with git merge master --ff. This is a linux/unix standard that has been adopted by many cross-platform programs and is enforced in Options.cs.

What you say about the command-line as API is correct, in the strictest sense. But we have never been very strict about it in the past, having changed our definition of command-line options many times without a qualm. The fact is that such a change on our part requires a lot less effort for users to respond to than a change in how an assertion or an attribute works.

I’m not convinced that strict adherence to definitions is always useful. I guess “What’s most useful at this moment?” would be my guideline rather than “What constitutes an API?”

I do think this stuff needs to be discussed, so thank you for that.

Regarding frameworks… NUnit has generally been able to work with all it’s older frameworks over many years. Each 2.x runner worked with all preceding frameworks for many years. and then many years more with all 2.x frameworks. NUnit 3.x continues to work with 2.x, through an extension.

However, in the past, the assumption was that major releases only happened every decade or more. Since you are talking about 4.0 coming out soon, then I don’t think it can be the big bang change that we had with 3.0. All this is covered in our Vision document, but may not be spelled out as well as it should be. It will be up to you guys (Core Team) after I leave to decide if you want to change the Vision and Values of NUnit, but IMO you should formally change them before you act on those changes. Up to now, our goal has been that no user has to recompile using a new framework in order to use a new runner, although they may want to in order to use new features.

I wonder if we should introduce --runparams or something with the new behaviour, and deprecate --params. The console could show a warning whenever --params is used, and we could remove it in a future release. That would provide a clean ‘upgrade path’ for people - the only issue is that we end up with a slightly less sensible command line argument.

--runparams would then error with pre-3.5 frameworks.

I’ve removed the easyfix label from this - I think it’s anything but! 😄

PR #155 did not fix this issue but was closed automatically because it contained the comment “Fixes #23”

As indicated by its title, PR #155 removed parameter parsing from the framework and made it the responsibility of the runner. Additionally, as part of the change, we started using a dictionary rather than a string to represent parameters. The intent was to make it easier to subsequently fix the problem called out by this issue.

There have been various views of backward compatibility raised here. For the record, my own is that there is never a backward compatibility problem when something broken is fixed. Of course, there can always be somebody who came to rely on the broken implementation, but frankly that’s there own fault. In this case, the only risk to worry about is if we use a non-standard escaping mechanism, which would not be known in advance to users. Let’s not do that!

I’m re-opening this issue.