Current Dev State

static/js/ketcher2/node_modules/webdriverio/docs/guide/getstarted/boilerplate.md

@@ -0,0 +1,78 @@
+name: boilerplate
+category: getstarted
+tags: guide
+index: 2
+title: WebdriverIO - Boilerplate Projects
+---
+
+# Boilerplate Projects
+
+Over the time our community has developed a bunch of boilerplate projects that can be used as inspiration to set up the own test suite.
+
+## [webdriverio/cucumber-boilerplate](https://github.com/webdriverio/cucumber-boilerplate)
+
+Our very own boilerplate for Cucumber test suites. We created over 150 predefined step definitions for you so that you can start write feature files for your project right away.
+
+- Framework: Cucumber
+- Features:
+    - over 150 predefined steps that cover almost everything you need
+    - integration of WebdriverIO's Multiremote functionality
+    - own demo app
+
+## [saucelabs-sample-test-frameworks/JS-Mocha-WebdriverIO-Selenium](https://github.com/saucelabs-sample-test-frameworks/JS-Mocha-WebdriverIO-Selenium)
+
+Simple boilerplate project that runs multiple browser on [SauceLabs](https://saucelabs.com/) in parallel.
+
+- Framework: Mocha
+- Features:
+    - Page Object usage
+    - Integration with [SauceLabs](https://saucelabs.com/)
+
+## [jonyet/webdriverio-boilerplate](https://github.com/jonyet/webdriverio-boilerplate)
+
+Designed to be quick to get you started without getting terribly complex, as well as to share examples of how one can leverage external node modules to work in conjunction with wdio specs.
+
+- Framework: Mocha
+- Features:
+    - examples for using Visual Regression testing with WebdriverIO v4
+    - cloud integration with [BrowserStack](https://www.browserstack.com/)
+    - Page Objects usage
+
+## [cognitom/webdriverio-examples](https://github.com/cognitom/webdriverio-examples)
+
+Project with various examples to setup WebdriverIO with an internal grid and PhantomJS or using cloud services like [TestingBot](https://testingbot.com/).
+
+- Framework: Mocha
+- Features:
+    - examples for the tunneling feature from TestingBot
+    - standalone examples
+    - simple demonstration of how to integrate PhantomJS as a service so no that no Java is required
+
+## [michaelguild13/Selenium-WebdriverIO-Mocha-Chai-Sinon-Boilerplate](https://github.com/michaelguild13/Selenium-WebdriverIO-Mocha-Chai-Sinon-Boilerplate)
+
+Enhance testing stack demonstration with Mocha and Chai allows you to write simple assertion using the [Chai](http://chaijs.com/) assertion library.
+
+- Framework: Mocha
+- Features:
+    - Chai integration
+    - Babel setup
+
+## [dcypherthis/wdio-boilerplate-cucumber](https://github.com/dcypherthis/wdio-boilerplate-cucumber)
+
+This project is an example of how to get started with WebdriverIO for Selenium testing in Node.js. It makes use of the Cucumber BDD framework and works with dot, junit, and allure reporters. It is ES6 friendly (via babel-register) and uses Grunt to manage tasks.
+
+- Framework: Cucumber
+- Features:
+    - detailed documentation
+    - runs tests in a [Docker](https://www.docker.com/) container
+    - Babel setup
+
+## [WillLuce/WebdriverIO_Typescript](https://github.com/WillLuce/WebdriverIO_Typescript)
+
+This directory contains the WebdriverIO page object example written using TypeScript.
+
+- Framework: Mocha
+- Features:
+    - examples of Page Object Model implemenetation
+    - Intellisence
+

static/js/ketcher2/node_modules/webdriverio/docs/guide/getstarted/configuration.md

@@ -0,0 +1,274 @@
+name: configuration
+category: getstarted
+tags: guide
+index: 1
+title: WebdriverIO - Configuration
+---
+
+# Configuration
+
+If you create a WebdriverIO instance, you need to define some options in order to set the proper
+capabilities and settings. When calling the `remote` method like:
+
+```js
+var webdriverio = require('webdriverio');
+var client = webdriverio.remote(options);
+```
+
+you need to pass in an options object to define your Webdriver instance. Note that this is only necessary if you run WebdriverIO as a standalone package. If you are using the wdio test runner, these options belong in your `wdio.conf.js` configuration file. The following options can be defined:
+
+### desiredCapabilities
+Defines the capabilities you want to run in your Selenium session. See the [Selenium documentation](https://github.com/SeleniumHQ/selenium/wiki/DesiredCapabilities)
+for a list of the available `capabilities`. Also useful is Sauce Labs [Automated Test Configurator](https://wiki.saucelabs.com/display/DOCS/Platform+Configurator#/)
+that helps you to create this object by clicking together your desired capabilities.
+
+Refer to the [cloud service docs](/guide/usage/cloudservices.html) for further
+service specific options.
+
+Type: `Object`<br>
+Default: `{ browserName: 'firefox' }`<br>
+
+**Example:**
+
+```js
+browserName: 'chrome',    // options: `firefox`, `chrome`, `opera`, `safari`
+version: '27.0',          // browser version
+platform: 'XP',           // OS platform
+tags: ['tag1','tag2'],    // specify some tags (e.g. if you use Sauce Labs)
+name: 'my test'           // set name for test (e.g. if you use Sauce Labs)
+pageLoadStrategy: 'eager' // strategy for page load
+```
+
+**Details:**
+
+`pageLoadStrategy` is implemented in Selenium [2.46.0](https://github.com/SeleniumHQ/selenium/blob/master/java/CHANGELOG#L494), and apparently, it is only working on Firefox. The valid values are:
+
+ `normal` - waits for `document.readyState` to be 'complete'. This value is used by default.<br>
+ `eager`  - will abort the wait when `document.readyState` is 'interactive' instead of waiting for 'complete'.<br>
+ `none`   - will abort the wait immediately, without waiting for any of the page to load.
+
+### logLevel
+Level of logging verbosity.
+
+__verbose:__ everything gets logged<br>
+__silent:__ nothing gets logged<br>
+__command:__ url to Selenium server gets logged (e.g. `[15:28:00]  COMMAND     GET      "/wd/hub/session/dddef9eb-82a9-4f6c-ab5e-e5934aecc32a/title"`)<br>
+__data:__ payload of the request gets logged (e.g. `[15:28:00]  DATA                {}`)<br>
+__result:__ result from the Selenium server gets logged (e.g. `[15:28:00]  RESULT              "Google"`)
+
+Type: `String`<br>
+Default: *silent*<br>
+Options: *verbose* | *silent* | *command* | *data* | *result*
+
+### logOutput
+Pipe WebdriverIO logs into a file. You can either define a directory, and WebdriverIO generates a filename for the log file
+or you can pass in a writeable stream, and everything gets redirected to that (last one doesn't work yet with the wdio runner).
+
+Type: `String|writeable stream`<br>
+Default: *null*
+
+### protocol
+Protocol to use when communicating with the Selenium standalone server (or driver).
+
+Type: `String`<br>
+Default: *http*
+
+### host
+Host of your WebDriver server.
+
+Type: `String`<br>
+Default: *127.0.0.1*
+
+### port
+Port your WebDriver server is on.
+
+Type: `Number`<br>
+Default: *4444*
+
+### path
+Path to WebDriver server.
+
+Type: `String`<br>
+Default: */wd/hub*
+
+### baseUrl
+Shorten `url` command calls by setting a base url. If your `url` parameter starts with `/`, the base url gets prepended.
+
+Type: `String`<br>
+Default: *null*
+
+### connectionRetryTimeout
+Timeout for any request to the Selenium server
+
+Type: `Number`<br>
+Default: *90000*
+
+### connectionRetryCount
+Count of request retries to the Selenium server
+
+Type: `Number`<br>
+Default: *3*
+
+### coloredLogs
+Enables colors for log output
+
+Type: `Boolean`<br>
+Default: *true*
+
+### bail
+If you only want to run your tests until a specific amount of tests have failed use bail (default is 0 - don't bail, run all tests).
+
+Type: `Number`<br>
+Default: *0* (don't bail, run all tests)
+
+### screenshotPath
+Saves a screenshot to a given path if the Selenium driver crashes
+
+Type: `String`|`null`<br>
+Default: *null*
+
+### screenshotOnReject
+Attaches a screenshot of a current page to the error if the Selenium driver crashes.
+Can be specified as object to set the timeout and count of retries on the attempt to take screenshot.
+
+Type: `Boolean`|`Object`<br>
+Default: *false*
+
+**Note**: Attaching screenshot to the error uses extra time to get screenshot and extra memory to store it. So for the sake of performance it is disabled by default.
+
+**Example:**
+
+```js
+// take screenshot on reject
+screenshotOnReject: true
+
+// take screenshot on reject and set some options
+screenshotOnReject: {
+    connectionRetryTimeout: 30000,
+    connectionRetryCount: 0
+}
+```
+
+### waitforTimeout
+Default timeout for all waitForXXX commands. Note the lowercase `f`.
+
+Type: `Number`<br>
+Default: *1000*
+
+### waitforInterval
+Default interval for all waitForXXX commands.
+
+Type: `Number`<br>
+Default: *500*
+
+### queryParams
+A key-value store of query parameters to be added to every selenium request.
+Type: `Object`<br>
+Default: None
+
+**Example:**
+
+```js
+queryParams: {
+  specialKey: 'd2ViZHJpdmVyaW8='
+}
+
+// Selenium request would look like:
+// http://127.0.0.1:4444/v1/session/a4ef025c69524902b77af5339017fd44/window/current/size?specialKey=d2ViZHJpdmVyaW8%3D
+```
+
+## debug
+
+Enables node debugging
+
+Type: `Boolean`<br>
+Default: *false*
+
+## execArgv
+Node arguments to specify when launching child processes
+
+Type: `Array of String`<br>
+Default: *null*
+
+## Setup [Babel](https://babeljs.io/) to write tests using next generation JavaScript
+
+**Note: these instructions are for Babel 6.  Using Babel 5 is not recommended.**
+
+First, install babel dependencies:
+```
+npm install --save-dev babel-register babel-preset-es2015
+```
+
+There are multiple ways to setup Babel using the wdio testrunner. If you are running Cucumber or Jasmine tests, you just need
+to register Babel in the before hook of your config file
+
+```js
+    before: function() {
+        require('babel-register');
+    },
+```
+
+If you run Mocha tests, you can use Mocha's internal compiler to register Babel, e.g.:
+
+```js
+    mochaOpts: {
+        ui: 'bdd',
+        compilers: ['js:babel-register'],
+        require: ['./test/helpers/common.js']
+    },
+```
+
+### `.babelrc` settings
+
+Using `babel-polyfill` is not recommended with `webdriverio`; if you need such features, use [`babel-runtime`](https://babeljs.io/docs/plugins/transform-runtime/) instead by running
+```
+npm install --save-dev babel-plugin-transform-runtime babel-runtime
+```
+and including the following in your `.babelrc`:
+```json
+{
+  "presets": ["es2015"],
+  "plugins": [
+    ["transform-runtime", {
+      "polyfill": false
+    }]
+  ]
+}
+```
+
+Instead of `babel-preset-es2015`, you may use `babel-preset-es2015-nodeX`, where `X` is your Node major version, to avoid unnecessary polyfills like generators:
+```
+npm install --save-dev babel-preset-es2015-node6
+```
+```json
+{
+  "presets": ["es2015-node6"],
+  "plugins": [
+    ["transform-runtime", {
+      "polyfill": false,
+      "regenerator": false
+    }]
+  ]
+}
+```
+
+## Setup [TypeScript](http://www.typescriptlang.org/)
+
+Similar to Babel setup, you can register TypeScript to compile your .ts files in your before hook of your config file.
+You will need [ts-node](https://github.com/TypeStrong/ts-node) as an installed devDependency.
+
+```js
+    before(function() {
+        require('ts-node/register');
+    }),
+```
+
+Similarly for mocha:
+
+```js
+    mochaOpts: {
+        ui: 'bdd',
+        compilers: ['ts:ts-node/register'],
+        requires: ['./test/helpers/common.js']
+    },
+```

static/js/ketcher2/node_modules/webdriverio/docs/guide/getstarted/install.md

@@ -0,0 +1,55 @@
+name: install
+category: getstarted
+tags: guide
+index: 0
+title: WebdriverIO - Install
+---
+
+# Install
+
+You will need to have [Node.js](http://nodejs.org/) and [NPM](https://www.npmjs.org/) installed on your machine. Check out their project websites for more instructions. If you want to have WebdriverIO integrated into your test suite, then install it locally with:
+
+```sh
+$ npm install webdriverio --save-dev
+```
+
+The test runner is called `wdio` and should be available after the install was successful:
+
+```sh
+$ ./node_modules/.bin/wdio --help
+```
+
+You can also install the package globally on your machine and use the `wdio` directly from the command line. However it is recommended to install it per project.
+
+## Set up your Selenium environment
+
+There are two ways of setting up your Selenium environment: as a standalone package or by installing the
+server and browser driver separately.
+
+### Use of existing standalone package
+
+The simplest way to get started is to use one of the NPM selenium standalone
+packages like: [vvo/selenium-standalone](https://github.com/vvo/selenium-standalone). After installing
+it (globally) you can run your server by executing:
+
+```sh
+$  selenium-standalone start
+```
+
+If you are using the wdio testrunner you might be interested in the [Selenium Standalone Service](/guide/services/selenium-standalone.html) that starts the server for you everytime before the test starts.
+
+You can also run the selenium server separately from your test setup. To do so you need to get the newest version of the selenium standalone server [here](http://docs.seleniumhq.org/download/). Just download the jar file somewhere on your system. After that start your terminal and execute the file via
+
+```sh
+$ java -jar /your/download/directory/selenium-server-standalone-3.0.1.jar
+```
+
+With the latest version of Selenium most of the drivers for the browser come with an external driver that has to be downloaded and setup.
+
+## Setup Chrome
+
+The [Chromedriver](https://sites.google.com/a/chromium.org/chromedriver/home) is a standalone server which implements WebDriver's wire protocol for Chromium. It is being developed by members of the Chromium and WebDriver team. For running Chrome browser tests on your local machine you need to download ChromeDriver from the project website and make it available on your machine by setting the `PATH` to the ChromeDriver executable.
+
+## Setup Firefox
+
+The same applies for Firefox. It is driven by the GeckoDriver that translates calls into the [Marionette](https://developer.mozilla.org/en-US/docs/Mozilla/QA/Marionette) automation protocol. To run tests on Firefox with Selenium standalone server v3 or newer you also need to download the latest driver [here](https://github.com/mozilla/geckodriver/releases) and make it available in the `PATH` of your machine.

static/js/ketcher2/node_modules/webdriverio/docs/guide/getstarted/modes.md

@@ -0,0 +1,53 @@
+name: modes
+category: getstarted
+tags: guide
+index: 3
+title: WebdriverIO - How to use WebdriverIO
+---
+
+# How to use WebdriverIO
+
+WebdriverIO can be used for various purposes. It implements the Webdriver protocol API and can run browser in an automated way. The framework is designed to work in any arbitrary environment and for any kind of task. It is independent from any 3rd party frameworks and only requires Node.js to run.
+
+### Standalone Mode
+
+The probably simplest form to run WebdriverIO is in standalone mode. This has nothing to do with the Selenium server file which is usually called `selenium-server-standalone`. It basically just means that you require the `webdriverio` package in your project and use the API behind it to run your automation. Here is a simple example:
+
+```js
+var webdriverio = require('webdriverio');
+var options = { desiredCapabilities: { browserName: 'chrome' } };
+var client = webdriverio.remote(options);
+
+client
+    .init()
+    .url('https://duckduckgo.com/')
+    .setValue('#search_form_input_homepage', 'WebdriverIO')
+    .click('#search_button_homepage')
+    .getTitle().then(function(title) {
+        console.log('Title is: ' + title);
+        // outputs: "Title is: WebdriverIO (Software) at DuckDuckGo"
+    })
+    .end();
+```
+
+Using WebdriverIO in standalone mode allows you to integrate this automation tool in your own (test) project to create a new automation library. Popular examples of that are [Chimp](https://chimp.readme.io/) or [CodeceptJS](http://codecept.io/). You can also write plain Node scripts to scrape the World Wide Web for content or anything else where a running browser is required.
+
+### The WDIO Testrunner
+
+The main purpose of WebdriverIO though is end to end testing on big scale. We therefore implemented a test runner that helps you to build a reliable test suite that is easy to read and maintain. The test runner takes care of many problems you are usually facing when working with plain automation libraries. For one it organizes your test runs and splits up test specs so your tests can be executed with maximum concurrency. It also handles session management and provides a lot of features that help you to debug problems and find errors in your tests. Here is an same example from above written as test spec and executed by wdio:
+
+```js
+describe('DuckDuckGo search', function() {
+    it('searches for WebdriverIO', function() {
+        browser.url('https://duckduckgo.com/');
+        browser.setValue('#search_form_input_homepage', 'WebdriverIO');
+        browser.click('#search_button_homepage');
+
+        var title = browser.getTitle();
+        console.log('Title is: ' + title);
+        // outputs: "Title is: WebdriverIO (Software) at DuckDuckGo"
+    });
+});
+```
+
+The test runner is an abstraction of popular test frameworks like Mocha, Jasmine or Cucumber. Different than using the standalone mode all commands that get executed by the wdio test runner are synchronous. That means that you don't use promises anymore to handle async code. To run your tests using the wdio test runner check out the [Getting Started](/guide/testrunner/gettingstarted.html) section for more information.

static/js/ketcher2/node_modules/webdriverio/docs/guide/getstarted/upgrade.md

@@ -0,0 +1,43 @@
+name: upgrade
+category: getstarted
+tags: guide
+index: 5
+title: WebdriverIO - How to upgrade from v3 to v4
+---
+
+How to upgrade from v3 to v4
+============================
+
+If you have already written tons of tests using v3 but you want to upgrade to v4 then you have two opportunities:
+
+1. You can simply update to v4 and continue to run your tests asynchronous. To do so make sure to set the `sync` property in your `wdio.conf.js` to `false`. Note that in v4 wdio splits up the test specs and starts one session per capability per spec file. If you run your tests in the cloud make sure to limit this behavior (using [`maxInstances`](https://github.com/webdriverio/webdriverio/blob/master/examples/wdio.conf.js#L52-L60)) before you exceed the concurrency limit.
+2. If you want to transform your test specs from asynchronous behavior using promises to synchronous but don't have time to rewrite your whole suite, you can run some specs asynchronous and some synchronous. First of all you need to set all spec function to run asynchronous. You can do that by giving each test block (e.g. `it` in Mochas BDD testing) or step definition the function name `async`:
+
+```js
+describe('some feature', function () {
+    // ...
+    it('I am an old test running asynchronous', function async () {
+        return browser
+            .url('...')
+            .click('button=some button')
+            .getText('.myElem').then(function (text) {
+                expect(text).to.be.equal('some text');
+            })
+    });
+
+    it('I am a new test running synchronous', function () {
+        browser.url('...');
+
+        var button = browser.element('.myButton');
+        button.click();
+
+        expect(browser.getText('label')).to.be.equal('some text');
+    });
+});
+```
+
+This way old and new tests can coexist and you can move your old test time after time to the new synchronous way of writing specs.
+
+Also make sure to add the desired framework adapters to your dependencies. In v4 all frameworks as well as reporters live as own adapter packages on NPM and need to be additionally installed. Besides the spec reporter (will be published later too) we were able to port all frameworks and reporter into own packages.
+
+Nevertheless an upgrade from v3 to v4 can lead to break your build even though you've configured everything properly. We can not guarantee that one of the steps above work for you. The worst case is that you have to stick to v3 or rewrite everything.

static/js/ketcher2/node_modules/webdriverio/docs/guide/getstarted/v4.md

@@ -0,0 +1,55 @@
+name: v4
+category: getstarted
+tags: guide
+index: 4
+title: WebdriverIO - What's new in WebdriverIO?
+---
+
+# What's new in WebdriverIO v4?
+
+History has proven to us: no major version change without rewriting the whole code base. This time we have rewritten everything into ES2016 conforming JavaScript and we use Babel now to compile the code before pushing it to NPM. This allows us not only to specify a project wide code style using `ESLint`, it also sets an important milestone for the future development of WebdriverIO. One of the next big changes compared to v3 is that we split up the codebase into multiple packages. That means that all reporters and framework adaptations  have to be installed separately. Note: if you have installed WebdriverIO globally you also need to install these extra packages globally. The schema of the new package system is as follows:
+
+#### Framework Adaptations
+- example plugins: [wdio-mocha-framework](https://github.com/webdriverio/wdio-mocha-framework), [wdio-jasmine-framework](https://github.com/webdriverio/wdio-jasmine-framework), [wdio-cucumber-framework](https://github.com/webdriverio/wdio-cucumber-framework)
+- use naming convention is `wdio-*-framework`
+- use NPM keywords wdio-plugin, wdio-framework
+
+#### Reporters
+- example plugins: [wdio-dot-reporter](https://github.com/webdriverio/wdio-dot-reporter), [wdio-junit-reporter](https://github.com/webdriverio/wdio-junit-reporter), [wdio-allure-reporter](https://github.com/webdriverio/wdio-allure-reporter)
+- use naming convention is `wdio-*-reporter`
+- use NPM keywords wdio-plugin, wdio-reporter
+
+#### Services
+- example services: [wdio-sauce-service](https://github.com/webdriverio/wdio-sauce-service)
+- use naming convention is `wdio-*-service`
+- use NPM keywords wdio-plugin, wdio-service
+
+We really appreciate every new plugin that gets developed and may help other people to run better tests. If you have created such a plugin make sure to create a pull request to our [configuration utility](https://github.com/webdriverio/webdriverio/blob/master/lib/cli.js#L13-L33) so your package will be suggested if someone runs the wdio configurator.
+
+### It's all synchronous
+
+One of the probably biggest changes is the way WebdriverIO handles async in the wdio testrunner now. Many developers that moved away from Java to run their e2e tests in Node.js struggled with async handling of commands in their test suites. Also beginners had to learn the concept of promises to properly build up reliable tests. This is now over. All commands now block the execution of the test process until they've resolved. No `then` calls have to be done anymore, we can just assign the direct response of the Selenium server to a variable, like:
+
+```js
+describe('webdriver.io page', function() {
+    it('should have the right title', function () {
+        browser.url('/');
+        var title = browser.getTitle();
+        assert.equal(title, 'WebdriverIO - WebDriver bindings for Node.js');
+    });
+});
+```
+
+WebdriverIO uses the popular [Fibers](https://www.npmjs.com/package/fibers) package which is a Node.js plugin and compatible with all operating systems and various Node.js versions. It is also used by other big projects like [Meteor](https://www.meteor.com/) and is pretty stable and in active development. If you have used generators in v3 you can easily upgrade to v4 by removing the asterisks in your spec definitions as well as all `yield` words in your tests (there is no support for generators in v4 anymore).
+
+### New concept of services
+
+One really exciting new feature is the concept of services. These are little add-ons that help you to simplify tests, manage your test suite and integrate results with all kinds of 3rd party integrations. As a showcase service we created the package `wdio-sauce-service` which is a service for running tests on Sauce Labs. Of course, you can run tests using Sauce without that service but using the package reduces overhead and makes the setup way easier. For example, it updates the job status automatically and comes with a [Sauce Connect](https://wiki.saucelabs.com/display/DOCS/Sauce+Connect) integration to securely run your local tests in the cloud. We hope that the community is building a lot more services and 3rd party integrations.
+
+### Reliable test execution through retry mechanisms
+
+It's a known issue that e2e tests are fragile and not always reliable. It's the job of WebdriverIO to tackle this problem and prevent flakes from happening. An annoying and common error is the so called stale element reference error in Selenium where the element you are requesting got re-rendered causing the driver to lose its connection to it. These errors used to happen in random locations in your tests suite and there was almost no way to prevent them. In v4 we have now implemented a retry mechanism that checks for that error and automatically reruns the command for you. This mechanism can also be used to prevent other common problems from happening and will be improved with the next couple of versions. It also appears that some users faced connection issues in their internal grid system. This is now also handled by WebdriverIO which as of v4 will automatically retry all failing requests to the Selenium server.
+
+### Hook me up!
+
+Hooks are an important instrument to get information about the running test process. In the new version we introduced a lot of new hooks that allow you to interfere with the test at any time. You can make async requests to 3rd party tools as well as log certain states to get a better overview about the system you are testing. These are all of the new hooks that were implemented: `beforeSession`, `beforeSuite`, `beforeHook`, `beforeTest`, `beforeCommand`, `afterCommand`, `afterTest`, `afterHook`, `afterSuite`, `afterSession`, `onError` and for Cucumber tests: `beforeFeature`, `beforeScenario`, `beforeStep`, `afterFeature`, `afterScenario`, `afterStep`. Each of these hooks will wait to continue with the test process until synchronous WebdriverIO commands have finished or the returning promise has been resolved.