Jean-Jacques Lafay
Jean-Jacques Lafay
Hard-coded 'specflow.json' name doesn't allow different configurations for different test assemblies
> Why do you put multiple test assemblies in the same folder? As I said : > to avoid wasting disk space, and also because there are runtime dependencies (plugins)...
Hard-coded 'specflow.json' name doesn't allow different configurations for different test assemblies
Indeed, I had taken a look at the code (to convince myself that I had not overlooked a way to specify the configuration file). I will possibly give it a...
Hard-coded 'specflow.json' name doesn't allow different configurations for different test assemblies
By the way, .NET Core *does* somewhat support `app.config`, but I fully agree that the additional dependency to the [corresponding package](https://www.nuget.org/packages/system.configuration.configurationmanager/) is something we'd much rather avoid.
Hard-coded 'specflow.json' name doesn't allow different configurations for different test assemblies
Hello @gabidabet, Not solved. But for now we don't *run* .NET Core tests, so we can still live with the `app.config` files. We also need configuration for the live-doc generation,...
Hard-coded 'specflow.json' name doesn't allow different configurations for different test assemblies
@gasparnagy > @lanfeust69 Could you please give some details about which configuration settings you would like to specify in the `specflow.json` so that we can find some other suggestions? I...
@augustoproiete : thanks for the additional insights. I didn't have the time to dig things deeper and come up with a PR, and that's why I opened the issue in...
It used to work with version 0.22, where http.proxy would be picked up. Might depend on the proxy authentication scheme to actually work.
> Nice work! BTW one of the more complex things I had punted on in my POC was handling resources. From my conversations with @alexcrichton those significantly changed the Rust...
@alexcrichton : Thanks for a very quick first look ! I personally prefer sizeable PR broken down through meaningful commits (because of the logical coupling, an oversight in an earlier...
> > Not sure if a function only used with some features should be marked `#[allow(dead_code)]` (which may miss the time it is no longer used) or `#[cfg(any(feature = "feature1",...