Closed balrok closed 3 months ago
@balrok Do I correctly understand that the new approach allows users to change the Configuration
on the fly at any moment?
I did the same mistake years ago in Selenide, and I know: users will abuse it.
They will call Configuration.setProperty
before, after and between tests. They will call Configuration.setProperty
with different values in parallel tests etc.
Maybe it's a better approach to allow users create a configuration file, e.g. flyingsaucer.conf
?
Then you can commit such a file in src/main/resources
, and the same configuration will be used in tests and production.
Yes exactly, this was my intent. You are probably right that the feature will get abused. A solution might be to allow overriding properties only once at the beginning and then have it immutable. But I'm not sure if I manage to implement it without adding too much complexity.
I think the feature to commit a src/main/resources-file exists already and maybe it is even enough for my use-case. So I close the PR for now.
Thanks for your feedback: you have a good point :-)
This feature would be helpful for us, so we can make sure that in tests and runtime the config is always the same on all machines without much configuration.