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

@SilverXXX commented on Fri Jul 22 2016

When running some tests with nunit3-console.exe, if you pass with --param there is no way to pass inside a value a ‘;’.

It seems from CommandLineOptions.cs the you can’t escape them in any way (it’s not documented so i read the source directly). A regex to capture only not escaped char would solve the problem (i’m not a regex expert so i cant suggest exact one)

---

@rprouse commented on Fri Jul 22 2016

See our docs, there is general information there on quoting for various operating systems. You can also have multiple --param in the command line, one per variable.

I am closing this as a question, but feel free to add questions, we will see them and try to help.

---

@ChrisMaddock commented on Fri Jul 22 2016

@rprouse - I think this is a potential ‘issue’ within NUnit, not command line usage? Looks like the options will always split on semi-colon, and then throw if it’s not a valid A=B format afterwards? So I don’t think there is any way pass in a test parameter with a semi-colon currently. (If that’s to be a supported thing to do!)

---

@SilverXXX commented on Fri Jul 22 2016

Yes @ChrisMaddock, i would have tried to create a pull request to show a possible solution, it actually require only a one line change and a sensible regexp, but i’m quite bad at it (a connection string is a simple example of an impossible paramater to pass right now) Edit: and since it’s all made of key=value it doesnt even return an error

---

@rprouse commented on Fri Jul 22 2016

Sorry, reading issues on my phone, I missed the detail 😦

[rprouse]

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.

[CharliePoole]

@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.