New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
shared.config.browser_name naming? #452
Comments
why browser_name is bad? |
It's not bad... But it becomes irrelevant when we for example use remote driver... Question is - can we choose a name that can be used in more cases... |
What about driver_name? Covers both: "chrome" and "remote" |
yeap... might be a good option to consider... |
As I now see, in context of #406, I might add something like config.options ... (though I was against this idea before...)... After that, we will decide on the fate of browser_name... |
In general, we don't just need to count the remote context but also the appium context. Probably we should peak the name that will be compliant fully with mobile automation. Maybe we even can allow to set Currently in master, while preparing Release Candidate 1, it's named as config.name. So we probably have to decide betwean:
To make the decision, we should:
Some arguments for config.driver_name
some examples:
Some arguments for config.name:
some examples:
|
consider renaming to... config.name? config.executor?
seems like renaming to config.name is a bad idea,
then element.config.name would be irrelevant
element.config.executor - yet might be ok...
but should not then executor accept and remote url of the hub?
The text was updated successfully, but these errors were encountered: