microsoft
Support `@response.rsp` files
Command line can contains long arguments (i.e. --filter).
Allow to pass a response file will help these scenario.
I think this should be handled as part of the config file (see #3562 and #3499). I am not sure there is really a need for a filter file.
FWIW I've made a custom implementation for this a long time ago in vstest. Your implementation would be easier because you have neither default arguments, or -- settings.
https://github.com/nohwnd/vstest/blob/commandline-parser/src/vstest.console/CommandLine/Parser.cs#L536
I think this should be handled as part of the config file (see https://github.com/microsoft/testfx/issues/3562 and https://github.com/microsoft/testfx/issues/3499). I am not sure there is really a need for a filter file.
What you mean, the response file will contains all the command line not only the filter. Or have I misunderstood?
What you mean, the response file will contains all the command line not only the filter. Or have I misunderstood?
Is this not what I suggested in #3499 ?
Is this not what I suggested in https://github.com/microsoft/testfx/issues/3499 ?
This feature is slightly different. It used when the command line for some reason is really log and cannot fit the max length of the command line. The feature discussed in the other issue doesn't fit well the "on the fly" generation, because users should parse json and rewrite a new one. Here it's simply a generation of plain command line with one option per line.
This is a key feature to unblock the --filterByIds "long list of ids" that is used in some tooling to partition or select specific tests.