Char '&' not supported in test parameters in Nunit 3.7.0

[jocasofer]

Hi,

If I run a test with this commandline, all parameters after '&' are disregarded:
nunit3-console test.dll --params=Parameter1Name=Paramet&er1Value;Parameter2Name=Parameter2Value

In TestResult.xml, they show up like this:

...
<setting name="TestParametersDictionary" value="[Parameter1Name, Paramet]">
...
<setting name="TestParameters" value="Parameter1Name=Paramet" />
...

I also tried to escape the '&' but with no luck.
Is there any other way to use parameters with '&'?

Just another thought, why not use the runsettings file to pass the parameters to nunit-console?
Because I can run my tests from VS, with parameters containing '&'.
(In this case, '&' needs to be converted to '&')

Thanks
Jose

[ChrisMaddock]

This is a command line problem, rather than Nunit I’d guess. Have you tried escaping the ampersand, as below?

https://stackoverflow.com/a/1327476

[jocasofer]

Thanks Chris, that worked great!

I still need to remove the ^ from the parameter, but it's just a minor inconvenience and can be done easily when parsing the parameters.

Regarding .runsettings (or .testsettings,....), is there any reason for not being supported by nunit-console?

Thanks for your help!

[CharliePoole]

@jocasofer NUnit-console came first, of course, and as a command-line program relied on arguments to specify parameters and options. The VS adapter didn't have any way to enter arguments but Microsoft provided the option of a .runsettings file, which we adopted.

There's no technical reason that file couldn't be supported by the console with a command-line option that pointed to the file. However, that would result in having many different ways to specify options. Currently, we support direct entry of options, the --testlist option and the @filename syntax. Adding a --runsettings option seems like it could be confusing. Additionally, there are many options that are not allowed when running under VS, so the implementation might be a bit messy.

[ChrisMaddock]

I still need to remove the ^ from the parameter, but it's just a minor inconvenience and can be done easily when parsing the parameters.

That shouldn't be necessary - by the time it gets through to your C#, the parameter should just read Paramet&er1Value - like you'd expect?

What are you actually passing? 🙂

[jocasofer]

@ChrisMaddock You're right! I had some quote characters in the parameters that shouldn't be there. I removed them and it's working perfectly.
Thank you for your support!

@CharliePoole I understand your point of view. But my question originated from my need of having 2 parameters files. A XML runsettings file for VS and a batch with --params for NUnit-console. This can potentially lead to running tests with different settings from VS to NUnit-console. My suggestion was to allow something like --paramsFile=vs.runsettings. If we could just copy the file, we could prevent inconsistent parameters between the two files. Currently, neither --testlist nor @filename support this feature, right?
Thank you for your feedback.

[CharliePoole]

@jocasofer I see your point, particularly for users (unlike me 😄 ) who consider VS as their primary environment for running tests. There would be some details to work out about how to represent settings that are available by design in the console but not in the adapter. Conversely, if such settings were placed in the .runsettings file, the adapter would need to ignore them. That's not hard to do - unknown settings are already ignored - but might require some explanation for users.

Essentially, it seems to me that CI will almost invariably require some other set of parameters from test runs performed by developers on their own machines.

I agree it could be worth exploring though.