.config.example.yml

# The standard place to add your features and step_definitions is in a folder
# named 'features' at the root of the project. However if you'd like to name
# this folder something else, you can tell Quke what the new name is here.
# The default is features
features_folder: 'cukes'

# Normally Capybara expects to be testing an in-process Rack application, but
# we're using it to talk to a remote host. Users of Quke can set what this
# will be by simply setting `app_host`. You can then use it directly using
# Capybara `visit('/Main_Page')` or `visit('/')` rather than having to repeat
# the full url each time
app_host: 'https://en.wikipedia.org/wiki'

# Tells Quke which browser to use for testing. Choices are firefox, chrome, and
# browserstack, with the default being chrome
driver: chrome

# Let Quke know you want to run the browser in headless mode. Headless mode
# means the browser still runs but you won't see it displayed. The benefit is
# that your tests will take less time as it's less resource intensive.
headless: true

# Add a pause (in seconds) between steps so you can visually track how the
# browser is responding. Only useful if using a non-headless browser. The
# default is 0
pause: 1

# Specify whether Quke should stop all tests once an error occurs. Useful in
# Continuous Integration (CI) environments where a quick Yes/No is preferable to
# a detailed response. By default Quke sets this to false if not set in the
# config.
stop_on_error: true

# By default Quke will display web pages where a failure has taken place.
# A copy of the html is saved and Quke will display it in your default browser.
# This can be useful to diagnose why something has failed, but there are times
# you may not want Quke to do this.
display_failures: false

# Capybara will attempt to find an element for a period of time, rather than
# immediately failing because the element cannot be found. This defaults to 2
# seconds. However if the site you are working with is slow or features
# elements that take some time to load you can increase this default.
max_wait_time: 5

# Tell the driver Quke is using to send a different user-agent value to the site
# under test. Useful if you want the underlying driver to spoof what kind of
# browser the request is coming from. For example you may want to pretend to be
# a mobile browser so you can check what you get back versus the desktop
# version. Or you want to pretend to be another kind of browser, because the one
# you have is not supported by the site.
user_agent: "Mozilla/5.0 (MSIE 10.0; Windows NT 6.1; Trident/5.0)"

# If set Quke will tell Cucumber to output to the console using its
# 'progress' formatter (simply displays a . for each passing scenario and F for
# each failing one), rather than the default 'pretty' which displays each
# scenario in detail.
# If you don't need to see the detail on each run, this might be easier to
# follow than the detailed output you see using the default 'pretty' print
# format.
print_progress: false

# Anything you place under the 'custom' node in the `.config.yml` file will be
# available within your steps and page objects by calling
# `Quke::Quke.config.custom`. So using the example below we could access its
# values in the following ways
#
# Quke::Quke.config.custom["default_org_name"] # = "Testy Ltd"
# Quke::Quke.config.custom["accounts"]["account2"]["username"] # = "john.doe@example.gov.uk"
# Quke::Quke.config.custom["urls"]["front_office"] # = "http://myservice.service.gov.uk"
#
# As long as what you add is valid YAML (check with a tool like
# http://www.yamllint.com/) Quke will be able to pick it up and make it
# available in your tests.
custom:
  default_org_name: "Testy Ltd"
  accounts:
    account1:
      username: jane.doe@example.gov.uk
      password: Av3rystr*ngone
    account2:
      username: john.doe@example.gov.uk
      password: An*th3rstrongone
  urls:
    front_office: "http://myservice.service.gov.uk"
    back_office: "http://admin-myservice.service.gov.uk"

# If you are running Quke behind a proxy you can configure the proxy details
# here. You'll need either the hostname or IP of the proxy server (don't include
# the http:// bit) and the port number (typically 8080). Currently proxy
# settings will only be applied if you are using the Chrome or Firefox drivers.
proxy:
  host: '10.10.2.70'
  port: 8080
  # In some cases you may also need to tell the browser (driver) not to use the
  # proxy for local or specific connections. For this simply provide a comma
  # separated list of addresses.
  no_proxy: '127.0.0.1,192.168.0.1'

