shared.config.browser_name naming?

[yashaka]

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?

[aleksandr-kotlyar]

why browser_name is bad?

[yashaka]

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...

[aleksandr-kotlyar]

What about driver_name? Covers both: "chrome" and "remote"

[yashaka]

yeap... might be a good option to consider...

[yashaka]

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...

[yashaka]

config.browser_name definitely will be deprecated, because conflicts with Mobile context, where the default driver name is Appium, but we still via capabilities can configure betwean actual mobile browser name and native application...

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 config.name = 'Espresso', and this will automatically configure appium driver to connect to first available android mobile device, and so on... We might thing about config.name as driver.name for web context and automationName capability for mobile context.

Currently in master, while preparing Release Candidate 1, it's named as config.name. So we probably have to decide betwean:

1. config.name
2. config.driver_name

To make the decision, we should:

• analyze:
  • automationName section at https://appium.io/docs/en/writing-running-appium/caps/#general-capabilities
    • automationName capabilitiy
    • browserName capability (probably to be set still via config.options as for remote context)
• check config.driver.name property for all contexts (local driver, remote driver, appium espresso driver for app, appium uiautomator 2 driver for app, appium driver for mobile browser)

Some arguments for config.driver_name

• has a driver term, that connects it by meaning with other *driver* named config.* options and separate form other like timeout and base_url

some examples:

from selene import browser

browser.config.timeout = 10  # to not repeat it for each below

chrome = browser.with_(driver_name='chrome', base_url='https://autotest.how')
mobile_chrome = browser.with_(driver_name='Appium', driver_options={'browserName': 'Chrome'}, base_url='https://autotest.how')
mobile_app = browser.with_(driver_name='Espresso', driver_options={'app': '/abs/path/to/my.apk'})

# example may not be correct instead of passed driver_options, that type should be different
# we should create options object, and then update it with capabilities,
# but for simplicity I just passed dict there

Some arguments for config.name:

• seems similar to config.driver_name but more concise and pretty
  • but won't it confuse sometimes?

some examples:

from selene import browser

browser.config.timeout = 10  # to not repeat it for each below

chrome = browser.with_(name='chrome', base_url='https://autotest.how')
mobile_chrome = browser.with_(name='Appium', driver_options={'browserName': 'Chrome'}, base_url='https://autotest.how')
mobile_app = browser.with_(name='Espresso', driver_options={'app': '/abs/path/to/my.apk'})