Modifications to test run parameter processing

[CharliePoole]

Fixes #888

@jnm2 Since you worked on documenting the existing behavior I think you're the best one to review the changes I'm making.

[jnm2]

Why do we want this behavior to change?

[CharliePoole]

It seemed more like what one would expect. If you type X = 5, don't you expect X to be 5 rather than " 5" ?

Ideally I would have wanted your first example to work differently from the other two, but of course we get the same thing in all three cases after Windows command-line processing.

[CharliePoole]

I'm not totally in love with this solution either. :-(

[jnm2]

The problem is, what if someone types X=" 5" at the command line? When that gets turned into string[] using standard Windows argv rules, the string we get in the array is X= 5.

How then should people put leading or trailing spaces in test parameters if they want to?

[jnm2]

(There's no way to distinguish whether "X= 5" or X=" 5" was typed by looking in string[] args.)

[jnm2]

Also, if someone typed X = 5 at the command line without quotes, string[] args would contain the three elements X, =, 5.

[CharliePoole]

So... thinking about it, all of these same considerations apply in spades to the --where option, because there are even more possibilities as to how and where you use quotes on the command-line. Mostly, I've dealt with the problems people bring up by saying: "don't do that, do this." Can we do that here? The practical rules would be...

1. Use =, : or space after --param
2. Avoid spaces in the argument that follows, but
3. If you must have spaces, put the whole following argument in quotes
4. If the value part of the argument has spaces, use single or escaped double quotes around that part only.

So
--param X=5
--param="X = 5"
-p:"X='Something with spaces'" (OR ""Something with spaces""

Obviously, that would all have to be documented.

OTOH, we could go back to the existing behavior, which you documented in tests, but then we would be inconsistent with how --where is processed and up to now that has been OK.

[jnm2]

The only downside to changing it is that wrappers of NUnit such as Cake and NUKE will not be able to share logic for escaping parameters between v3 and v4. If the difference is subtle, it might not get implemented properly. (For all I know, it might already not be.)

[jnm2]

If the value part of the argument has spaces, use single or escaped double quotes around that part only.

Just as a reminder, with argv parsing, these three things all result in the string --param=X= 5 being in string[] args:

• "--param=X= 5"
• --param="X= 5"
• --param=X=" 5"

We can't tell them apart. So we will either have to require single quotes, or never trim the value part. (Similar for the name part, but how likely is that to actually want whitespace around it?)

[CharliePoole]

Yes, that's my point exactly. However, my conclusion from the same facts seems to be different. (No surprise)

If we could tell them apart, I'd want the third one to work differently from the first two. But we can't and I hope our users know that as well. (That last part is a bit shaky, since some of our users these days are not programmers.)

In any case, I'd like us to be consistent for all the options that take name/value pairs.

So which side are you coming down on here? Are you saying you're OK with trimming names but not values?

[CharliePoole]

@jnm2 OK... no more updates till you finish!!!

[CharliePoole]

Rebased. @jnm2 Where are we on this... i.e. your thoughts on trimming names and/or values?

[CharliePoole]

I'd like to keep up the momentum so I'll merge this now but I'm open to further changes when we have time to discuss them.