Contributing

Code

We love pull requests. Here’s a quick guide:

  1. Fork the repo.

  2. Run the tests. We only take pull requests with passing tests, and it’s great
    to know that you have a clean state.

  3. Add a test for your change. Only refactoring and documentation changes
    require no new tests. If you are adding functionality or fixing a bug, we need
    a test!

  4. Make the test pass.

  5. Push to your fork and submit a pull request.

How to run tests

  1. Download the latest Selenium standalone server
    and run it via

    1
    $ java -jar selenium-server-standalone-2.41.0.jar
  2. Make sure you have all the dependencies installed

    1
    $ npm install

also all Bower packages required by our testpage

1
$ cd test/site/www && bower install && cd ../../..
  1. Start a local server that delivers our test page to the browser. We recommend using
    http-server

    1
    2
    $ cd /root/dir/of/webdriverio
    $ http-server -p 8080
  2. Depending on your feature/fix/patch make sure it gets covered by a test.
    To ensure that you can run one of the following commands:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    # if your patch is browser specific
    # (e.g. upload files)
    npm run-script test-desktop
    # if your patch is mobile specific
    # (e.g. flick or swipe tests)
    npm run-script test-mobile
    # if your patch is functional and hasn't something to do with Selenium
    # (e.g. library specific fixes like changes within EventHandler.js)
    npm run-script test-functional

    While developing you can run tests on specific specs by passing another
    environment variable _SPEC, e.g.

    1
    $ _SPEC=test/spec/YOURSPEC.js npm run-script test-desktop

Syntax rules

At this point you’re waiting on us. We like to at least comment on, if not
accept, pull requests within three business days (and, typically, one business
day). We may suggest some changes or improvements or alternatives.

Please pay attention on the following syntax rules:

  • Four spaces, no tabs.
  • No trailing whitespace. Blank lines should not have any space.
  • Prefer &&/|| over and/or.
  • a = b and not a=b.
  • Follow the conventions you see used in the source already.

And in case we didn’t emphasize it enough: we love tests!


Documentation

For convenience and ease of maintenance, our project’s documentation pages are generated partly from markdown files in
the docs/ directory and partly from comments in the source code.

As with code contributions, your first step should be to fork the repo.

Markdown Pages

Pages in the docs/ directory follow a common markdown syntax. In lieu of detailed definitions of this syntax, it’s
easiest to imitate the format in the existing pages. Some page attributes can be defined in a YAML block at the
beginning of each document, terminated with three or more dashes (i.e. a horizontal line in markdown), for example:

1
2
3
4
layout: guide
name: guide
title: WebdriverIO - Developer Guide
---

API Methods

The source code for various API methods is located in the lib/ folder. To find the source of any API method listed
on http://webdriver.io/api.html, you can find the corresponding .js file. For example the
dragAndDrop method is defined in the lib/commands/dragAndDrop.js
file. The documentation for each method is generated from documentation blocks in each file. The syntax relies on
block-level comments (e.g. /** multi-line comment */, comment-tags for the parameters
(e.g. @param {String=} windowHandle the window to change focus to), and code samples contained in example tags,
(e.g. <example>...</example>). As with the markdown pages, it’s easiest to imitate the format of the existing
documents. For example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/**
*
* Get tag name of a DOM-element found by given selector.
*
* <example>
:index.html
<div id="elem">Lorem ipsum</div>
:getTagName.js
client.getTagName('#elem').then(function(tagName) {
console.log(tagName); // outputs: "div"
});
* </example>
*
* @param {String} selector element with requested tag name
* @returns {String|String[]} the element's tag name, as a lowercase string
*
* @uses protocol/elements, protocol/elementIdName
* @type property
*
*/

Here’s a quick cheat-sheet:

  1. Description: The first few lines of the comment are typically used to provide a concise description of the method.

  2. Examples: The <example> block omits asterisks (*) – see above example.

  3. File Names: For examples that reference multiple files, infer the file name in the <example> block by prefixing
    its name with a colon. See :index.html and :getTagName.js in the above example.

  4. Parameters: Parameters should type-hint using curly braces, e.g. {String} or {Number} and may include default
    arguments following and equals sign, e.g. {Number=42}

  5. Type: The @type attribute corresponds to the sections on the API page. Currently in use are action, appium,
    cookie, mobile, property, protocol, state, utility, window. You probably will not ever need to change this.

  6. Returns: Identifies the data type returned and a short description.

When you have completed your updates to the documentation, push to your fork and submit a pull request.