# If you select the browserstack driver, there are a number of options you
# can pass through to setup your browserstack tests, username and auth_key
# being the critical ones.
# Please see https://www.browserstack.com/automate/capabilities for more details
browserstack:
  # To run your tests with browserstack you must provide a username and auth_key
  # as a minimum.
  # If you don't want to put these credentials in the config file (because you
  # want to commit it to source control), Quke will also check for the existance
  # of the environment variables BROWSERSTACK_USERNAME and BROWSERSTACK_AUTH_KEY
  username: jdoe
  auth_key: 123456789ABCDE

  # If you want to use local testing you must provide a key. You can find this
  # in Browserstack once logged in under settings. Its typically the same value
  # as the auth_key above.
  # If you don't want to put this credential in the config file (because you
  # want to commit it to source control), Quke will also check for the existance
  # of the environment variable BROWSERSTACK_LOCAL_KEY
  local_key: 123456789ABCDE

  # Anything set under capabilities will be passed directly by Quke to
  # browserstack as means of configuring the test.
  # So the config keys (e.g. build, project, name) you set should match a real
  # browserstack capability, and the value exist in the range it expects. See
  # for further reference on browserstack capabilities
  # https://www.browserstack.com/automate/capabilities
  # https://www.browserstack.com/automate/ruby#configure-capabilities
  capabilities:
    # Keep track of all your automated tests using the build and project
    # capabilities. Group your tests into builds, and builds further into
    # projects
    project: 'Adding browserstack support'
    build: 'Version 1'
    # Allows you to specify an identifier for the test run.
    # If you intend to repeat a test this might not be that applicable, but in
    # the case of one off tests it might be useful
    name: 'Testing google search'

    # To avoid invalid certificate errors while testing set acceptSslCerts to
    # true. This is not listed on the general capabilities page but is here
    # https://www.browserstack.com/automate/ruby#self-signed-certificates
    acceptSslCerts: true
    # Required if you want to generate screenshots at various steps in your test
    # test. Browserstack default is false
    browserstack.debug: true
    # Required if you want to enable video recording during your test.
    # Browserstack default is true
    browserstack.video: true
    # Required if you need to test a locally hosted (e.g. http://localhost:300)
    # or private internal web site. Browserstack has a feature called local
    # testing that Quke also supports, but to use
    # - Browserstack must be your selected driver
    # - You must have set local_key above
    # - You must this value to true
    browserstack.local: false
    # Another setting not listed, setting the following will prevent any values
    # you pass in, for example when filling in a form, from appearing in the
    # logs. General use case is to prevent passwords being exposed, but beware
    # that all input will be masked in the logs if set.
    browserstack.maskSendKeys: true

    # MOBILE testing and DESKTOP testing are essentially diametric; you set one
    # or the other but not both. Some examples seem to put logic in place to
    # test the options passed in and then set the capabilities accordingly,
    # however Browserstack handles this and has what will happen documented
    # https://www.browserstack.com/automate/capabilities#capabilities-parameter-override
    #
    # MOBILE testing
    # The docs are a little confusing but essentially if you want to test against
    # mobile devices you need to define 1 set of capabilities, and if desktop
    # another
    # -----
    # OS you want to test. Accepted values are MAC, WIN8, XP, WINDOWS, ANY,
    # ANDROID. Browserstack default is ANY
    platform: MAC
    # Browser you want to test. Accepted values firefox, chrome, internet
    # explorer,safari, opera, iPad, iPhone, android. Browserstack default is
    # chrome
    browserName: iPhone
    # Browser version you want to test. See the docs for the full list of
    # available versions. Browserstack default is latest stable version of
    # browser selected
    version: '49'
    # Device you want to test on. See the docs for the full list of available.
    device: 'iPhone 5'
    #
    # DESKTOP testing
    # -----
    # OS you want to test. Accepted values are WINDOWS, OS X. If both OS and
    # platform are set, OS will take precedence
    os: WINDOWS
    # OS version you want to test. Accepted values are
    # Windows: XP, 7, 8, 8.1 and 10
    # OS X: Snow Leopard, Lion, Mountain Lion, Mavericks, Yosemite, El Capitan
    os_version: '8.1'
    # Browser you want to test. Accepted values are Firefox, Safari, IE, Chrome,
    # Opera
    browser: chrome
    # Browser version you want to test. See the docs for the full list of
    # available versions
    browser_version: '49'
    # Set the resolution of VM before beginning of your test.
    # See docs https://www.browserstack.com/automate/capabilities for full list
    # of accepted values, as it is also OS dependent
    resolution: '1024x768'