diff --git a/.gitignore b/.gitignore index eba055ecf1e..9b06c7d2f6c 100644 --- a/.gitignore +++ b/.gitignore @@ -74,13 +74,11 @@ package-lock.json .DS_Store website/.sass-cache/ -website/translated_docs website/static/css website/build/ website/yarn.lock website/sidebars.json website/node_modules -website/i18n/* docs/api/**/*.md docs/_*.md diff --git a/website/i18n/de-DE.json b/website/i18n/de-DE.json new file mode 100644 index 00000000000..cd2e1d28b93 --- /dev/null +++ b/website/i18n/de-DE.json @@ -0,0 +1,132 @@ +{ + "_comment": "Diese Datei wurde automatisch generiert von write-translations.js", + "localized-strings": { + "next": "Nächste", + "previous": "Vorheriges", + "tagline": "Next-gen WebDriver Test Framework für Node.js", + "allure-reporter": "Allure Reporter", + "applitools-service": "Applitools Service", + "browserstack-service": "BrowserStack Service", + "concise-reporter": "Concise Reporter", + "devtools-service": "DevTools Service", + "dot-reporter": "Dot Reporter", + "firefox-profile-service": "Firefox Profile Service", + "junit-reporter": "JUnit Reporter", + "sauce-service": "Sauce Service", + "selenium-standalone-service": "Selenium Standalone Service", + "spec-reporter": "Spec Reporter", + "sumologic-reporter": "Sumologic Reporter", + "testingbot-service": "Testingbot Service", + "api": "API Dokumentation", + "api/appium": "Appium", + "api/browser/$": "$", + "api/browser/$$": "$$", + "api/browser/call": "call", + "api/browser/debug": "debug", + "api/browser/deleteCookies": "deleteCookies", + "api/browser/execute": "execute", + "api/browser/executeAsync": "executeAsync", + "api/browser/getCookies": "getCookies", + "api/browser/keys": "keys", + "api/browser/newWindow": "newWindow", + "api/browser/pause": "pause", + "api/browser/reloadSession": "reloadSession", + "api/browser/saveScreenshot": "saveScreenshot", + "api/browser/setCookies": "setCookies", + "api/browser/switchWindow": "switchWindow", + "api/browser/touchAction": "touchAction", + "api/browser/url": "url", + "api/browser/waitUntil": "waitUntil", + "api/element/$": "$", + "api/element/$$": "$$", + "api/element/addValue": "addValue", + "api/element/clearValue": "clearValue", + "api/element/click": "click", + "api/element/doubleClick": "doubleClick", + "api/element/dragAndDrop": "dragAndDrop", + "api/element/getAttribute": "getAttribute", + "api/element/getCSSProperty": "getCSSProperty", + "api/element/getHTML": "getHTML", + "api/element/getLocation": "getLocation", + "api/element/getProperty": "getProperty", + "api/element/getSize": "getSize", + "api/element/getTagName": "getTagName", + "api/element/getText": "getText", + "api/element/getValue": "getValue", + "api/element/isDisplayed": "isDisplayed", + "api/element/isDisplayedInViewport": "isDisplayedInViewport", + "api/element/isEnabled": "isEnabled", + "api/element/isExisting": "isExisting", + "api/element/isFocused": "isFocused", + "api/element/isSelected": "isSelected", + "api/element/moveTo": "moveTo", + "api/element/saveScreenshot": "saveScreenshot", + "api/element/scrollIntoView": "scrollIntoView", + "api/element/selectByAttribute": "selectByAttribute", + "api/element/selectByIndex": "selectByIndex", + "api/element/selectByVisibleText": "selectByVisibleText", + "api/element/setValue": "setValue", + "api/element/touchAction": "touchAction", + "api/element/waitForDisplayed": "waitForDisplayed", + "api/element/waitForEnabled": "waitForEnabled", + "api/element/waitForExist": "waitForExist", + "api/element/waitUntil": "waitUntil", + "api/jsonwp": "JSON Wire Protokoll", + "api/mjsonwp": "Mobile JSON Wire Protokoll", + "api/webdriver": "WebDriver-Protokoll", + "autocompletion": "Autovervollständigung", + "babel": "Babel-Setup", + "boilerplate": "Boilerplate Projekte", + "browserobject": "Das Browser-Objekt", + "clioptions": "WDIO CLI Optionen", + "cloudservices": "Cloud-Dienste Nutzen", + "configurationfile": "Testrunner Konfiguration", + "customcommands": "Benutzerdefinierte Befehle", + "customreporter": "Benutzerdefinierte Reporter", + "customservices": "Benutzerdefinierte Services", + "debugging": "Debugging", + "frameworks": "Frameworks", + "gettingstarted": "Erste Schritte", + "jenkins": "Jenkins Integration", + "multiremote": "Multiremote", + "options": "Optionen", + "organizingsuites": "Organisation von Test-Suite", + "pageobjects": "Page Object Pattern", + "proxy": "Proxy-Setup", + "repl": "REPL-Schnittstelle", + "retry": "Flaky Tests Wiederholen", + "selectors": "Selektoren", + "setuptypes": "Einrichten von WebdriverIO", + "timeouts": "Zeitüberschreitung", + "typescript": "TypeScript-Setup", + "watcher": "Test Dateien Überwachen", + "Guide": "Guide", + "API": "API", + "Help": "Hilfe", + "Blog": "Blog", + "GitHub": "GitHub", + "Introduction": "Einleitung", + "Configuration": "Konfiguration", + "Usage": "Nutzung", + "Testrunner": "Testrunner", + "Reporter": "Reporter", + "Services": "Services", + "browser": "browser", + "element": "Element" + }, + "pages-strings": { + "Watch Talks about WebdriverIO|no description given": "Präsentationen über WebdriverIO", + "The community around WebdriverIO is actively speaking on various user groups or conferences about specific topics around automated testing with WebdriverIO. Check out this talk about [Building Scalable And Stable e2e Test Suites](https://www.youtube.com/watch?v=FHxXMeDh7Co&t=935s) by [@bromann](https://twitter.com/bromann) at SauceCon 2018. There is also a whole [YouTube Channel](https://www.youtube.com/user/medigerati/videos?flow=grid&sort=p&view=0) about different topics around WebdriverIO created by [Kevin Lamping](https://twitter.com/klamping).|no description given": "Die Community rund um WebdriverIO spricht aktiv auf verschiedensten User Meetups oder Konferenzen über bestimmte Themen rund um automatisierte Tests mit WebdriverIO. Sehen Sie sich hier eine Präsentation über [Skalierbare und Stabile E2E Tests mit WebdriverIO] (https://www.youtube.com/watch?v=FHxXMeDh7Co&t=935s) von [@bromann] (https://twitter.com/bromann) von der SauceCon 2018 an. Es gibt auch eine ganzen [YouTube Kanal] (https://www.youtube.com/user/medigerati/videos?flow=grid&sort=p&view=0) über verschiedene Themen rund um WebdriverIO von [Kevin Lamping] (https://twitter.com/klamping).", + "Watch more videos|no description given": "Weitere Videos ansehen", + "Applitools Support|no description given": "Applitools Unterstützung", + "Adding helper functions, or more complicated sets and combinations of existing commands is __simple__ and really __useful__|no description given": "Das Hinzufügen von Hilfsfunktionen, oder komplizierter Sets und Kombinationen der vorhandenen Befehlen ist __einfach__ und sehr __nützlich__", + "Extendable|no description given": "Erweiterbar", + "WebdriverIO has 1st class support for the __WebDriver specification__ as well as to __Appium__ and allows to run tests on desktop and mobile.|no description given": "WebdriverIO unterstützt nicht nur die __WebDriver Spezifikation__ im vollem Umfang, sondern auch __Appium__ zum Ausführen von Tests auf Desktop und Mobilen Endgeräten.", + "Compatible|no description given": "Kompatibilität", + "It implements all Webdriver protocol commands and provides useful integrations with other tools.|no description given": "Es implementiert alle Webdriver-Protokollbefehle und bietet nützliche Integrationen mit anderen Tools.", + "Feature Rich|no description given": "Reich an Funktionen", + "Help Translate|recruit community translators for your project": "Hilf beim Übersetzen", + "Edit this Doc|recruitment message asking to edit the doc source": "Bearbeiten", + "Translate this Doc|recruitment message asking to translate the docs": "Übersetzen" + } +} diff --git a/website/i18n/es-ES.json b/website/i18n/es-ES.json new file mode 100644 index 00000000000..5b753550674 --- /dev/null +++ b/website/i18n/es-ES.json @@ -0,0 +1,136 @@ +{ + "_comment": "This file is auto-generated by write-translations.js", + "localized-strings": { + "next": "Next", + "previous": "Previous", + "tagline": "Next-gen WebDriver test framework for Node.js", + "allure-reporter": "Allure Reporter", + "applitools-service": "Applitools Service", + "browserstack-service": "Browserstack Service", + "concise-reporter": "Concise Reporter", + "devtools-service": "Devtools Service", + "dot-reporter": "Dot Reporter", + "firefox-profile-service": "Firefox Profile Service", + "junit-reporter": "Junit Reporter", + "sauce-service": "Sauce Service", + "selenium-standalone-service": "Selenium Standalone Service", + "spec-reporter": "Spec Reporter", + "sumologic-reporter": "Sumologic Reporter", + "testingbot-service": "Testingbot Service", + "api": "API Docs", + "api/appium": "Appium", + "api/browser/$": "$", + "api/browser/$$": "$$", + "api/browser/call": "call", + "api/browser/debug": "debug", + "api/browser/deleteCookies": "deleteCookies", + "api/browser/execute": "execute", + "api/browser/executeAsync": "executeAsync", + "api/browser/getCookies": "getCookies", + "api/browser/keys": "keys", + "api/browser/newWindow": "newWindow", + "api/browser/pause": "pause", + "api/browser/reloadSession": "reloadSession", + "api/browser/saveScreenshot": "saveScreenshot", + "api/browser/setCookies": "setCookies", + "api/browser/setTimeout": "setTimeout", + "api/browser/switchWindow": "switchWindow", + "api/browser/touchAction": "touchAction", + "api/browser/url": "url", + "api/browser/waitUntil": "waitUntil", + "api/chromium": "Chromium", + "api/element/$": "$", + "api/element/$$": "$$", + "api/element/addValue": "addValue", + "api/element/clearValue": "clearValue", + "api/element/click": "click", + "api/element/doubleClick": "doubleClick", + "api/element/dragAndDrop": "dragAndDrop", + "api/element/getAttribute": "getAttribute", + "api/element/getCSSProperty": "getCSSProperty", + "api/element/getHTML": "getHTML", + "api/element/getLocation": "getLocation", + "api/element/getProperty": "getProperty", + "api/element/getSize": "getSize", + "api/element/getTagName": "getTagName", + "api/element/getText": "getText", + "api/element/getValue": "getValue", + "api/element/isDisplayed": "isDisplayed", + "api/element/isDisplayedInViewport": "isDisplayedInViewport", + "api/element/isEnabled": "isEnabled", + "api/element/isExisting": "isExisting", + "api/element/isFocused": "isFocused", + "api/element/isSelected": "isSelected", + "api/element/moveTo": "moveTo", + "api/element/saveScreenshot": "saveScreenshot", + "api/element/scrollIntoView": "scrollIntoView", + "api/element/selectByAttribute": "selectByAttribute", + "api/element/selectByIndex": "selectByIndex", + "api/element/selectByVisibleText": "selectByVisibleText", + "api/element/setValue": "setValue", + "api/element/touchAction": "touchAction", + "api/element/waitForDisplayed": "waitForDisplayed", + "api/element/waitForEnabled": "waitForEnabled", + "api/element/waitForExist": "waitForExist", + "api/element/waitUntil": "waitUntil", + "api/jsonwp": "JSON Wire Protocol", + "api/mjsonwp": "Mobile JSON Wire Protocol", + "api/saucelabs": "Sauce Labs", + "api/webdriver": "Webdriver Protocol", + "autocompletion": "Autocompletion", + "babel": "Babel Setup", + "boilerplate": "Boilerplate Projects", + "browserobject": "The Browser Object", + "clioptions": "WDIO CLI Options", + "cloudservices": "Using Cloud Services", + "configurationfile": "Testrunner Configuration", + "customcommands": "Custom Commands", + "customreporter": "Custom Reporter", + "customservices": "Custom Services", + "debugging": "Debugging", + "frameworks": "Frameworks", + "gettingstarted": "Getting Started", + "jenkins": "Jenkins Integration", + "multiremote": "Multiremote", + "options": "Options", + "organizingsuites": "Organizing Test Suite", + "pageobjects": "Page Object Pattern", + "proxy": "Proxy Setup", + "repl": "REPL interface", + "retry": "Retry Flaky Tests", + "selectors": "Selectors", + "setuptypes": "How to setup WebdriverIO", + "timeouts": "Timeouts", + "typescript": "TypeScript Setup", + "watcher": "Watch Test Files", + "Guide": "Guide", + "API": "API", + "Help": "Help", + "Blog": "Blog", + "GitHub": "GitHub", + "Introduction": "Introduction", + "Configuration": "Configuration", + "Usage": "Usage", + "Testrunner": "Testrunner", + "Reporter": "Reporter", + "Services": "Services", + "Protocols": "Protocols", + "browser": "browser", + "element": "element" + }, + "pages-strings": { + "Watch Talks about WebdriverIO|no description given": "Watch Talks about WebdriverIO", + "The community around WebdriverIO is actively speaking on various user groups or conferences about specific topics around automated testing with WebdriverIO. Check out this talk about [Building Scalable And Stable e2e Test Suites](https://www.youtube.com/watch?v=FHxXMeDh7Co&t=935s) by [@bromann](https://twitter.com/bromann) at SauceCon 2018. There is also a whole [YouTube Channel](https://www.youtube.com/user/medigerati/videos?flow=grid&sort=p&view=0) about different topics around WebdriverIO created by [Kevin Lamping](https://twitter.com/klamping).|no description given": "The community around WebdriverIO is actively speaking on various user groups or conferences about specific topics around automated testing with WebdriverIO. Check out this talk about [Building Scalable And Stable e2e Test Suites](https://www.youtube.com/watch?v=FHxXMeDh7Co&t=935s) by [@bromann](https://twitter.com/bromann) at SauceCon 2018. There is also a whole [YouTube Channel](https://www.youtube.com/user/medigerati/videos?flow=grid&sort=p&view=0) about different topics around WebdriverIO created by [Kevin Lamping](https://twitter.com/klamping).", + "Watch more videos|no description given": "Watch more videos", + "Applitools Support|no description given": "Applitools Support", + "Adding helper functions, or more complicated sets and combinations of existing commands is __simple__ and really __useful__|no description given": "Adding helper functions, or more complicated sets and combinations of existing commands is __simple__ and really __useful__", + "Extendable|no description given": "Extendable", + "WebdriverIO has 1st class support for the __WebDriver specification__ as well as to __Appium__ and allows to run tests on desktop and mobile.|no description given": "WebdriverIO has 1st class support for the __WebDriver specification__ as well as to __Appium__ and allows to run tests on desktop and mobile.", + "Compatible|no description given": "Compatible", + "It implements all Webdriver protocol commands and provides useful integrations with other tools.|no description given": "It implements all Webdriver protocol commands and provides useful integrations with other tools.", + "Feature Rich|no description given": "Feature Rich", + "Help Translate|recruit community translators for your project": "Help Translate", + "Edit this Doc|recruitment message asking to edit the doc source": "Edit", + "Translate this Doc|recruitment message asking to translate the docs": "Translate" + } +} diff --git a/website/translated_docs/de/API.md b/website/translated_docs/de/API.md new file mode 100644 index 00000000000..2d398abd065 --- /dev/null +++ b/website/translated_docs/de/API.md @@ -0,0 +1,43 @@ +--- +id: api +title: API Dokumentation +--- +Willkommen zur WebdriverIO API Dokumentation. These pages contain reference materials for all implemented selenium bindings and commands. WebdriverIO has all [JSONWire protocol](https://github.com/SeleniumHQ/selenium/wiki/JsonWireProtocol) commands implemented and also supports special bindings for [Appium](http://appium.io). + +> **Note:** These are the docs for the latest version (v5.0.0) of WebdriverIO. If you are still using v4 or older please use the legacy docs website [v4.webdriver.io](http://v4.webdriver.io)! + +## Examples + +Each command documentation usually comes with an example that demonstrates the usage of it using WebdriverIO's testrunner running its commands synchronously. If you run WebdriverIO in standalone mode you still can use all commands but need to make sure that the execution order is handled properly by chaining the commands and resolving the promise chain. So instead of assigning the value directly to a variable, as the wdio testrunner allows it: + +```js +it('can handle commands synchronously', () => { + var value = $('#input').getValue(); + console.log(value); // outputs: some value +}); +``` + +you need return the command promise so it gets resolved properly as well as access the value when the promise got resolve: + +```js +it('handles commands as promises', () =>{ + return $('#input').getValue().then((value) => { + console.log(value); // outputs: some value + }); +}); +``` + +Of course you can use Node.JS latest [async/await](https://github.com/yortus/asyncawait) functionality to bring synchronous syntax into your testflow like: + +```js +it('can handle commands using async/await', async function () { + var value = await $('#input').getValue(); + console.log(value); // outputs: some value +}); +``` + +However it is recommended to use the testrunner to scale up your test suite as it comes with a lot of useful add ons like the [Sauce Service](_sauce-service.md) that helps you to avoid writing a lot of boilerplate code by yourself. + +## Contribute + +If you feel like you have a good example for a command, don't hesitate to open a PR and submit it. Just click on the orange button on the top right with the label *"Improve this doc"*. Make sure you understand the way we write these docs by checking the [Contribute](https://github.com/webdriverio/webdriverio/blob/master/CONTRIBUTING.md) section. \ No newline at end of file diff --git a/website/translated_docs/de/Autocompletion.md b/website/translated_docs/de/Autocompletion.md new file mode 100644 index 00000000000..3c586157236 --- /dev/null +++ b/website/translated_docs/de/Autocompletion.md @@ -0,0 +1,41 @@ +--- +id: autocompletion +title: Autocompletion +--- +If you have been writing program code for a while, you probably like autocompletion. Autocomplete is available out of the box in many code editors. However if autocompletion is required for packages that are not installed in the usual locations or are excluded from indexing for some reasons, these too could be added via configuration changes. + +![Autocompletion](/img/autocompletion/0.png) + +[JSDoc](http://usejsdoc.org/) is used for documenting code. It helps to see more additional details about parameters and their types. + +![Autocompletion](/img/autocompletion/1.png) + +Use standard shortcuts *⇧ + ⌥ + SPACE* on IntelliJ Platform to see available documentation: + +![Autocompletion](/img/autocompletion/2.png) + +So, let's start to consider an example of adding autocompletion to code editors on the IntelliJ Platform like WebStorm. + +### Node.js Core modules as External library + +Open *Settings -> Preferences -> Languages & Frameworks -> JavaScript -> Libraries* + +![Autocompletion](/img/autocompletion/3.png) + +Add new library + +![Autocompletion](/img/autocompletion/4.png) + +Add directory with WebdriverIO commands + +![Autocompletion](/img/autocompletion/5.png) ![Autocompletion](/img/autocompletion/6.png) ![Autocompletion](/img/autocompletion/7.png) + +Enter documentation URL + +![Autocompletion](/img/autocompletion/8.png) ![Autocompletion](/img/autocompletion/9.png) ![Autocompletion](/img/autocompletion/10.png) + +### Using TypeScript community stubs (TypeScript definition files) + +WebStorm provides one more workaround for adding coding assistance. It allows you to download [DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped) stubs. + +![Autocompletion](/img/autocompletion/11.png) ![Autocompletion](/img/autocompletion/12.png) \ No newline at end of file diff --git a/website/translated_docs/de/Babel.md b/website/translated_docs/de/Babel.md new file mode 100644 index 00000000000..064065f97c6 --- /dev/null +++ b/website/translated_docs/de/Babel.md @@ -0,0 +1,40 @@ +--- +id: babel +title: Babel Setup +--- +To write tests using next generation JavaScript features you can add [Babel](https://babeljs.io/) as compiler for your test files. For that first, install the necessary Babel dependencies: + + npm install --save-dev @babel/cli @babel/preset-env @babel/register + + +Make sure your [`babel.config.js`](https://babeljs.io/docs/en/config-files) is configured properly. The simplest setup you can use is: + +```js +module.exports = { + presets: [ + ['@babel/preset-env', { + targets: { + node: 8 + } + }] + ] +} +``` + +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'] +}, +``` \ No newline at end of file diff --git a/website/translated_docs/de/BoilerplateProjects.md b/website/translated_docs/de/BoilerplateProjects.md new file mode 100644 index 00000000000..db8f49faf91 --- /dev/null +++ b/website/translated_docs/de/BoilerplateProjects.md @@ -0,0 +1,160 @@ +--- +id: boilerplate +title: Boilerplate Projects +--- +Over the time our community has developed a bunch of boilerplate projects that can be used as inspiration to set up your own test suite. + +## [amiya-pattnaik/webdriverIO-with-cucumberBDD](https://github.com/amiya-pattnaik/webdriverIO-with-cucumberBDD) + +- Framework: Cucumber (v3.x) +- Features: + - Page Objects Model uses with ES6 style class base approach and fully ES6 - ES8 support through Babel + - Examples of multi selector option to query element with more than one selector at a time + - Examples of headless browser execution using - PhantomJS and Chrome + - Integration with BrowserStack + - Support of read/write data from MS-Excel for easy test data management from external data sources with examples + - Database support to any RDBMS (Oracle, MySql, TeraData, Vertica etc.), executing any queries / fetching result set etc. with examples for E2E testing + - Multiple reporting (Spec, Junit, Allure, JSON), plus local view of Junit report(.html) format + - Task manage through Grunt + - Examples with demo app https://search.yahoo.com/ and http://www.phptravels.net, Chai assertion liberary (expect, assert, should) + - Appium specific .config file for playback on mobile device. For one click Appium setup refer [appium-setup-made-easy-OSX](https://github.com/amiya-pattnaik/appium-setup-made-easy-OSX) + +## [amiya-pattnaik/webdriverIO-with-jasmineBDD](https://github.com/amiya-pattnaik/webdriverIO-with-jasmineBDD) + +- Framework: Jasmine (v3.x) +- Features: + - Page Objects Model uses with ES6 style class base approach and fully ES6 - ES8 support through Babel + - Examples of multi selector option to query element with more than one selector at a time + - Examples of headless browser execution using - PhantomJS and Chrome + - Integration with BrowserStack + - Support of read/write data from MS-Excel for easy test data management from external data sources with examples + - Database support to any RDBMS (Oracle, MySql, TeraData, Vertica etc.), executing any queries / fetching result set etc. with examples for E2E testing + - Multiple reporting (Spec, Junit, Allure, JSON), plus local view of Junit report(.html) format + - Task manage through Grunt + - Examples with demo app http://www.phptravels.net + - Appium specific .config file for playback on mobile device. For one click Appium setup refer [appium-setup-made-easy-OSX](https://github.com/amiya-pattnaik/appium-setup-made-easy-OSX) + +## [amiya-pattnaik/webdriverIO-with-mochaBDD](https://github.com/amiya-pattnaik/webdriverIO-with-mochaBDD) + +- Framework: Mocha (v5.x) +- Features: + - Page Objects Model uses with ES6 style class base approach and fully ES6 - ES8 support through Babel + - Examples of multi selector option to query element with more than one selector at a time + - Examples of headless browser execution using - PhantomJS and Chrome + - Integration with BrowserStack + - Support of read/write data from MS-Excel for easy test data management from external data sources with examples + - Database support to any RDBMS (Oracle, MySql, TeraData, Vertica etc.), executing any queries / fetching result set etc. with examples for E2E testing + - Multiple reporting (Spec, Junit, Allure, JSON, Mochawesome, Timeline), plus local view of Junit report(.html) format and Mochawesome report + - Task manage through Grunt + - Examples with demo app http://www.phptravels.net, Chai assertion liberary (expect, assert, should) + - Appium specific .config file for playback on mobile device. For one click Appium setup refer [appium-setup-made-easy-OSX](https://github.com/amiya-pattnaik/appium-setup-made-easy-OSX) + +## [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 implementation + - Intellisense + +## [klamping/wdio-starter-kit](https://github.com/klamping/wdio-starter-kit) + +Boilerplate repo for quick set up of WebdriverIO test scripts with TravisCI, Sauce Labs and Visual Regression Testing + +- Framework: Mocha, Chai +- Features: + - Login & Registration Tests, with Page Objects + - Mocha + - Chai with expect global + - Chai WebdriverIO + - Sauce Labs integration + - Visual Regression Tests + - Local notifications + - ESLint using Semistandard style + - WebdriverIO tuned Gitignore file + +## [webdriverio/appium-boilerplate](https://github.com/webdriverio/appium-boilerplate/) + +Boilerplate project to run Appium tests together with WebdriverIO for: + +- iOS/Android Native Apps +- iOS/Android Hybrid Apps +- Android Chrome and iOS Safari browser + +The boilerplate holds the following things + +- Framework: Jasmine +- Features: + - Configs for: + - iOS and Android app + - iOS and Android browsers + - Helpers for: + - WebView + - Gestures + - Native alerts + - Pickers + - Tests examples for: + - WebView + - Login + - Forms + - Swipe + - Browsers \ No newline at end of file diff --git a/website/translated_docs/de/BrowserObject.md b/website/translated_docs/de/BrowserObject.md new file mode 100644 index 00000000000..12fcc567f9a --- /dev/null +++ b/website/translated_docs/de/BrowserObject.md @@ -0,0 +1,148 @@ +--- +id: browserobject +title: The Browser Object +--- +If you use the wdio test runner you can access the webdriver instance through the global `browser` or `driver` object. The session is initialized by the test runner. The same goes for ending the session. This is also done by the test runner process. + +Besides all commands from the [api](API.md) the browser object provides some more information you might be interested in during your test run: + +## Get Desired Capabilities + +```js +console.log(browser.sessionId); // outputs: "57b15c6ea81d0edb9e5b372da3d9ce28" +console.log(browser.capabilities); +/** + * outputs: + { acceptInsecureCerts: false, + acceptSslCerts: false, + applicationCacheEnabled: false, + browserConnectionEnabled: false, + browserName: 'chrome', + chrome: + { chromedriverVersion: '2.40.565386 (45a059dc425e08165f9a10324bd1380cc13ca363)', + userDataDir: '/var/folders/ns/8mj2mh0x27b_gsdddy1knnsm0000gn/T/.org.chromium.Chromium.mpJ0yc' }, + cssSelectorsEnabled: true, + databaseEnabled: false, + handlesAlerts: true, + hasTouchScreen: false, + javascriptEnabled: true, + locationContextEnabled: true, + mobileEmulationEnabled: false, + nativeEvents: true, + networkConnectionEnabled: false, + pageLoadStrategy: 'normal', + platform: 'Mac OS X', + rotatable: false, + setWindowRect: true, + takesHeapSnapshot: true, + takesScreenshot: true, + unexpectedAlertBehaviour: '', + version: '68.0.3440.106', + webStorageEnabled: true } + */ +``` + +## Get Config Options + +You can always define custom options within you wdio config: + +```js +// wdio.conf.js +exports.config = { + // ... + fakeUser: 'maxmustermann', + fakePassword: 'foobar', + // ... +} +``` + +to then access it in your tests: + +```js +console.log(browser.config); +/** + * outputs: + * { + port: 4444, + protocol: 'http', + waitforTimeout: 10000, + waitforInterval: 250, + coloredLogs: true, + deprecationWarnings: true, + logLevel: 'debug', + baseUrl: 'http://localhost', + connectionRetryTimeout: 90000, + connectionRetryCount: 3, + sync: true, + specs: [ 'err.js' ], + fakeUser: 'maxmustermann', // <-- custom option + fakePassword: 'foobar', // <-- custom option + // ... + */ + +console.log(browser.config.fakeUser); // outputs: "maxmustermann" +``` + +## Mobile Flags + +If you need to modify your test based on whether or not your session runs on a mobile device, you can access the mobile flags to check, e.g.: + +```js +// wdio.conf.js +exports.config = { + // ... + capabilities: { + platformName: 'iOS', + app: 'net.company.SafariLauncher', + udid: '123123123123abc', + deviceName: 'iPhone', + // ... + } + // ... +}; +``` + +In your test you can access these flags like: + +```js +// Note: `driver` is the equivalent to the `browser` object but semantically more correct +// you can choose which global variable you want to use +console.log(driver.isMobile); // outputs: true +console.log(driver.isIOS); // outputs: true +console.log(driver.isAndroid); // outputs: false +``` + +This can be useful if you want to define selectors in your page objects based on the device type, e.g. + +```js +// mypageobject.page.js +import Page from './page'; + +class LoginPage extends Page { + // ... + get username () { + const selectorAndroid = 'new UiSelector().text("Cancel").className("android.widget.Button")'; + const selectorIOS = 'UIATarget.localTarget().frontMostApp().mainWindow().buttons()[0]'; + const selectorType = driver.isAndroid ? 'android' : 'ios'; + const selector = driver.isAndroid ? selectorAndroid : selectorIOS; + return $(`${selectorType}=${selector}`); + } + // ... +} +``` + +You can also use these flags to only run certain tests for certain device types: + +```js +// mytest.e2e.js +describe('my test', () => { + // ... + // only run test with Android devices + if (driver.isAndroid) { + it('tests something only for Android', () => { + // ... + }) + } + // ... +}) +``` \ No newline at end of file diff --git a/website/translated_docs/de/CLI.md b/website/translated_docs/de/CLI.md new file mode 100644 index 00000000000..89ca906dd65 --- /dev/null +++ b/website/translated_docs/de/CLI.md @@ -0,0 +1,94 @@ +--- +id: clioptions +title: WDIO CLI Options +--- +WebdriverIO comes with its own test runner to help you get started with integration testing as quickly as possible. All the fiddling around hooking up WebdriverIO with a test framework belongs to the past. The WebdriverIO runner does all the work for you and helps you to run your tests as efficiently as possible. + +Starting with v5 of WebdriverIO the testrunner will be bundled as a seperated NPM package `@wdio/cli`. To see the command line interface help just type the following command in your terminal: + +```sh +$ npm install @wdio/cli +$ ./node_modules/.bin/wdio --help + +WebdriverIO CLI runner + +Usage: wdio [options] [configFile] +Usage: wdio config +Usage: wdio repl + +config file defaults to wdio.conf.js +The [options] object will override values from the config file. +An optional list of spec files can be piped to wdio that will override +configured specs + +Commands: + wdio.js repl Run WebDriver session in command line + +Options: + --help prints WebdriverIO help menu [boolean] + --version prints WebdriverIO version [boolean] + --host, -h automation driver host address [string] + --port, -p automation driver port [number] + --user, -u username if using a cloud service as automation backend + [string] + --key, -k corresponding access key to the user [string] + --watch watch specs for changes [boolean] + --logLevel, -l level of logging verbosity + [choices: "trace", "debug", "info", "warn", "error"] + --bail stop test runner after specific amount of tests have + failed [number] + --baseUrl shorten url command calls by setting a base url [string] + --waitforTimeout, -w timeout for all waitForXXX commands [number] + --framework, -f defines the framework (Mocha, Jasmine or Cucumber) to + run the specs [string] + --reporters, -r reporters to print out the results on stdout [array] + --suite overwrites the specs attribute and runs the defined + suite [array] + --spec run only a certain spec file - overrides specs piped + from stdin [array] + --exclude exclude spec file(s) from a run - overrides specs piped + from stdin [array] + --mochaOpts Mocha options + --jasmineOpts Jasmine options + --cucumberOpts Cucumber options +``` + +Sweet! Now you need to define a configuration file where all information about your tests, capabilities and settings are set. Switch over to the [Configuration File](ConfigurationFile.md) section to find out how that file should look like. With the `wdio` configuration helper it is super easy to generate your config file. Just run: + +```sh +$ ./node_modules/.bin/wdio config +``` + +and it launches the helper utility. It will ask you questions depending on the answers you give. This way you can generate your config file in less than a minute. + +![WDIO configuration utility](/img/config-utility.gif) + +Once you have your configuration file set up you can start your integration tests by calling: + +```sh +$ ./node_modules/.bin/wdio wdio.conf.js +``` + +That's it! Now, you can access to the selenium instance via the global variable `browser`. + +## Run the test runner programmatically + +Instead of calling the wdio command you can also include the test runner as module and run in within any arbitrary environment. For that you need to require the `@wdio/cli` package as module the following way: + +```js +import Launcher from '@wdio/cli'; +``` + +After that you create an instance of the launcher and run the test. The Launcher class expects as parameter the url to the config file and parameters that will overwrite the value in the config. + +```js +const wdio = new Launcher('/path/to/my/wdio.conf.js', opts); +wdio.run().then((code) => { + process.exit(code); +}, (error) => { + console.error('Launcher failed to start the test', error.stacktrace); + process.exit(1); +}); +``` + +The run command returns a [Promise](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) that gets resolved if the test ran successful or failed or gets rejected if the launcher was not able to start run the tests. \ No newline at end of file diff --git a/website/translated_docs/de/CloudServices.md b/website/translated_docs/de/CloudServices.md new file mode 100644 index 00000000000..34addee6a7c --- /dev/null +++ b/website/translated_docs/de/CloudServices.md @@ -0,0 +1,117 @@ +--- +id: cloudservices +title: Using Cloud Services +--- +Using ondemand services like Sauce Labs, Browserstack or TestingBot with WebdriverIO is pretty simple. All you need to do is to set `user` and `key` in your options that are provided by the cloud provider. Optional you can also parametrize your test by setting cloud specific capabilities like `build`. If you only want to run cloud services in Travis, you can use the `CI` environment variable to check if you are in Travis and modify the config accordingly. + +```js +// wdio.conf.js + +var config = {...} +if (process.env.CI) { + config.user = process.env.SAUCE_USERNAME; + config.key = process.env.SAUCE_ACCESS_KEY; +} +exports.config = config +``` + +## [Sauce Labs](https://saucelabs.com/) + +It is easy to set up your tests to run remotely in Sauce Labs. + +The only requirement is to set the `user` and `key` in your config (either exported by `wdio.conf.js` or passed into `webdriverio.remote(...)`) to your Sauce Labs username and access key. + +You can also pass in any optional [test configuration option](https://docs.saucelabs.com/reference/test-configuration/#webdriver-api) as a key/value in the capabilities for any browser. + +### [Sauce Connect](https://wiki.saucelabs.com/display/DOCS/Sauce+Connect+Proxy) + +If you want to run tests against a server that is not accessible to the Internet (like on `localhost`), then you need to use Sauce Connect. + +It is out of the scope of WebdriverIO to support this, so you must start it by yourself. + +If you are using the WDIO testrunner download and configure the [`@wdio/sauce-service`](https://github.com/webdriverio/webdriverio/tree/master/packages/wdio-sauce-service) in your `wdio.conf.js`. It helps getting Sauce Connect running and comes with additional features that better integrate your tests into the Sauce service. + +### With Travis CI + +Travis CI, however, does [have support](http://docs.travis-ci.com/user/sauce-connect/#Setting-up-Sauce-Connect) for starting Sauce Connect before each test, so follow their directions for that if you are interested. + +If you do so, you must set the `tunnel-identifier` test configuration option in each browser's capabilities. Travis sets this to the `TRAVIS_JOB_NUMBER` environmental variable by default. + +Also if you want to have Sauce Labs group your tests by build number, you can set the `build` to `TRAVIS_BUILD_NUMBER`. + +Lastly if you set the `name`, this changes the name of this test in Sauce Labs for this build. If you are using the WDIO testrunner combined with the [`@wdio/sauce-service`](https://github.com/webdriverio/webdriverio/tree/master/packages/wdio-sauce-service) WebdriverIO automatically sets a proper name for the test. + +Example `desiredCapabilities`: + +```javascript +browserName: 'chrome', +version: '27.0', +platform: 'XP', +'tunnel-identifier': process.env.TRAVIS_JOB_NUMBER, +name: 'integration', +build: process.env.TRAVIS_BUILD_NUMBER +``` + +### Timeouts + +Since you are running your tests remotely, it might be necessary to increase some timeouts. + +You can change the [idle timeout](https://docs.saucelabs.com/reference/test-configuration/#idle-test-timeout) by passing `idle-timeout` as a test configuration option. This controls how long Sauce will wait between commands before closing the connection. + +## [BrowserStack](https://www.browserstack.com/) + +Browserstack is also supported easily. + +The only requirement is to set the `user` and `key` in your config (either exported by `wdio.conf.js` or passed into `webdriverio.remote(...)`) to your Browserstack automate username and access key. + +You can also pass in any optional [supported capabilities](https://www.browserstack.com/automate/capabilities) as a key/value in the capabilities for any browser. If you set `browserstack.debug` to `true` it will record a screencast of the session, which might be helpful. + +### [Local Testing](https://www.browserstack.com/local-testing#command-line) + +If you want to run tests against a server that is not accessible to the Internet (like on `localhost`), then you need to use Local Testing. + +It is out of the scope of WebdriverIO to support this, so you must start it by yourself. + +If you do use local, you should set `browserstack.local` to `true` in your capabilities. + +If you are using the WDIO testrunner download and configure the [`wdio-browserstack-service`](https://github.com/itszero/wdio-browserstack-service) in your `wdio.conf.js`. It helps getting BrowserStack running and comes with additional features that better integrate your tests into the BrowserStack service. + +### With Travis CI + +If you want to add Local Testing in Travis you have to start it by yourself. + +The following script will download and start it in the background. You should run this in Travis before starting the tests. + +```bash +wget https://www.browserstack.com/browserstack-local/BrowserStackLocal-linux-x64.zip +unzip BrowserStackLocal-linux-x64.zip +./BrowserStackLocal -v -onlyAutomate -forcelocal $BROWSERSTACK_ACCESS_KEY & +sleep 3 +``` + +Also, you might wanna set the `build` to the Travis build number. + +Example `desiredCapabilities`: + +```javascript +browserName: 'chrome', +project: 'myApp', +version: '44.0', +build: 'myApp #' + process.env.TRAVIS_BUILD_NUMBER + '.' + process.env.TRAVIS_JOB_NUMBER, +'browserstack.local': 'true', +'browserstack.debug': 'true' +``` + +## [TestingBot](https://testingbot.com/) + +The only requirement is to set the `user` and `key` in your config (either exported by `wdio.conf.js` or passed into `webdriverio.remote(...)`) to your TestingBot username and secret key. + +You can also pass in any optional [supported capabilities](https://testingbot.com/support/other/test-options) as a key/value in the capabilities for any browser. + +### [Local Testing](https://testingbot.com/support/other/tunnel) + +If you want to run tests against a server that is not accessible to the Internet (like on `localhost`), then you need to use Local Testing. TestingBot provides a JAVA based tunnel to allow you to test websites not accessible from the internet. + +Their tunnel support page contains the information necessary to get this up and running. + +If you are using the WDIO testrunner download and configure the [`@wdio/testingbot-service`](https://github.com/webdriverio/webdriverio/tree/master/packages/wdio-testingbot-service) in your `wdio.conf.js`. It helps getting TestingBot running and comes with additional features that better integrate your tests into the TestingBot service. \ No newline at end of file diff --git a/website/translated_docs/de/ConfigurationFile.md b/website/translated_docs/de/ConfigurationFile.md new file mode 100644 index 00000000000..510254d886d --- /dev/null +++ b/website/translated_docs/de/ConfigurationFile.md @@ -0,0 +1,334 @@ +--- +id: configurationfile +title: Testrunner Configuration +--- +The configuration file contains all necessary information to run your test suite. It is a node module that exports a JSON. Here is an example configuration with all supported properties and additional information: + +```js +exports.config = { + + // ===================== + // Server Configurations + // ===================== + // Host address of the running Selenium server. This information is usually obsolete as + // WebdriverIO automatically connects to localhost. Also if you are using one of the + // supported cloud services like Sauce Labs, Browserstack or Testing Bot you also don't + // need to define host and port information because WebdriverIO can figure that out + // according to your user and key information. However if you are using a private Selenium + // backend you should define the host address, port, and path here. + // + host: '0.0.0.0', + port: 4444, + path: '/wd/hub', + // + // ================= + // Service Providers + // ================= + // WebdriverIO supports Sauce Labs, Browserstack and Testing Bot (other cloud providers + // should work too though). These services define specific user and key (or access key) + // values you need to put in here in order to connect to these services. + // + user: 'webdriverio', + key: 'xxxxxxxxxxxxxxxx-xxxxxx-xxxxx-xxxxxxxxx', + // + // If you run your tests on SauceLabs you can specify the region you want to run your tests + // in via the `region` property. Available short handles for regions are: + // us: us-west-1 (default) + // eu: eu-central-1 + region: 'us', + // + // ================== + // Specify Test Files + // ================== + // Define which test specs should run. The pattern is relative to the directory + // from which `wdio` was called. Notice that, if you are calling `wdio` from an + // NPM script (see https://docs.npmjs.com/cli/run-script) then the current working + // directory is where your package.json resides, so `wdio` will be called from there. + // + specs: [ + 'test/spec/**' + ], + // Patterns to exclude. + exclude: [ + 'test/spec/multibrowser/**', + 'test/spec/mobile/**' + ], + // + // ============ + // Capabilities + // ============ + // Define your capabilities here. WebdriverIO can run multiple capabilities at the same + // time. Depending on the number of capabilities, WebdriverIO launches several test + // sessions. Within your capabilities you can overwrite the spec and exclude option in + // order to group specific specs to a specific capability. + // + // + // First you can define how many instances should be started at the same time. Let's + // say you have 3 different capabilities (Chrome, Firefox and Safari) and you have + // set maxInstances to 1, wdio will spawn 3 processes. Therefor if you have 10 spec + // files and you set maxInstances to 10, all spec files will get tested at the same time + // and 30 processes will get spawned. The property basically handles how many capabilities + // from the same test should run tests. + // + maxInstances: 10, + // + // Or set a limit to run tests with a specific capability. + maxInstancesPerCapability: 10, + // + // If you have trouble getting all important capabilities together, check out the + // Sauce Labs platform configurator - a great tool to configure your capabilities: + // https://docs.saucelabs.com/reference/platforms-configurator + // + capabilities: [{ + browserName: 'chrome', + chromeOptions: { + // to run chrome headless the following flags are required + // (see https://developers.google.com/web/updates/2017/04/headless-chrome) + // args: ['--headless', '--disable-gpu'], + } + }, { + // maxInstances can get overwritten per capability. So if you have an in house Selenium + // grid with only 5 firefox instance available you can make sure that not more than + // 5 instance gets started at a time. + maxInstances: 5, + browserName: 'firefox', + specs: [ + 'test/ffOnly/*' + ], + "moz:firefoxOptions": { + // flag to activate Firefox headless mode (see https://github.com/mozilla/geckodriver/blob/master/README.md#firefox-capabilities for more details about moz:firefoxOptions) + // args: ['-headless'] + } + }], + // + // Additional list of node arguments to use when starting child processes + execArgv: [], + // + // =================== + // Test Configurations + // =================== + // Define all options that are relevant for the WebdriverIO instance here + // + // Level of logging verbosity: trace | debug | info | warn | error + logLevel: 'info', + // + // 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). + bail: 0, + // + // Set a base URL in order to shorten url command calls. If your `url` parameter starts + // with `/`, the base url gets prepended, not including the path portion of your baseUrl. + // If your `url` parameter starts without a scheme or `/` (like `some/path`), the base url + // gets prepended directly. + baseUrl: 'http://localhost:8080', + // + // Default timeout for all waitForXXX commands. + waitforTimeout: 1000, + // + // Add files to watch (e.g. application code or page objects) when running `wdio` command + // with `--watch` flag (globbing is supported). + filesToWatch: [ + // e.g. rerun tests if I change my application code + // './app/**/*.js' + ], + // + // Framework you want to run your specs with. + // The following are supported: mocha, jasmine and cucumber + // see also: http://webdriver.io/docs/frameworks.html + // + // Make sure you have the wdio adapter package for the specific framework installed before running any tests. + framework: 'mocha', + // + // Test reporter for stdout. + // The only one supported by default is 'dot' + // see also: http://webdriver.io/docs/dot-reporter.html and click on "Reporters" in left column + reporters: [ + 'dot', + ['allure', { + // + // If you are using the "allure" reporter you should define the directory where + // WebdriverIO should save all allure reports. + outputDir: './' + }] + ], + // + // Options to be passed to Mocha. + // See the full list at http://mochajs.org/ + mochaOpts: { + ui: 'bdd' + }, + // + // Options to be passed to Jasmine. + // See also: https://github.com/webdriverio/webdriverio/tree/master/packages/wdio-jasmine-framework#jasminenodeopts-options + jasmineNodeOpts: { + // + // Jasmine default timeout + defaultTimeoutInterval: 5000, + // + // The Jasmine framework allows it to intercept each assertion in order to log the state of the application + // or website depending on the result. For example it is pretty handy to take a screenshot every time + // an assertion fails. + expectationResultHandler: function(passed, assertion) { + // do something + }, + // + // Make use of Jasmine-specific grep functionality + grep: null, + invertGrep: null + }, + // + // If you are using Cucumber you need to specify where your step definitions are located. + // See also: https://github.com/webdriverio/webdriverio/tree/master/packages/wdio-cucumber-framework#cucumberopts-options + cucumberOpts: { + require: [], // (file/dir) require files before executing features + backtrace: false, // show full backtrace for errors + compiler: [], // ("extension:module") require files with the given EXTENSION after requiring MODULE (repeatable) + dryRun: false, // invoke formatters without executing steps + failFast: false, // abort the run on first failure + format: ['pretty'], // (type[:path]) specify the output format, optionally supply PATH to redirect formatter output (repeatable) + colors: true, // disable colors in formatter output + snippets: true, // hide step definition snippets for pending steps + source: true, // hide source URIs + profile: [], // (name) specify the profile to use + strict: false, // fail if there are any undefined or pending steps + tags: [], // (expression) only execute the features or scenarios with tags matching the expression + timeout: 20000, // timeout for step definitions + ignoreUndefinedDefinitions: false, // Enable this config to treat undefined definitions as warnings. + }, + // + // ===== + // Hooks + // ===== + // WebdriverIO provides a several hooks you can use to interfere the test process in order to enhance + // it and build services around it. You can either apply a single function to it or an array of + // methods. If one of them returns with a promise, WebdriverIO will wait until that promise got + // resolved to continue. + // + + /** + * Gets executed once before all workers get launched. + * @param {Object} config wdio configuration object + * @param {Array.} capabilities list of capabilities details + */ + onPrepare: function (config, capabilities) { + }, + /** + * Gets executed just before initialising the webdriver session and test framework. It allows you + * to manipulate configurations depending on the capability or spec. + * @param {Object} config wdio configuration object + * @param {Array.} capabilities list of capabilities details + * @param {Array.} specs List of spec file paths that are to be run + */ + beforeSession: function (config, capabilities, specs) { + }, + /** + * Gets executed before test execution begins. At this point you can access to all global + * variables like `browser`. It is the perfect place to define custom commands. + * @param {Array.} capabilities list of capabilities details + * @param {Array.} specs List of spec file paths that are to be run + */ + before: function (capabilities, specs) { + }, + /** + * Hook that gets executed before the suite starts + * @param {Object} suite suite details + */ + beforeSuite: function (suite) { + }, + /** + * Hook that gets executed _before_ a hook within the suite starts (e.g. runs before calling + * beforeEach in Mocha) + */ + beforeHook: function () { + }, + /** + * Hook that gets executed _after_ a hook within the suite ends (e.g. runs after calling + * afterEach in Mocha) + */ + afterHook: function () { + }, + /** + * Function to be executed before a test (in Mocha/Jasmine) or a step (in Cucumber) starts. + * @param {Object} test test details + */ + beforeTest: function (test) { + }, + /** + * Runs before a WebdriverIO command gets executed. + * @param {String} commandName hook command name + * @param {Array} args arguments that command would receive + */ + beforeCommand: function (commandName, args) { + }, + /** + * Runs after a WebdriverIO command gets executed + * @param {String} commandName hook command name + * @param {Array} args arguments that command would receive + * @param {Number} result 0 - command success, 1 - command error + * @param {Object} error error object if any + */ + afterCommand: function (commandName, args, result, error) { + }, + /** + * Function to be executed after a test (in Mocha/Jasmine) or a step (in Cucumber) ends. + * @param {Object} test test details + */ + afterTest: function (test) { + }, + /** + * Hook that gets executed after the suite has ended + * @param {Object} suite suite details + */ + afterSuite: function (suite) { + }, + /** + * Gets executed after all tests are done. You still have access to all global variables from + * the test. + * @param {Number} result 0 - test pass, 1 - test fail + * @param {Array.} capabilities list of capabilities details + * @param {Array.} specs List of spec file paths that ran + */ + after: function (result, capabilities, specs) { + }, + /** + * Gets executed right after terminating the webdriver session. + * @param {Object} config wdio configuration object + * @param {Array.} capabilities list of capabilities details + * @param {Array.} specs List of spec file paths that ran + */ + afterSession: function (config, capabilities, specs) { + }, + /** + * Gets executed after all workers got shut down and the process is about to exit. + * @param {Object} exitCode 0 - success, 1 - fail + * @param {Object} config wdio configuration object + * @param {Array.} capabilities list of capabilities details + * @param {} results object containing test results + */ + onComplete: function (exitCode, config, capabilities, results) { + }, + /** + * Gets executed when an error happens, good place to take a screenshot + * @ {String} error message + */ + onError: function(message) { + } + /** + * Cucumber specific hooks + */ + beforeFeature: function (feature) { + }, + beforeScenario: function (scenario) { + }, + beforeStep: function (step) { + }, + afterStep: function (stepResult) { + }, + afterScenario: function (scenario) { + }, + afterFeature: function (feature) { + } +}; +``` + +You can also find that file with all possible options and variations in the [example folder](https://github.com/webdriverio/webdriverio/blob/master/examples/wdio.conf.js). \ No newline at end of file diff --git a/website/translated_docs/de/CustomCommands.md b/website/translated_docs/de/CustomCommands.md new file mode 100644 index 00000000000..60320255dac --- /dev/null +++ b/website/translated_docs/de/CustomCommands.md @@ -0,0 +1,54 @@ +--- +id: customcommands +title: Custom Commands +--- +If you want to extend the browser instance with your own set of commands there is a method called `addCommand` available from the browser object. You can write your command in a synchronous (default) way the same way as in your specs or asynchronous (like when using WebdriverIO in standalone mode). The following example shows how to add a new command that returns the current url and title as one result only using synchronous commands: + +```js +browser.addCommand("getUrlAndTitle", (customVar) => { + return { + url: this.getUrl(), + title: this.getTitle(), + customVar: customVar + }; +}); +``` + +Custom commands give you the opportunity to bundle a specific sequence of commands that are used frequently in a handy single command call. You can define custom commands at any point in your test suite, just make sure that the command is defined before you first use it (the before hook in your wdio.conf.js might be a good point to create them). Once defined you can use them as follows: + +```js +it('should use my custom command', () => { + browser.url('http://www.github.com'); + const result = browser.getUrlAndTitle('foobar'); + + assert.strictEqual(result.url, 'https://github.com/'); + assert.strictEqual(result.title, 'GitHub · Where software is built'); + assert.strictEqual(result.customVar, 'foobar'); +}); +``` + +Be careful to not overload the `browser` scope with custom commands. It is advised to rather define custom logic into page objects so they are bound to a specific page. + +## Integrate 3rd party libraries + +If you use external libraries (e.g. to do database calls) that support promises, a nice approach to easily integrate them is to wrap certain API methods within a custom command. When returning the promise, WebdriverIO ensures that it doesn't continue with the next command until the promise is resolved. If the promise gets rejected the command will throw an error. + +```js +import request from 'request'; + +browser.addCommand('makeRequest', (url) => { + return request.get(url).then((response) => response.body) +}); +``` + +Then just use it in your wdio test specs synchronously: + +```js +it('execute external library in a sync way', () => { + browser.url('...'); + const body = browser.makeRequest('http://...'); + console.log(body); // returns response body +}); +``` + +Note that the result of your custom command will be the result of the promise you return. Also there is no support for synchronous commands in standalone mode therefore you always have to handle asynchronous commands using promises. \ No newline at end of file diff --git a/website/translated_docs/de/CustomReporter.md b/website/translated_docs/de/CustomReporter.md new file mode 100644 index 00000000000..fe519a5ea6a --- /dev/null +++ b/website/translated_docs/de/CustomReporter.md @@ -0,0 +1,78 @@ +--- +id: customreporter +title: Custom Reporter +--- +You can write your own custom reporter for the wdio test runner that fits your needs. All you need to do is to create a node module that inherits from the `@wdio/reporter` package so it can receive messages from the test. The basic construction should look like: + +```js +import WDIOReporter from '@wdio/reporter'; + +export default class CustomReporter extends WDIOReporter { + constructor (options) { + /** + * make reporter to write to output stream by default + */ + options = Object.assign(options, { stdout: true }); + super(options); + } + + onTestPass (test) { + this.write(`Congratulations! Your test "${test.title}" passed 👏`); + } +}; +``` + +The only thing to do now in order to use this reporter is to assign it to the reporter property. Therefor your wdio.conf.js file should look like this: + +```js +var CustomReporter = require('./reporter/my.custom.reporter'); + +exports.config = { + // ... + reporters: [[CustomReporter, { + someOption: 'foobar' + }]], + // ... +}; +``` + +You can also publish the reporter to NPM so everyone can use it. Name the package like other reporters `wdio--reporter` and tag it with keywords like `wdio` or `wdio-reporter`. + +## Event Handler + +You can register event handler for several events which get triggered during the test. All these handlers will receive payloads with useful information about the current state and progress. The structure of these payload objects depend on the event and are unified across the frameworks (Mocha, Jasmine and Cucumber). Once you implemented your custom reporter it should work for all frameworks. The following list contains all possible methods you can add to your reporter class: + +```js +import WDIOReporter from '@wdio/reporter'; + +export default class CustomReporter extends WDIOReporter { + onRunnerStart () {} + onBeforeCommand () {} + onAfterCommand () {} + onScreenshot () {} + onSuiteStart () {} + onHookStart () {} + onHookEnd () {} + onTestStart () {} + onTestPass () {} + onTestFail () {} + onTestSkip () {} + onTestEnd () {} + onSuiteEnd () {} + onRunnerEnd () {} +}; +``` + +The method names are pretty self explanatory. To print something on a certain event, use the `this.write(...)` method which is provided by the parent class (`WDIOReporter`). It either streams the content to stdout or to a log file depending on the options of the reporter. + +```js +import WDIOReporter from '@wdio/reporter'; + +export default class CustomReporter extends WDIOReporter { + onTestPass (test) { + this.write(`Congratulations! Your test "${test.title}" passed 👏`); + } +}; +``` + +Note that you can't defer the test execution in any way. All event handler should execute synchronous routines otherwise you will run into race conditions. Make sure you check out the [example section](https://github.com/webdriverio/webdriverio/tree/master/examples/wdio) where you can find an example for a custom reporter that prints the event name for each event. If you have implemented a custom reporter that can be useful for the community, don't hesitate to make a Pull Request so we can make the reporter available for the public. \ No newline at end of file diff --git a/website/translated_docs/de/CustomServices.md b/website/translated_docs/de/CustomServices.md new file mode 100644 index 00000000000..c0d38b0890a --- /dev/null +++ b/website/translated_docs/de/CustomServices.md @@ -0,0 +1,55 @@ +--- +id: customservices +title: Custom Services +--- +You can write your own custom service for the wdio test runner that fits your needs. Services are addons to be created for reusable logic to simplify tests, manage your test suite and integrate results. Services have access to all the same [before/after hooks](ConfigurationFile.md) available in the `wdio.conf.js`. The basic construction of service should look like this: + +```js +export default class CustomService { + onPrepare (config, capabilities) { + // TODO: something before the workers launch + } + + onComplete (exitCode, config, capabilities) { + // TODO: something after the workers shutdown + }, + + // ... +} +``` + +The only thing to do now in order to use this service is to assign it to the services property. Therefor your `wdio.conf.js` file should look like this: + +```js +import CustomService from './service/my.custom.service'; + +exports.config = { + // ... + services: [[CustomService, { + someOption: true + }]], + // ... +}; +``` + +### NPM + +To make services easier to consume and discover by the webdriver.io community, please follow these recommendations: + +* services should use naming convention is `wdio-*-service` +* use NPM keywords `wdio-plugin`, `wdio-service` +* main entry should export an instance of the service. +* example services: [@wdio/sauce-service](https://github.com/webdriverio/webdriverio/tree/master/packages/wdio-sauce-service) + +Following the recommended naming pattern allows services to be added by name: + +```js +// Add wdio-custom-service +exports.config = { + // ... + services: ['custom'], + // ... +}; +``` + +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/packages/wdio-cli/src/config.js#L20-L34) so your package will be suggested if someone runs the wdio configurator. \ No newline at end of file diff --git a/website/translated_docs/de/Debugging.md b/website/translated_docs/de/Debugging.md new file mode 100644 index 00000000000..33eba136d44 --- /dev/null +++ b/website/translated_docs/de/Debugging.md @@ -0,0 +1,86 @@ +--- +id: debugging +title: Debugging +--- +Debugging is significantly more difficult when there are several processes spawning dozens of tests in multiple browsers. + +For starters, it is extremely helpful to limit parallelism by setting `maxInstances` to 1 and targeting only those specs and browsers that need to be debugged. + +In `wdio.conf`: + +```js +exports.config = { + // ... + maxInstances: 1, + specs: [ + '**/myspec.spec.js' + ], + capabilities: [{ + browserName: 'firefox' + }], + // ... +} +``` + +## The Debug Command + +In many cases, you can use [`browser.debug()`](/docs/api/browser/debug.html) to pause your test and inspect the browser. Your command line interface will also switch into a REPL mode that allows you to fiddle around with commands and elements on the page. In REPL mode you can access the browser object or `$` and `$$` functions like you can in your tests. + +When using `browser.debug()` you will likely need to increase the timeout of the test runner to prevent the test runner from failing the test for taking to long. For example: + +In `wdio.conf`: + +```js +jasmineNodeOpts: { + defaultTimeoutInterval: (24 * 60 * 60 * 1000); +} +``` + +See [timeouts](Timeouts.md) for more information on how to do that using other frameworks. + +## Debugging in Chrome DevTools + +To get it working, you need to pass the `--inspect` flag down to the wdio command running tests like this: + +```sh +$ wdio wdio.conf.js --inspect +``` + +This will start the runner process with this inspect flag enabled. With that you can open the DevTools and can connect to the runner process. Make sure you set a `debugger` statement somewhere in order to start fiddling around with commands in the console. + +Tests will pause at `debugger` statements, but ONLY once dev-tools has been opened and the debugger attached. If you prefer to break on the first line, you can use `--inspect-brk` instead. + +Once execution has finished, the test doesn't actually finish until the devtools is closed. You'll need to do that yourself. + +## Dynamic configuration + +Note that `wdio.conf.js` can contain javascript. Since you probably do not want to permanently change your timeout value to 1 day, it can be often helpful to change these settings from the command line using an environment variable. This can used to dynamically change the configuration: + +```js +const debug = process.env.DEBUG; +const defaultCapabilities = ...; +const defaultTimeoutInterval = ...; +const defaultSpecs = ...; + +exports.config = { + // ... + maxInstances: debug ? 1 : 100, + capabilities: debug ? [{ browserName: 'chrome' }] : defaultCapabilities, + execArgv: debug ? ['--inspect'] : [], + jasmineNodeOpts: { + defaultTimeoutInterval: debug ? (24 * 60 * 60 * 1000) : defaultTimeoutInterval + } + // ... +} +``` + +You can then prefix the `wdio` command with the debug flag: + + DEBUG=true ./node_modules/.bin/wdio wdio.conf.js --spec ./tests/e2e/myspec.test.js + + +and debug your spec file with the DevTools. + +## Dynamic Repl with Atom + +If you are an [Atom](https://atom.io/) hacker you can try [wdio-repl](https://github.com/kurtharriger/wdio-repl) by [@kurtharriger](https://github.com/kurtharriger) which is a dynamic repl that allows you to execute single code lines in Atom. Watch [this](https://www.youtube.com/watch?v=kdM05ChhLQE) Youtube video to see a demo. \ No newline at end of file diff --git a/website/translated_docs/de/Frameworks.md b/website/translated_docs/de/Frameworks.md new file mode 100644 index 00000000000..8194589a026 --- /dev/null +++ b/website/translated_docs/de/Frameworks.md @@ -0,0 +1,105 @@ +--- +id: frameworks +title: Frameworks +--- +The wdio runner currently supports [Mocha](http://mochajs.org/) and [Jasmine](http://jasmine.github.io/) and [Cucumber](https://cucumber.io/) (not yet supported in v5). To integrate each framework with WebdriverIO there are adapter packages on NPM that need to be downloaded and installed. Note that these packages need to be installed at the same place WebdriverIO is installed. If you've installed WebdriverIO globally make sure you have the adapter package installed globally as well. + +Within your spec files or step definition you can access the webdriver instance using the global variable `browser`. You don't need to initiate or end the Selenium session. This is taken care of by the wdio testrunner. + +## Using Mocha + +First you need to install the adapter package from NPM: + +```sh +npm install @wdio/mocha-framework --save-dev +``` + +If you like to use Mocha you should additionally install an assertion library to have more expressive tests, e.g. [Chai](http://chaijs.com). Initialise that library in the `before` hook in your configuration file: + +```js +before: function() { + var chai = require('chai'); + global.expect = chai.expect; + chai.Should(); +} +``` + +Once that is done you can write beautiful assertions like: + +```js +describe('my awesome website', () => { + it('should do some chai assertions', () => { + browser.url('http://webdriver.io'); + browser.getTitle().should.be.equal('WebdriverIO - WebDriver bindings for Node.js'); + }); +}); +``` + +WebdriverIO supports Mochas `BDD` (default), `TDD` and `QUnit` [interface](https://mochajs.org/#interfaces). If you like to write your specs in TDD language set the ui property in your `mochaOpts` config to `tdd`, now your test files should get written like: + +```js +suite('my awesome website', () => { + test('should do some chai assertions', () => { + browser.url('http://webdriver.io'); + browser.getTitle().should.be.equal('WebdriverIO - WebDriver bindings for Node.js'); + }); +}); +``` + +If you want to define specific Mocha settings you can do that by adding `mochaOpts` to your configuration file. A list of all options can be found on the [project website](http://mochajs.org/). + +**Note:** that since all commands are running synchronously there is no need to have async mode in Mocha enabled. Therefor you can't use the `done` callback: + +```js +it('should test something', () => { + done(); // throws "done is not a function" +}) +``` + +If you want to run something asynchronously you can either use the [`call`](api/browser/call.md) command or [custom commands](CustomCommands.md). + +## Using Jasmine + +First you need to install the adapter package from NPM: + +```sh +npm install @wdio/jasmine-framework --save-dev +``` + +Jasmine already provides assertion methods you can use with WebdriverIO. So there is no need to add another one. + +### Intercept Assertion + +The Jasmine framework allows it to intercept each assertion in order to log the state of the application or website depending on the result. For example it is pretty handy to take a screenshot everytime an assertion fails. In your `jasmineNodeOpts` you can add a property called `expectationResultHandler` that takes a function to execute. The function parameter give you information about the result of the assertion. The following example demonstrate how to take a screenshot if an assertion fails: + +```js +jasmineNodeOpts: { + defaultTimeoutInterval: 10000, + expectationResultHandler: function(passed, assertion) { + /** + * only take screenshot if assertion failed + */ + if(passed) { + return; + } + + browser.saveScreenshot('assertionError_' + assertion.error.message + '.png'); + } +}, +``` + +Please note that you can't stop the test execution to do something async. It might happen that the command takes too much time and the website state has changed. Though usually after 2 another commands the screenshot got taken which gives you still valuable information about the error. + +## Using Cucumber + +To use Cucumber you have to use WebdriverIO v4 until the framework has been migrated to v5. First you need to install the adapter package from NPM: + +```sh +npm install @wdio/cucumber-framework --save-dev +``` + +If you want to use Cucumber set the `framework` property to cucumber, either by adding `framework: 'cucumber'` to the [config file](ConfigurationFile.md) or by adding `-f cucumber` to the command line. + +Options for Cucumber can be given in the config file with cucumberOpts. Check out the whole list of options [here](https://github.com/webdriverio/webdriverio/tree/master/packages/wdio-cucumber-framework#cucumberopts-options). + +To get up and running quickly with Cucumber have a look on our [cucumber-boilerplate](https://github.com/webdriverio/cucumber-boilerplate) project that comes with all step definition you will probably need and allows you to start writing feature files right away. \ No newline at end of file diff --git a/website/translated_docs/de/GettingStarted.md b/website/translated_docs/de/GettingStarted.md new file mode 100644 index 00000000000..89e38c3daa1 --- /dev/null +++ b/website/translated_docs/de/GettingStarted.md @@ -0,0 +1,180 @@ +--- +id: gettingstarted +title: Getting Started +--- +Welcome to the WebdriverIO documentation. It will help you to get started fast. If you run into problems you can find help and answers on our [Gitter Channel](https://gitter.im/webdriverio/webdriverio) or you can hit me on [Twitter](https://twitter.com/webdriverio). Also, if you encounter problems in starting up the server or running the tests after following this tutorial, ensure that the server and the geckodriver are listed in your project directory. If not, re-download them per steps 2 and 3 below. + +> **Note:** These are the docs for the latest version (v5.0.0) of WebdriverIO. If you are still using v4 or older please us the legacy docs website [v4.webdriver.io](http://v4.webdriver.io)! + +The following will give you a short step by step introduction to get your first WebdriverIO script up and running. + +## Taking the first step + +Let's suppose you have [Node.js](http://nodejs.org/) already installed. First thing we need to do is to download a browser driver that helps us automate the browser. To do so we create an example folder first: + +### Create a simple test folder + +```sh +$ mkdir webdriverio-test && cd webdriverio-test +``` + +*While still in this test folder:* + +### Download Geckodriver + +Download the latest version of geckodriver for your environment and unpack it in your project directory: + +Linux 64 bit + +```sh +$ curl -L https://github.com/mozilla/geckodriver/releases/download/v0.21.0/geckodriver-v0.21.0-linux64.tar.gz | tar xz +``` + +OSX + +```sh +$ curl -L https://github.com/mozilla/geckodriver/releases/download/v0.21.0/geckodriver-v0.21.0-macos.tar.gz | tar xz +``` + +Note: Other geckodriver releases are available [here](https://github.com/mozilla/geckodriver/releases). In order to automate other browser you need to run different drivers. You can find a list with all drivers in the [awesome-selenium](https://github.com/christian-bromann/awesome-selenium#driver) readme. + +### Start Browser Driver + +Start Geckodriver by running: + +```sh +$ /path/to/binary/geckodriver --port 4444 +``` + +This will start Geckodriver on `localhost:4444` with the WebDriver endpoint set to `/`. Keep this running in the background and open a new terminal window. Next step is to download WebdriverIO via NPM: + +### Download WebdriverIO + +By calling: + +```sh +$ npm install webdriverio +``` + +### Create Test File + +Create a test file (e.g. `test.js`) with the following content: + +```js +const { remote } = require('webdriverio'); + +(async () => { + const browser = await remote({ + logLevel: 'error', + path: '/', + capabilities: { + browserName: 'firefox' + } + }); + + await browser.url('http://webdriver.io'); + + const title = await browser.getTitle(); + console.log('Title was: ' + title); + + await browser.deleteSession(); +})().catch((e) => console.error(e)); +``` + +### Run your test file + +Make sure you have at least Node.js v8.11.2 or higher installed. To update your current running Node.js version install [nvm](https://github.com/creationix/nvm) and follow their instructions. Once that is done run the test script by calling: + +```sh +$ node test.js +``` + +this should output the following: + +```sh +Title was: WebdriverIO · Next-gen WebDriver test framework for Node.js +``` + +Yay, Congratulations! You've just run your first automation script with WebdriverIO. Let's step it up a notch and create a real test. + +## Let's get serious + +*(If you haven't already, navigate back to the project root directory)* + +This was just a warm up. Let's move forward and run WebdriverIO with the test runner. If you want to use WebdriverIO in your project for integration testing we recommend to use the test runner because it comes with a lot of useful features that makes your life easier. With WebdriverIO v5 and up the testrunner has moved into the [`@wdio/cli`](https://www.npmjs.com/package/@wdio/cli) NPM package. To get started, we need to install this first: + +```sh +$ npm i --save-dev @wdio/cli +``` + +### Generate Configuration File + +To do that just run the configuration utility: + +```sh +$ ./node_modules/.bin/wdio config +``` + +A question interface pops up. It will help to create the config easy and fast. If you are not sure what to answer follow this answers: + +__Q: Where should your tests be launched?__ +A: *local_ +
__Q: Shall I install the runner plugin for you?__ +A: _Yes_ +
__Q: Where do you want to execute your tests?__ +A: _On my local machine_ +
__Q: Which framework do you want to use?__ +A: _mocha_ +
__Q: Shall I install the framework adapter for you?__ +A: _Yes* (just press enter) +
__Q: Do you want to run WebdriverIO commands synchronous or asynchronous?__ +A: *sync* (just press enter, you can also run commands async and handle promises by yourself but for the sake of simplicity let's run them synchronously) +
__Q: Where are your test specs located?__ +A: *./test/specs/**/*.js* (just press enter) +
__Q: Which reporter do you want to use?__ +A: *dot* (just press space and enter) +
__Q: Shall I install the reporter library for you?__ +A: *Yes* (just press enter) +
__Q: Do you want to add a service to your test setup?__ +A: none (just press enter, let's skip this for simplicity) +
__Q: Level of logging verbosity:__ +A: *trace* (just press enter) +
__Q: In which directory should screenshots gets saved if a command fails?__ +A: *./errorShots/* (just press enter) +
__Q: What is the base url?__ +A: *http://localhost* (just press enter) + + +That's it! The configurator now installs all required packages for you and creates a config file with the name `wdio.conf.js`. Next step is to create your first spec file (test file). + +### Create Spec Files + +For that create a test folder like this: + +```sh +$ mkdir -p ./test/specs +``` + +Now let's create a simple spec file in that new folder: + +```js +const assert = require('assert'); + +describe('webdriver.io page', () => { + it('should have the right title', () => { + browser.url('http://webdriver.io'); + const title = browser.getTitle(); + assert.equal(title, 'WebdriverIO - WebDriver bindings for Node.js'); + }); +}); +``` + +### Kick Off Testrunner + +The last step is to execute the test runner. To do so just run: + +```sh +$ ./node_modules/.bin/wdio wdio.conf.js +``` + +Hurray! The test should pass and you can start writing integration tests with WebdriverIO. If you are interested in more in depth video on-boarding tutorials, feel free to check out our very own course called [learn.webdriver.io](https://learn.webdriver.io/?coupon=wdio). Also our community has collected a lot of [boilerplate projects](BoilerplateProjects.md) that can help you to get started. \ No newline at end of file diff --git a/website/translated_docs/de/JenkinsIntegration.md b/website/translated_docs/de/JenkinsIntegration.md new file mode 100644 index 00000000000..46509cd5153 --- /dev/null +++ b/website/translated_docs/de/JenkinsIntegration.md @@ -0,0 +1,43 @@ +--- +id: jenkins +title: Jenkins Integration +--- +WebdriverIO offers a tight integration to CI systems like [Jenkins](https://jenkins-ci.org/). With the [junit reporter](https://github.com/webdriverio/wdio-junit-reporter) you can easily debug your tests as well as keep track of your test results. The integration is pretty easy. + +First we need to define `junit` as test reporter. Also make sure you have it installed (`$ npm install --save-dev wdio-junit-reporter`) and that we save our xunit results at a place where Jenkins can pick them up. Therefore we define our reporter in our config as follows: + +```js +// wdio.conf.js +module.exports = { + // ... + reporters: [ + 'dot', + ['junit', { + outputDir: './' + }] + ], + // ... +}; +``` + +It is up to you which framework you want to choose. The reports will be similar. This tutorial is going to use Jasmine. After you have written couple of tests you can begin to setup a new Jenkins job. Give it a name and a description: + +![Name And Description](/img/jenkins/jobname.png "Name And Description") + +Then make sure it grabs always the newest version of your repository: + +![Jenkins Git Setup](/img/jenkins/gitsetup.png "Jenkins Git Setup") + +Now the important part: create a build step to execute shell commands. That build step needs to build your project. Since this demo project only tests an external app we don't need to build anything but install the node dependencies and run our test command `npm test` which is an alias for `node_modules/.bin/wdio test/wdio.conf.js`. + +![Build Step](/img/jenkins/runjob.png "Build Step") + +After our test we want Jenkins to track our xunit report. To do so we have to add a post-build action called *"Publish JUnit test result report"*. You could also install an external xunit plugin to track your reports. The JUnit one comes with the basic Jenkins installation and is sufficient enough for now. + +According to our config file we store the xunit reports in our workspace root directory. These reports are xml files. So all we need to do in order to track the reports is to point Jenkins to all xml files in our root directory: + +![Post-build Action](/img/jenkins/postjob.png "Post-build Action") + +That's it! This is all you need to setup Jenkins to run your WebdriverIO jobs. Your job will now provide detailed test results with history charts, stacktrace information on failed jobs as well as a list of commands with payload that got used in each test. + +![Jenkins Final Integration](/img/jenkins/final.png "Jenkins Final Integration") \ No newline at end of file diff --git a/website/translated_docs/de/Multiremote.md b/website/translated_docs/de/Multiremote.md new file mode 100644 index 00000000000..a4eda25cf20 --- /dev/null +++ b/website/translated_docs/de/Multiremote.md @@ -0,0 +1,101 @@ +--- +id: multiremote +title: Multiremote +--- +WebdriverIO allows you to run multiple WebDriver/Appium sessions in a single test. This becomes handy when you need to test application features where multiple users are required (e.g. chat or WebRTC applications). Instead of creating a couple of remote instances where you need to execute common commands like [newSession](/docs/api/webdriver.html#newsession) or [url](/docs/api/browser/url.html) on each of those instances, you can simply create a multiremote instance and control all browser at the same time. To do so just use the `multiremote` function and pass an object with named browser with their capabilities into it. By giving each capability a name you will be able to easy select and access that single instance when executing commands on a single instance. + +## Using Standalone Mode + +Here is an example demonstrating a how to create a multiremote WebdriverIO instance in **standalone mode**: + +```js +import { multiremote } from 'webdriverio'; + +(async () => { + const browser = await multiremote({ + myChromeBrowser: { + capabilities: { + browserName: 'chrome' + } + }, + myFirefoxBrowser: { + capabilities: { + browserName: 'firefox' + } + } + }); + + // open url with both browser at the same time + await browser.url('http://json.org'); + + // click on an element at the same time + const elem = await browser.$('#someElem'); + await elem.click(); + + // only click with one browser (Firefox) + await elem.myFirefoxBrowser.click(); +})() +``` + +## Using WDIO Testrunner + +In order to use multiremote in the wdio testrunner just define the `capabilities` object in your `wdio.conf.js` as an object with the browser names as keys (instead of a list of capabilities): + +```js +export.config = { + // ... + capabilities: { + myChromeBrowser: { + desiredCapabilities: { + browserName: 'chrome' + } + }, + myFirefoxBrowser: { + desiredCapabilities: { + browserName: 'firefox' + } + } + } + // ... +}; +``` + +This would create two WebDriver sessions with Chrome and Firefox. Instead of just Chrome and Firefox you can also boot up two mobile devices using [Appium](http://appium.io/). Any kind of OS/browser combination is possible here (e.g. cross platform like mobile device and desktop browser). All commands you call with the `browser` variable gets executed in parallel with each instance. This helps to streamline your integration test and speedup the execution a bit. For example open up an url: + +```js +browser.url('http://chat.socket.io/'); +``` + +Each command result will be an object with the browser names as key and the actual command result as value, e.g. + +```js +// wdio testrunner example +browser.url('https://www.whatismybrowser.com/'); + +const elem = $('.string-major'); +const result = elem.getText(); + +console.log(result.resultChrome); // returns: 'Chrome 40 on Mac OS X (Yosemite)' +console.log(result.resultFirefox); // returns: 'Firefox 35 on Mac OS X (Yosemite)' +``` + +You will notice that each command gets executed one by one. That means that the command finishes once all browser have executed it. This is helpful because it keeps the browser actions synced and it makes it easier to understand what currently happens. + +Sometimes it is necessary to do different things with each browser in order to test something. For instance if we want to test a chat application, there has to be one browser who inputs a text message while the other browser waits to receive that message and do an assertion on it. When using the WDIO testrunner it registers the browser names with their instances to the global scope, e.g. + +```js +myChromeBrowser.$('#message').setValue('Hi, I am Chrome'); +myChromeBrowser.$('#send').click(); + +const firefoxMessages = myFirefoxBrowser.$$('.messages') +// wait until messages arrive +firefoxMessages.waitForExist(); +// check if one of the messages contain the Chrome message +assert.true( + firefoxMessages.map((m) => m.getText()).includes('Hi, I am Chrome') +) +``` + +In that example the `myFirefoxBrowser` instance will start waiting on a messages once the `myChromeBrowser` instance clicked on the send button. Multiremote makes it easy and convenient to control multiple browser either doing the same thing in parallel or something different. + +**Note:** Multiremote is not meant to execute all your tests in parallel. It should help you to coordinate more than one browser for sophisticated integration tests. \ No newline at end of file diff --git a/website/translated_docs/de/Options.md b/website/translated_docs/de/Options.md new file mode 100644 index 00000000000..bb161fd5e9b --- /dev/null +++ b/website/translated_docs/de/Options.md @@ -0,0 +1,174 @@ +--- +id: options +title: Options +--- +WebdriverIO is not only a WebDriver protocol binding like Selenium. It is a full test framework that comes with a lot of additional features and utilities. It is based on the [webdriver](https://www.npmjs.com/package/webdriver) package which is a lightweight, non-opinionated implementation of the WebDriver specification including mobile commands supported by Appium. WebdriverIO takes the protocol commands and creates smart user commands that make it easier to use the protocol for test automation. + +WebdriverIO enhances the WebDriver package with additional commands. They share the same set of options when run in a standalone script. When running tests using `@wdio/cli` (wdio testrunner) some additional options are available that belong into the `wdio.conf.js`. + +## WebDriver Options + +The following options are defined: + +### protocol + +Protocol to use when communicating with the driver server. + +Type: `String` +Default: `http` + +### host + +Host of your driver server. + +Type: `String` +Default: `0.0.0.0` + +### port + +Port your driver server is on. + +Type: `Number` +Default: `4444` + +### path + +Path to driver server endpoint. + +Type: `String` +Default: `/wd/hub` + +### queryParams + +Query paramaters that are propagated to the driver server. + +Type: `Object` +Default: `null` + +### capabilities + +Defines the capabilities you want to run in your WebDriver session. Check out the [WebDriver Protocol](https://w3c.github.io/webdriver/#capabilities) for more details. If you run an older driver that doesn't support WebDriver you need to apply the [JSONWireProtocol capabilities](https://github.com/SeleniumHQ/selenium/wiki/DesiredCapabilities) to successfuly run a session. Also a useful utility is the 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. + +Type: `Object` +Default: `{ browserName: 'firefox' }` + + +**Example:** + +```js +{ + browserName: 'chrome', // options: `firefox`, `chrome`, `opera`, `safari` + browserVersion: '27.0', // browser version + platformName: 'Windows 10' // OS platform +} +``` + +To run web or native tests on mobile devices capabilities differ from the WebDriver protocol. Have a look into the [Appium Docs](http://appium.io/docs/en/writing-running-appium/caps/) for more details. + +### logLevel + +Level of logging verbosity. + +Type: `String` +Default: `info` +Options: `trace` | `debug` | `info` | `warn` | `error` + +### 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. + +Type: `String|writeable stream` +Default: `null` + +### connectionRetryTimeout + +Timeout for any request to the Selenium server + +Type: `Number` +Default: `90000` + +### connectionRetryCount + +Count of request retries to the Selenium server + +Type: `Number` +Default: `3` + +* * * + +## WDIO Options + +The following options are defined for running WebdriverIO with the `@wdio/cli` testrunner: + +### specs + +Define specs for test execution. + +Type: `String[]` +Default: `[]` + +### exclude + +Exclude specs from test execution. + +Type: `String[]` +Default: `[]` + +### suites + +An object describing various of suites that can be specified when applying the `--suite` option to the `wdio` cli command. + +Type: `Object` +Default: `{}` + +### baseUrl + +Shorten `url` command calls by setting a base url. If your `url` parameter starts with `/`, the base url gets prepended, not including the path portion of your baseUrl. If your `url` parameter starts without a scheme or `/` (like `some/path`), the base url gets prepended directly. + +Type: `String` +Default: `null` + +### 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). *Note*: Please be aware that when using a third party test runner such as Mocha, additional configuration might be required. + +Type: `Number` +Default: `0` (don't bail, run all tests) + +### waitforTimeout + +Default timeout for all waitForXXX commands. Note the lowercase `f`. This timeout **only** affects commands starting with waitForXXX and their default wait time. To increase the timeout of the test please see the framework docs. + +Type: `Number` +Default: `3000` + +### waitforInterval + +Default interval for all waitForXXX commands to check if an expected state (e.g. visibility) has been changed. + +Type: `Number` +Default: `500` + +### framework + +Defines the test framework to be used by the wdio testrunner. + +Type: `String` +Default: `mocha` Options: `mocha` | `jasmine` | `cucumber` + +### reporters + +List of reporters to use. A reporter can be either a string or an array where the first element is a string with the reporter name and the second element an object with reporter options. + +Type: `String[]|Object[]` +Default: `[]` Example: + +```js +reporters: [ + 'dot', + ['spec', { + outputDir: __dirname + '/reports', + otherOption: 'foobar' + }] +] +``` \ No newline at end of file diff --git a/website/translated_docs/de/OrganizingTestSuites.md b/website/translated_docs/de/OrganizingTestSuites.md new file mode 100644 index 00000000000..8742cc717ac --- /dev/null +++ b/website/translated_docs/de/OrganizingTestSuites.md @@ -0,0 +1,158 @@ +--- +id: organizingsuites +title: Organizing Test Suite +--- +While your project is growing you will inevitably add more and more integration tests. This will increase your build time and will also slow down your productivity. To prevent this you should start to run your tests in parallel. You might have already recognised that WebdriverIO creates for each spec (or feature file in cucumber) a single WebDriver session. In general, you should try to test a single feature in your app in one spec file. Try to not have too many or too few tests in one file. However, there is no golden rule about that. + +Once you get more and more spec files you should start running them concurrently. To do so you can adjust the `maxInstances` property in your config file. WebdriverIO allows you to run your tests with maximum concurrency meaning that no matter how many files and tests you have, they could run all in parallel. Though there are certain limits (computer CPU, concurrency restrictions). + +> Let's say you have 3 different capabilities (Chrome, Firefox, and Safari) and you have set maxInstances to 1, the wdio test runner will spawn 3 processes. Therefore, if you have 10 spec files and you set maxInstances to 10; all spec files will get tested at the same time and 30 processes will get spawned. + +You can define the `maxInstance` property globally to set the attribute for all browser. If you run your own WebDriver grid it could be that you have more capacity for one browser than for an other one. In this case you can limit the `maxInstance` in your capability object: + +```js +// wdio.conf.js +exports.config = { + // ... + // set maxInstance for all browser + maxInstances: 10, + // ... + capabilities: [{ + browserName: "firefox" + }, { + // maxInstances can get overwritten per capability. So if you have an in-house WebDriver + // grid with only 5 firefox instance available you can make sure that not more than + // 5 instance gets started at a time. + browserName: 'chrome' + }], + // ... +} +``` + +## Inherit From Main Config File + +If you run your test suite in multiple environments (e.g. dev and integration) it could be helpful to have multiple configuration files to keep them easy manageable. Similar to the [page object concept](PageObjects.md) you first create a main config file. It contains all configurations you share across environments. Then for each environment you can create a file and supplement the information from the main config file with environment specific ones: + +```js +// wdio.dev.config.js +import merge from 'deepmerge'; +import wdioConf from './wdio.conf.js'; + +// have main config file as default but overwrite environment specific information +exports.config = merge(wdioConf.config, { + capabilities: [ + // more caps defined here + // ... + ], + + // run tests on sauce instead locally + user: process.env.SAUCE_USERNAME, + key: process.env.SAUCE_ACCESS_KEY, + services: ['sauce'] +}, { clone: false }); + +// add an additional reporter +exports.config.reporters.push('allure'); +``` + +## Group Test Specs + +You can easily group test specs in suites and run single specific suites instead of all of them. To do so you first need to define your suites in your wdio config: + +```js +// wdio.conf.js +exports.config = { + // define all tests + specs: ['./test/specs/**/*.spec.js'], + // ... + // define specific suites + suites: { + login: [ + './test/specs/login.success.spec.js', + './test/specs/login.failure.spec.js' + ], + otherFeature: [ + // ... + ] + }, + // ... +} +``` + +Now, if you want to only run a single suite, you can pass the suite name as cli argument like: + +```sh +$ wdio wdio.conf.js --suite login +``` + +or run multiple suites at once: + +```sh +$ wdio wdio.conf.js --suite login --suite otherFeature +``` + +## Run Selected Tests + +In some cases, you may wish to only execute a single test or a subset of your suites. With the `--spec` parameter you can specify which suite (Mocha, Jasmine) or feature (Cucumber) should be run. For example if you only want to run your login test, do: + +```sh +$ wdio wdio.conf.js --spec ./test/specs/e2e/login.js +``` + +or run multiple specs at once: + +```sh +$ wdio wdio.conf.js --spec ./test/specs/signup.js --spec ./test/specs/forgot-password.js +``` + +If the spec passed in is not a path to a spec file, it is used as a filter for the spec file names defined in your configuration file. To run all specs with the word 'dialog' in the spec file names, you could use: + +```sh +$ wdio wdio.conf.js --spec dialog +``` + +Note that each test file is running in a single test runner process. Since we don't scan files in advance (see the next section for information on piping filenames to `wdio`) you *can't* use for example `describe.only` at the top of your spec file to say Mocha to only run that suite. This feature will help you though to do that in the same way. + +## Exclude Selected Tests + +When needed, if you need to exclude particular spec file(s) from a run, you can use the `--exclude` parameter (Mocha, Jasmine) or feature (Cucumber). For example if you want to exclude your login test from the test run, do: + +```sh +$ wdio wdio.conf.js --exclude ./test/specs/e2e/login.js +``` + +or exclude multiple spec files: + +```sh +$ wdio wdio.conf.js --exclude ./test/specs/signup.js --exclude ./test/specs/forgot-password.js +``` + +or exclude a spec file when filtering using a suite: + +```sh +$ wdio wdio.conf.js --suite login --exclude ./test/specs/e2e/login.js +``` + +## Run Suites and Test Specs + +This will allow you to run an entire suite along with individual spec's. + +```sh +$ wdio wdio.conf.js --suite login --spec ./test/specs/signup.js +``` + +## Run Multiple, Specific Test Specs + +It is sometimes necessary—in the context of continuous integration and otherwise—to specify multiple sets of specs to be run at runtime. WebdriverIO's `wdio` command line utility will accept piped input in the form of filenames (from `find`, `grep`, or others). These filenames will override the list of glob patterns or filenames specified in the configuration file's `spec` list. + +```sh +$ grep -r -l --include "*.js" "myText" | wdio wdio.conf.js +``` + +***Note:** This will* not *override the `--spec` flag for running a single spec.* + +## Stop testing after failure + +With the `bail` option you can specify when WebdriverIO should stop the test run after test failures. This can be helpful when you have a big test suite and want to avoid long test runs when you already know that your build will break. The option expects a number that specifies after how many spec failures it should stop the whole test run. The default is `0` meaning that it always runs all tests specs it can find. + +Please see [Options Page](Options.md) for additional information on the bail configuration. \ No newline at end of file diff --git a/website/translated_docs/de/PageObjects.md b/website/translated_docs/de/PageObjects.md new file mode 100644 index 00000000000..70d4a2e3fc9 --- /dev/null +++ b/website/translated_docs/de/PageObjects.md @@ -0,0 +1,109 @@ +--- +id: pageobjects +title: Page Object Pattern +--- +The new version (v4) of WebdriverIO was designed with Page Object Pattern support in mind. By introducing the "elements as first class citizens" principle it is now possible to build up large test suites using this pattern. There are no additional packages required to create page objects. It turns out that `Object.create` provides all necessary features we need: + +- inheritance between page objects +- lazy loading of elements +- encapsulation of methods and actions + +The goal behind page objects is to abstract any page information away from the actual tests. Ideally you should store all selectors or specific instructions that are unique for a certain page in a page object, so that you still can run your test after you've completely redesigned your page. + +First off we need a main page object that we call `Page`. It will contain general selectors or methods all page objects will inherit from. Apart from all child page objects `Page` is created using the prototype model: + +```js +export default class Page { + constructor() { + this.title = 'My Page'; + } + + open(path) { + browser.url(path); + } +} +``` + +We will always export an instance of a page object and never create that instance in the test. Since we are writing end to end tests we always see the page as a stateless construct the same way as each http request is a stateless construct. Sure, the browser can carry session information and therefore can display different pages based on different sessions, but this shouldn't be reflected within a page object. These state changes should emerge from your actual tests. + +Let's start testing the first page. For demo purposes we use [The Internet](http://the-internet.herokuapp.com) website by [Elemental Selenium](http://elementalselenium.com/) as guinea pig. Let's try to build a page object example for the [login page](http://the-internet.herokuapp.com/login). First step is to write all important selectors that are required in our `login.page` object as getter functions. As mentioned above we are using the `Object.create` method to inherit the prototype of our main page: + +```js +// login.page.js +import Page from './page'; + +class LoginPage extends Page { + + get username() { return $('#username'); } + get password() { return $('#password'); } + get submitBtn() { return $('form button[type="submit"]'); } + get flash() { return $('#flash'); } + get headerLinks() { return $$('#header a'); } + + open() { + super.open('login'); + } + + submit() { + this.submitBtn.click(); + } + +} + +export default new LoginPage(); +``` + +Defining selectors in getter functions might look a bit verbose but it is really useful. These functions get evaluated when you actually access the property and not when you generate the object. With that you always request the element before you do an action on it. + +WebdriverIO internally remembers the last result of a command. If you chain an element command with an action command it finds the element from the previous command and uses the result to execute the action. With that you can remove the selector (first parameter) and the command looks as simple as: + +```js +LoginPage.username.setValue('Max Mustermann'); +``` + +which is basically the same thing as: + +```js +var elem = $('#username'); +elem.setValue('Max Mustermann'); +``` + +or + +```js +$('#username').setValue('Max Mustermann'); +``` + +After we've defined all required elements and methods for the page we can start to write the test for it. All we need to do to use the page object is to require it and that's it. The `Object.create` method returns an instance of that page so we can start using it right away. By adding an additional assertion framework you can make your tests even more expressive: + +```js +// login.spec.js +import { expect } 'chai'; +import LoginPage '../pageobjects/login.page'; + +describe('login form', () => { + it('should deny access with wrong creds', () => { + LoginPage.open(); + LoginPage.username.setValue('foo'); + LoginPage.password.setValue('bar'); + LoginPage.submit(); + + expect(LoginPage.flash.getText()).to.contain('Your username is invalid!'); + }); + + it('should allow access with correct creds', () => { + LoginPage.open(); + LoginPage.username.setValue('tomsmith'); + LoginPage.password.setValue('SuperSecretPassword!'); + LoginPage.submit(); + + expect(LoginPage.flash.getText()).to.contain('You logged into a secure area!'); + }); +}); +``` + +From the structural side it makes sense to separate spec files and page objects and put them into different directories. Additionally you can give each page object the ending: `.page.js`. This way it is easy to figure out that you actually require a page object if you execute `var LoginPage = require('../pageobjects/form.page');`. + +This is the basic principle of how to write page objects with WebdriverIO. Note that you can build up way more complex page object structures than this. For example have specific page objects for modals or split up a huge page object into different sections objects that inherit from the main page object. The pattern gives you really a lot of opportunities to encapsulate page information from your actual tests, which is important to keep your test suite structured and clear in times where the project and number of tests grows. + +You can find this and some more page object examples in the [example folder](https://github.com/webdriverio/webdriverio/tree/master/examples/pageobject) on GitHub. \ No newline at end of file diff --git a/website/translated_docs/de/Proxy.md b/website/translated_docs/de/Proxy.md new file mode 100644 index 00000000000..be697584c3d --- /dev/null +++ b/website/translated_docs/de/Proxy.md @@ -0,0 +1,51 @@ +--- +id: proxy +title: Proxy Setup +--- +You can tunnel two different types of request through a proxy: + +- connection between your test script and the browser driver (or WebDriver endpoint) +- connection between the browser and the internet + +## Proxy Between Driver And Test + +If your company has a corporate proxy (e.g. on `http://my.corp.proxy.com:9090`) for all outgoing requests you can set it using the `PROXY` environment variable as explained in the [request module](https://github.com/request/request#controlling-proxy-behaviour-using-environment-variables). Before you start the test make sure you exported the variable in the terminal as follows: + +```sh +$ export HTTP_PROXY=http://my.corp.proxy.com:9090 +$ export HTTPS_PROXY=https://my.corp.proxy.com:9090 +$ wdio wdio.conf.js +``` + +If you use [Sauce Connect Proxy](https://wiki.saucelabs.com/display/DOCS/Sauce+Connect+Proxy) start it via: + +```sh +$ sc -u $SAUCE_USERNAME -k $SAUCE_ACCESS_KEY --no-autodetect -p http://my.corp.proxy.com:9090 +``` + +## Proxy Between Browser And Internet + +In order to tunnel the connection between the browser and the internet you can set up a proxy which can be useful e.g. to capture network information and other data using tools like [BrowserMob Proxy](https://github.com/lightbody/browsermob-proxy). The proxy parameters can be applied via the standard capabilities the following way: + +```js +// wdio.conf.js + +exports.config = { + // ... + capabilities: [{ + browserName: 'chrome', + // ... + proxy: { + proxyType: "manual", + httpProxy: "http://corporate.proxy:8080", + socksUsername: "codeceptjs", + socksPassword: "secret", + noProxy: "127.0.0.1,localhost" + }, + // ... + }], + // ... +} +``` + +For more information see the [WebDriver specification](https://w3c.github.io/webdriver/#proxy). \ No newline at end of file diff --git a/website/translated_docs/de/Retry.md b/website/translated_docs/de/Retry.md new file mode 100644 index 00000000000..6f2f9709ca5 --- /dev/null +++ b/website/translated_docs/de/Retry.md @@ -0,0 +1,77 @@ +--- +id: retry +title: Retry Flaky Tests +--- +You can rerun certain tests with the WebdriverIO testrunner that turn out to be unstable due to e.g. flaky network or race conditions. However it is not recommended to just increase the rerun rate if tests become unstable. + +## Rerun suites in MochaJS + +Since version 3 of MochaJS you can rerun whole test suites (everything inside an `describe` block). If you use Mocha you should favor this retry mechanism instead of the WebdriverIO implementation that only allows you to rerun certain test blocks (everything within an `it` block). Here is an example how to rerun a whole suite in MochaJS: + +```js +describe('retries', function() { + // Retry all tests in this suite up to 4 times + this.retries(4); + + beforeEach(() => { + browser.url('http://www.yahoo.com'); + }); + + it('should succeed on the 3rd try', function () { + // Specify this test to only retry up to 2 times + this.retries(2); + console.log('run'); + expect(browser.isVisible('.foo')).to.eventually.be.true; + }); +}); +``` + +## Rerun single tests in Jasmine or Mocha + +To rerun a certain test block just apply the number of reruns as last parameter after the test block function: + +```js +describe('my flaky app', () => { + /** + * spec that runs max 4 times (1 actual run + 3 reruns) + */ + it('should rerun a test at least 3 times', () => { + // ... + }, 3); +}); +``` + +The same works for hooks too: + +```js +describe('my flaky app', () => { + /** + * hook that runs max 2 times (1 actual run + 1 rerun) + */ + beforeEach(() => { + // ... + }, 1) + + // ... +}); +``` + +It is **not** possible to rerun whole suites with Jasmine, only hooks or test blocks. + +## Rerun Step Definitions in Cucumber + +To define a rerun rate for a certain step definitions just apply a retry option to it, like: + +```js +module.exports = function () { + /** + * step definition that runs max 3 times (1 actual run + 2 reruns) + */ + this.Given(/^some step definition$/, { wrapperOptions: { retry: 2 } }, () => { + // ... + }) + // ... +}) +``` + +Reruns can only be defined in your step definitions file and not in your feature file. \ No newline at end of file diff --git a/website/translated_docs/de/Selectors.md b/website/translated_docs/de/Selectors.md new file mode 100644 index 00000000000..78e6f1b3b19 --- /dev/null +++ b/website/translated_docs/de/Selectors.md @@ -0,0 +1,252 @@ +--- +id: selectors +title: Selectors +--- +The JsonWireProtocol provides several selector strategies to query an element. WebdriverIO simplifies them to keep selecting elements simple. The following selector types are supported: + +## CSS Query Selector + +```js +const elem = $('h2.subheading a'); +elem.click(); +``` + +## Link Text + +To get an anchor element with a specific text in it, query the text starting with an equal (=) sign. For example: + +```html +WebdriverIO +``` + +You can query this element by calling: + +```js +const link = $('=WebdriverIO'); +console.log(link.getText()); // outputs: "WebdriverIO" +console.log(link.getAttribute('href')); // outputs: "http://webdriver.io" +``` + +## Partial Link Text + +To find a anchor element whose visible text partially matches your search value, query it by using `*=` in front of the query string (e.g. `*=driver`) + +```html +WebdriverIO +``` + +You can query this element by calling: + +```js +const link = $('*=driver'); +console.log(link.getText()); // outputs: "WebdriverIO" +``` + +## Element with certain text + +The same technique can be applied to elements as well, e.g. query a level 1 heading with the text "Welcome to my Page": + +```html +

Welcome to my Page

+``` + +You can query this element by calling: + +```js +const header = $('h1=Welcome to my Page'); +console.log(header.getText()); // outputs: "Welcome to my Page" +console.log(header.getTagName()); // outputs: "h1" +``` + +or using query partial text + +```js +const header = $('h1*=Welcome'); +console.log(header.getText()); // outputs: "Welcome to my Page" +``` + +The same works for ids and class names: + +```html +WebdriverIO is the best +``` + +You can query this element by calling: + +```js +const classNameAndText = $('.someElem=WebdriverIO is the best'); +console.log(classNameAndText.getText()); // outputs: "WebdriverIO is the best" + +const idAndText = $('#elem=WebdriverIO is the best'); +console.log(idAndText.getText()); // outputs: "WebdriverIO is the best" + +const classNameAndPartialText = $('.someElem*=WebdriverIO'); +console.log(classNameAndPartialText.getText()); // outputs: "WebdriverIO is the best" + +const idAndPartialText = $('#elem*=WebdriverIO'); +console.log(idAndPartialText.getText()); // outputs: "WebdriverIO is the best" +``` + +## Tag Name + +To query an element with a specific tag name use `` or `` + +```html +WebdriverIO is the best +``` + +You can query this element by calling: + +```js +const classNameAndText = $(''); +console.log(classNameAndText.getText()); // outputs: "WebdriverIO is the best" +``` + +## xPath + +It is also possible to query elements via a specific [xPath](https://developer.mozilla.org/en-US/docs/Web/XPath). The selector has to have a format like `//BODY/DIV[6]/DIV[1]/SPAN[1]`. + +```html + + +

foobar

+

barfoo

+ + +``` + +You can query the second paragraph by calling: + +```js +const paragraph = $('//BODY/P[1]'); +console.log(paragraph.getText()); // outputs: "barfoo" +``` + +You can use xPath to also traverse up and down the DOM tree, e.g. + +```js +const parent = paragraph.$('..'); +console.log(parent.getTagName()); // outputs: "body" +``` + +## JS Function + +You can also use JS functions to fetch elements using web native APIs. This of course is only supported in a web environment (e.g. browser or web context in mobile). Given the following HTML structure: + +```html + + +

foobar

+

barfoo

+ + +``` + +You can query the sibling element of `#elem` as follows: + +```js +const elem = $('#elem') // or $(() => document.getElementById('elem')) +elem.$(() => this.nextSibling.nextSibling) // (first sibling is #text with value ("↵")) +``` + +## Mobile Selectors + +For (hybrid/native) mobile testing you have to use mobile strategies and use the underlying device automation technology directly. This is especially useful when a test needs some fine-grained control over finding elements. + +### Android UiAutomator + +Android’s UI Automator framework provides a number of ways to find elements. You can use the [UI Automator API](https://developer.android.com/tools/testing-support-library/index.html#uia-apis), in particular the [UiSelector class](https://developer.android.com/reference/android/support/test/uiautomator/UiSelector.html) to locate elements. In Appium you send the Java code, as a string, to the server, which executes it in the application’s environment, returning the element or elements. + +```js +const selector = 'new UiSelector().text("Cancel").className("android.widget.Button")'; +const Button = $(`android=${selector}`); +Button.click(); +``` + +### iOS UIAutomation + +When automating an iOS application, Apple’s [UI Automation framework](https://developer.apple.com/library/prerelease/tvos/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/UIAutomation.html) can be used to find elements. This JavaScript [API](https://developer.apple.com/library/ios/documentation/DeveloperTools/Reference/UIAutomationRef/index.html#//apple_ref/doc/uid/TP40009771) has methods to access to the view and everything on it. + +```js +const selector = 'UIATarget.localTarget().frontMostApp().mainWindow().buttons()[0]'; +const Button = $(`ios=${selector}`); +Button.click(); +``` + +You can also use predicate searching within iOS UI Automation in Appium, to control element finding even further. See [here](https://github.com/appium/appium/blob/master/docs/en/writing-running-appium/ios/ios-predicate.md) for details. + +### iOS XCUITest predicate strings and class chains + +With iOS 10 and above (using the XCUITest driver), you can use [predicate strings](https://github.com/facebook/WebDriverAgent/wiki/Predicate-Queries-Construction-Rules): + +```js +const selector = 'type == \'XCUIElementTypeSwitch\' && name CONTAINS \'Allow\''; +const Switch = $(`ios=predicate=${selector}`); +Switch.click(); +``` + +And [class chains](https://github.com/facebook/WebDriverAgent/wiki/Class-Chain-Queries-Construction-Rules): + +```js +const selector = '**/XCUIElementTypeCell[`name BEGINSWITH "D"`]/**/XCUIElementTypeButton'; +const Button = $(`ios=chain=${selector}`); +Button.click(); +``` + +### Accessibility ID + +The `accessibility id` locator strategy is designed to read a unique identifier for a UI element. This has the benefit of not changing during localization or any other process that might change text. In addition, it can be an aid in creating cross-platform tests, if elements that are functionally the same have the same accessibility id. + +- For iOS this is the `accessibility identifier` laid out by Apple [here](https://developer.apple.com/library/prerelease/ios/documentation/UIKit/Reference/UIAccessibilityIdentification_Protocol/index.html). +- For Android the `accessibility id` maps to the `content-description` for the element, as described [here](https://developer.android.com/training/accessibility/accessible-app.html). + +For both platforms getting an element, or multiple elements, by their `accessibility id` is usually the best method. It is also the preferred way, in replacement of the deprecated `name` strategy. + +```js +const elem = $('~my_accessibility_identifier'); +elem.click(); +``` + +### Class Name + +The `class name` strategy is a `string` representing a UI element on the current view. + +- For iOS it is the full name of a [UIAutomation class](https://developer.apple.com/library/prerelease/tvos/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/UIAutomation.html), and will begin with `UIA-`, such as `UIATextField` for a text field. A full reference can be found [here](https://developer.apple.com/library/ios/navigation/#section=Frameworks&topic=UIAutomation). +- For Android it is the fully qualified name of a [UI Automator](https://developer.android.com/tools/testing-support-library/index.html#UIAutomator) [class](https://developer.android.com/reference/android/widget/package-summary.html), such `android.widget.EditText` for a text field. A full reference can be found [here](https://developer.android.com/reference/android/widget/package-summary.html). + +```js +// iOS example +$('UIATextField').click(); +// Android example +$('android.widget.DatePicker').click(); +``` + +## Chain Selectors + +If you want to be more specific in your query, you can chain your selector until you've found the right element. If you call element before your actual command, WebdriverIO starts query from that element. For example if you have a DOM structure like: + +```html +
+
+ + + +
+
+ + + +
+
+ + + +
+
+``` + +And you want to add product B to the cart it would be difficult to do that just by using the CSS selector. With selector chaining it gets way easier as you can narrow down the desired element step by step: + +```js +$('.row .entry:nth-child(1)').$('button*=Add').click(); +``` \ No newline at end of file diff --git a/website/translated_docs/de/SetupTypes.md b/website/translated_docs/de/SetupTypes.md new file mode 100644 index 00000000000..f3f18bfcbd5 --- /dev/null +++ b/website/translated_docs/de/SetupTypes.md @@ -0,0 +1,57 @@ +--- +id: setuptypes +title: How to setup WebdriverIO +--- +WebdriverIO can be used for various purposes. It implements the Webdriver protocol API and can run a 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 + +Probably the 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 +const { remote } = require('webdriverio'); + +(async () => { + const browser = await remote({ + logLevel: 'trace', + capabilities: { + browserName: 'chrome' + } + }) + + await browser.url('https://duckduckgo.com/') + + const inputElem = await browser.$('#search_form_input_homepage') + await inputElem.setValue('WebdriverIO') + + const submitBtn = await browser.$('#search_button_homepage') + await submitBtn.click() + + console.log(await browser.getTitle()) // outputs: "Title is: WebdriverIO (Software) at DuckDuckGo" + + await browser.deleteSession() +})().catch((e) => console.error(e)) +``` + +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 a 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 the same example from above written as a test spec and executed by wdio: + +```js +describe('DuckDuckGo search', () => { + it('searches for WebdriverIO', () => { + browser.url('https://duckduckgo.com/') + + $('#search_form_input_homepage').setValue('WebdriverIO') + $('#search_button_homepage').click() + + const 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](GettingStarted.md) section for more information. \ No newline at end of file diff --git a/website/translated_docs/de/Timeouts.md b/website/translated_docs/de/Timeouts.md new file mode 100644 index 00000000000..2144ccfae16 --- /dev/null +++ b/website/translated_docs/de/Timeouts.md @@ -0,0 +1,124 @@ +--- +id: timeouts +title: Timeouts +--- +Each command in WebdriverIO is an asynchronous operation where a request is fired to the Selenium server (or a cloud service like [Sauce Labs](https://saucelabs.com/)), and its response contains the result once the action has completed or failed. Therefore time is a crucial component in the whole testing process. When a certain action depends on the state of a different action, you need to make sure that they get executed in the right order. Timeouts play an important role when dealing with these issues. + +## Selenium timeouts + +### Session Script Timeout + +A session has an associated session script timeout that specifies a time to wait for asynchronous scripts to run. Unless stated otherwise it is 30 seconds. You can set this timeout via: + +```js +browser.setTimeout({ 'script': 60000 }); +browser.executeAsync((done) => { + console.log('this should not fail'); + setTimeout(done, 59000); +}); +``` + +### Session Page Load Timeout + +A session has an associated session page load timeout that specifies a time to wait for the page loading to complete. Unless stated otherwise it is 300,000 milliseconds. You can set this timeout via: + +```js +browser.setTimeout({ 'pageLoad': 10000 }); +``` + +> The `pageLoad` keyword is a part of the official WebDriver [specification](https://www.w3.org/TR/webdriver/#set-timeouts), but might not be [supported](https://github.com/seleniumhq/selenium-google-code-issue-archive/issues/687) for your browser (the previous name is `page load`). + +### Session Implicit Wait Timeout + +A session has an associated session implicit wait timeout that specifies a time to wait for the implicit element location strategy when locating elements using the [`findElement`](/docs/api/webdriver.html#findelement) or [`findElements`](/docs/api/webdriver.html#findelements) commands (respectively [`$`](/docs/api/browser/$.html) or [`$$`](/docs/api/browser/$$.html) when running WebdriverIO with or without wdio testrunner). Unless stated otherwise it is zero milliseconds. You can set this timeout via: + +```js +browser.setTimeout({ 'implicit': 5000 }); +``` + +## WebdriverIO related timeouts + +### WaitForXXX timeout + +WebdriverIO provides multiple commands to wait on elements to reach a certain state (e.g. enabled, visible, existing). These commands take a selector argument and a timeout number which declares how long the instance should wait for that element to reach the state. The `waitforTimeout` option allows you to set the global timeout for all waitFor commands so you don't need to set the same timeout over and over again. Note the lowercase `f`. + +```js +// wdio.conf.js +exports.config = { + // ... + waitforTimeout: 5000, + // ... +}; +``` + +In your test you now can do this: + +```js +const myElem = $('#myElem'); +myElem.waitForVisible(); + +// you can also overwrite the default timeout if needed +myElem.waitForVisible(10000); +``` + +## Framework related timeouts + +Also the testing framework you use with WebdriverIO has to deal with timeouts especially since everything is asynchronous. It ensures that the test process don't get stuck if something went wrong. By default the timeout is set to 10 seconds which means that a single test should not take longer than that. A single test in Mocha looks like: + +```js +it('should login into the application', () => { + browser.url('/login'); + + const form = $('form'); + const username = $('#username'); + const password = $('#password'); + + username.setValue('userXY'); + password.setValue('******'); + form.submit(); + + expect(browser.getTitle()).to.be.equal('Admin Area'); +}); +``` + +In Cucumber the timeout applies to a single step definition. However if you want to increase the timeout because your test takes longer than the default value you need to set it in the framework options. This is for Mocha: + +```js +// wdio.conf.js +exports.config = { + // ... + framework: 'mocha', + mochaOpts: { + timeout: 20000 + }, + // ... +} +``` + +For Jasmine: + +```js +// wdio.conf.js +exports.config = { + // ... + framework: 'jasmine', + jasmineNodeOpts: { + defaultTimeoutInterval: 20000 + }, + // ... +} +``` + +and for Cucumber: + +```js +// wdio.conf.js +exports.config = { + // ... + framework: 'cucumber', + cucumberOpts: { + timeout: 20000 + }, + // ... +} +``` \ No newline at end of file diff --git a/website/translated_docs/de/TypeScript.md b/website/translated_docs/de/TypeScript.md new file mode 100644 index 00000000000..a1bd7c2df88 --- /dev/null +++ b/website/translated_docs/de/TypeScript.md @@ -0,0 +1,39 @@ +--- +id: typescript +title: TypeScript Setup +--- +Similar to Babel setup, you can register [TypeScript](http://www.typescriptlang.org/) to compile your .ts files in your before hook of your config file. You will need [ts-node](https://github.com/TypeStrong/ts-node) and [tsconfig-paths](https://github.com/dividab/tsconfig-paths) as the installed devDependencies. + +```js + before: function() { + require('ts-node/register'); + }, +``` + +Similarly for mocha: + +```js + mochaOpts: { + ui: 'bdd', + compilers: [ + 'ts-node/register', + 'tsconfig-paths/register' + ] + }, +``` + +and: + +```json + //tsconfig.json + "compilerOptions": { + "baseUrl": ".", + "paths": { + "*": [ "./*" ], + "src/*": ["./src/*"] + } + }, + "include": [ + "./src/**/*.ts" + ] +``` \ No newline at end of file diff --git a/website/translated_docs/de/WatchFiles.md b/website/translated_docs/de/WatchFiles.md new file mode 100644 index 00000000000..fb3f3b08f84 --- /dev/null +++ b/website/translated_docs/de/WatchFiles.md @@ -0,0 +1,25 @@ +--- +id: watcher +title: Watch Test Files +--- +With the WDIO testrunner you can watch files while you are working on them. They automatically rerun if you change either something in your app or in your test files. By adding a `--watch` flag when calling the `wdio` command the testrunner will wait for file changes after it ran all tests, e.g. + +```sh +$ wdio wdio.conf.js --watch +``` + +By default it only watches for changes in your `specs` files. However by setting a `filesToWatch` property in your `wdio.conf.js` that contains a list of file paths (globbing supported) it will also watch for these files to be changed in order to rerun the whole suite. This is useful if you want to automatically rerun all your tests if you have changed your application code, e.g. + +```js +// wdio.conf.js +export.config = { + // ... + filesToWatch: [ + // watch for all JS files in my app + './src/app/**/*.js' + ], + // ... +} +``` + +**Note:** ensure that you run as much tests in parallel as possible. E2E tests are by nature slow and rerunning tests is only useful if you can keep the individual testrun time short. In order to save time the testrunner keeps the WebDriver sessions alive while waiting for file changes. Make sure your WebDriver backend can be modified so that it doesn't automatically close the session if no command was executed after some specific time. \ No newline at end of file diff --git a/website/translated_docs/de/repl.md b/website/translated_docs/de/repl.md new file mode 100644 index 00000000000..2a8b5dfb058 --- /dev/null +++ b/website/translated_docs/de/repl.md @@ -0,0 +1,21 @@ +--- +id: repl +title: REPL interface +--- +With `v4.5.0` WebdriverIO introduces a [REPL](https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop) interface that helps you to not only discover the framework API but also debug and inspect your tests. It can be used in multiple ways. First you can use it as CLI command and spawn a WebDriver session from the command line, e.g. + +```sh +$ wdio repl chrome +``` + +This would open a Chrome browser that you can control with the REPL interface. Make sure you have a browser driver running on port `4444` in order to initiate the session. If you have a [SauceLabs](https://saucelabs.com) (or other cloud vendor) account you can also directly run the browser on your command line in the cloud via: + +```sh +$ wdio repl chrome -u $SAUCE_USERNAME -k $SAUCE_ACCESS_KEY +``` + +You can apply any options (see `wdio --help`) available for your REPL session. + +![WebdriverIO REPL](http://webdriver.io/images/repl.gif) + +Another way to use the REPL is in between your tests via the [`debug`](/api/utility/debug.html) command. It will stop the browser when executed and enables you to jump into the application (e.g. to the dev tools) or control the browser from the command line. This is helpful when some commands don't trigger a certain action as expected. With the REPL you can then try out the commands to see which are working most reliable. \ No newline at end of file diff --git a/website/translated_docs/es-ES/API.md b/website/translated_docs/es-ES/API.md new file mode 100644 index 00000000000..a5ca0164126 --- /dev/null +++ b/website/translated_docs/es-ES/API.md @@ -0,0 +1,43 @@ +--- +id: api +title: API Docs +--- +Welcome to the WebdriverIO docs page. These pages contain reference materials for all implemented selenium bindings and commands. WebdriverIO has all [JSONWire protocol](https://github.com/SeleniumHQ/selenium/wiki/JsonWireProtocol) commands implemented and also supports special bindings for [Appium](http://appium.io). + +> **Note:** These are the docs for the latest version (v5.0.0) of WebdriverIO. If you are still using v4 or older please use the legacy docs website [v4.webdriver.io](http://v4.webdriver.io)! + +## Examples + +Each command documentation usually comes with an example that demonstrates the usage of it using WebdriverIO's testrunner running its commands synchronously. If you run WebdriverIO in standalone mode you still can use all commands but need to make sure that the execution order is handled properly by chaining the commands and resolving the promise chain. So instead of assigning the value directly to a variable, as the wdio testrunner allows it: + +```js +it('can handle commands synchronously', () => { + var value = $('#input').getValue(); + console.log(value); // outputs: some value +}); +``` + +you need return the command promise so it gets resolved properly as well as access the value when the promise got resolve: + +```js +it('handles commands as promises', () =>{ + return $('#input').getValue().then((value) => { + console.log(value); // outputs: some value + }); +}); +``` + +Of course you can use Node.JS latest [async/await](https://github.com/yortus/asyncawait) functionality to bring synchronous syntax into your testflow like: + +```js +it('can handle commands using async/await', async function () { + var value = await $('#input').getValue(); + console.log(value); // outputs: some value +}); +``` + +However it is recommended to use the testrunner to scale up your test suite as it comes with a lot of useful add ons like the [Sauce Service](_sauce-service.md) that helps you to avoid writing a lot of boilerplate code by yourself. + +## Contribute + +If you feel like you have a good example for a command, don't hesitate to open a PR and submit it. Just click on the orange button on the top right with the label *"Improve this doc"*. Make sure you understand the way we write these docs by checking the [Contribute](https://github.com/webdriverio/webdriverio/blob/master/CONTRIBUTING.md) section. \ No newline at end of file diff --git a/website/translated_docs/es-ES/Autocompletion.md b/website/translated_docs/es-ES/Autocompletion.md new file mode 100644 index 00000000000..3c586157236 --- /dev/null +++ b/website/translated_docs/es-ES/Autocompletion.md @@ -0,0 +1,41 @@ +--- +id: autocompletion +title: Autocompletion +--- +If you have been writing program code for a while, you probably like autocompletion. Autocomplete is available out of the box in many code editors. However if autocompletion is required for packages that are not installed in the usual locations or are excluded from indexing for some reasons, these too could be added via configuration changes. + +![Autocompletion](/img/autocompletion/0.png) + +[JSDoc](http://usejsdoc.org/) is used for documenting code. It helps to see more additional details about parameters and their types. + +![Autocompletion](/img/autocompletion/1.png) + +Use standard shortcuts *⇧ + ⌥ + SPACE* on IntelliJ Platform to see available documentation: + +![Autocompletion](/img/autocompletion/2.png) + +So, let's start to consider an example of adding autocompletion to code editors on the IntelliJ Platform like WebStorm. + +### Node.js Core modules as External library + +Open *Settings -> Preferences -> Languages & Frameworks -> JavaScript -> Libraries* + +![Autocompletion](/img/autocompletion/3.png) + +Add new library + +![Autocompletion](/img/autocompletion/4.png) + +Add directory with WebdriverIO commands + +![Autocompletion](/img/autocompletion/5.png) ![Autocompletion](/img/autocompletion/6.png) ![Autocompletion](/img/autocompletion/7.png) + +Enter documentation URL + +![Autocompletion](/img/autocompletion/8.png) ![Autocompletion](/img/autocompletion/9.png) ![Autocompletion](/img/autocompletion/10.png) + +### Using TypeScript community stubs (TypeScript definition files) + +WebStorm provides one more workaround for adding coding assistance. It allows you to download [DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped) stubs. + +![Autocompletion](/img/autocompletion/11.png) ![Autocompletion](/img/autocompletion/12.png) \ No newline at end of file diff --git a/website/translated_docs/es-ES/Babel.md b/website/translated_docs/es-ES/Babel.md new file mode 100644 index 00000000000..064065f97c6 --- /dev/null +++ b/website/translated_docs/es-ES/Babel.md @@ -0,0 +1,40 @@ +--- +id: babel +title: Babel Setup +--- +To write tests using next generation JavaScript features you can add [Babel](https://babeljs.io/) as compiler for your test files. For that first, install the necessary Babel dependencies: + + npm install --save-dev @babel/cli @babel/preset-env @babel/register + + +Make sure your [`babel.config.js`](https://babeljs.io/docs/en/config-files) is configured properly. The simplest setup you can use is: + +```js +module.exports = { + presets: [ + ['@babel/preset-env', { + targets: { + node: 8 + } + }] + ] +} +``` + +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'] +}, +``` \ No newline at end of file diff --git a/website/translated_docs/es-ES/BoilerplateProjects.md b/website/translated_docs/es-ES/BoilerplateProjects.md new file mode 100644 index 00000000000..db8f49faf91 --- /dev/null +++ b/website/translated_docs/es-ES/BoilerplateProjects.md @@ -0,0 +1,160 @@ +--- +id: boilerplate +title: Boilerplate Projects +--- +Over the time our community has developed a bunch of boilerplate projects that can be used as inspiration to set up your own test suite. + +## [amiya-pattnaik/webdriverIO-with-cucumberBDD](https://github.com/amiya-pattnaik/webdriverIO-with-cucumberBDD) + +- Framework: Cucumber (v3.x) +- Features: + - Page Objects Model uses with ES6 style class base approach and fully ES6 - ES8 support through Babel + - Examples of multi selector option to query element with more than one selector at a time + - Examples of headless browser execution using - PhantomJS and Chrome + - Integration with BrowserStack + - Support of read/write data from MS-Excel for easy test data management from external data sources with examples + - Database support to any RDBMS (Oracle, MySql, TeraData, Vertica etc.), executing any queries / fetching result set etc. with examples for E2E testing + - Multiple reporting (Spec, Junit, Allure, JSON), plus local view of Junit report(.html) format + - Task manage through Grunt + - Examples with demo app https://search.yahoo.com/ and http://www.phptravels.net, Chai assertion liberary (expect, assert, should) + - Appium specific .config file for playback on mobile device. For one click Appium setup refer [appium-setup-made-easy-OSX](https://github.com/amiya-pattnaik/appium-setup-made-easy-OSX) + +## [amiya-pattnaik/webdriverIO-with-jasmineBDD](https://github.com/amiya-pattnaik/webdriverIO-with-jasmineBDD) + +- Framework: Jasmine (v3.x) +- Features: + - Page Objects Model uses with ES6 style class base approach and fully ES6 - ES8 support through Babel + - Examples of multi selector option to query element with more than one selector at a time + - Examples of headless browser execution using - PhantomJS and Chrome + - Integration with BrowserStack + - Support of read/write data from MS-Excel for easy test data management from external data sources with examples + - Database support to any RDBMS (Oracle, MySql, TeraData, Vertica etc.), executing any queries / fetching result set etc. with examples for E2E testing + - Multiple reporting (Spec, Junit, Allure, JSON), plus local view of Junit report(.html) format + - Task manage through Grunt + - Examples with demo app http://www.phptravels.net + - Appium specific .config file for playback on mobile device. For one click Appium setup refer [appium-setup-made-easy-OSX](https://github.com/amiya-pattnaik/appium-setup-made-easy-OSX) + +## [amiya-pattnaik/webdriverIO-with-mochaBDD](https://github.com/amiya-pattnaik/webdriverIO-with-mochaBDD) + +- Framework: Mocha (v5.x) +- Features: + - Page Objects Model uses with ES6 style class base approach and fully ES6 - ES8 support through Babel + - Examples of multi selector option to query element with more than one selector at a time + - Examples of headless browser execution using - PhantomJS and Chrome + - Integration with BrowserStack + - Support of read/write data from MS-Excel for easy test data management from external data sources with examples + - Database support to any RDBMS (Oracle, MySql, TeraData, Vertica etc.), executing any queries / fetching result set etc. with examples for E2E testing + - Multiple reporting (Spec, Junit, Allure, JSON, Mochawesome, Timeline), plus local view of Junit report(.html) format and Mochawesome report + - Task manage through Grunt + - Examples with demo app http://www.phptravels.net, Chai assertion liberary (expect, assert, should) + - Appium specific .config file for playback on mobile device. For one click Appium setup refer [appium-setup-made-easy-OSX](https://github.com/amiya-pattnaik/appium-setup-made-easy-OSX) + +## [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 implementation + - Intellisense + +## [klamping/wdio-starter-kit](https://github.com/klamping/wdio-starter-kit) + +Boilerplate repo for quick set up of WebdriverIO test scripts with TravisCI, Sauce Labs and Visual Regression Testing + +- Framework: Mocha, Chai +- Features: + - Login & Registration Tests, with Page Objects + - Mocha + - Chai with expect global + - Chai WebdriverIO + - Sauce Labs integration + - Visual Regression Tests + - Local notifications + - ESLint using Semistandard style + - WebdriverIO tuned Gitignore file + +## [webdriverio/appium-boilerplate](https://github.com/webdriverio/appium-boilerplate/) + +Boilerplate project to run Appium tests together with WebdriverIO for: + +- iOS/Android Native Apps +- iOS/Android Hybrid Apps +- Android Chrome and iOS Safari browser + +The boilerplate holds the following things + +- Framework: Jasmine +- Features: + - Configs for: + - iOS and Android app + - iOS and Android browsers + - Helpers for: + - WebView + - Gestures + - Native alerts + - Pickers + - Tests examples for: + - WebView + - Login + - Forms + - Swipe + - Browsers \ No newline at end of file diff --git a/website/translated_docs/es-ES/BrowserObject.md b/website/translated_docs/es-ES/BrowserObject.md new file mode 100644 index 00000000000..12fcc567f9a --- /dev/null +++ b/website/translated_docs/es-ES/BrowserObject.md @@ -0,0 +1,148 @@ +--- +id: browserobject +title: The Browser Object +--- +If you use the wdio test runner you can access the webdriver instance through the global `browser` or `driver` object. The session is initialized by the test runner. The same goes for ending the session. This is also done by the test runner process. + +Besides all commands from the [api](API.md) the browser object provides some more information you might be interested in during your test run: + +## Get Desired Capabilities + +```js +console.log(browser.sessionId); // outputs: "57b15c6ea81d0edb9e5b372da3d9ce28" +console.log(browser.capabilities); +/** + * outputs: + { acceptInsecureCerts: false, + acceptSslCerts: false, + applicationCacheEnabled: false, + browserConnectionEnabled: false, + browserName: 'chrome', + chrome: + { chromedriverVersion: '2.40.565386 (45a059dc425e08165f9a10324bd1380cc13ca363)', + userDataDir: '/var/folders/ns/8mj2mh0x27b_gsdddy1knnsm0000gn/T/.org.chromium.Chromium.mpJ0yc' }, + cssSelectorsEnabled: true, + databaseEnabled: false, + handlesAlerts: true, + hasTouchScreen: false, + javascriptEnabled: true, + locationContextEnabled: true, + mobileEmulationEnabled: false, + nativeEvents: true, + networkConnectionEnabled: false, + pageLoadStrategy: 'normal', + platform: 'Mac OS X', + rotatable: false, + setWindowRect: true, + takesHeapSnapshot: true, + takesScreenshot: true, + unexpectedAlertBehaviour: '', + version: '68.0.3440.106', + webStorageEnabled: true } + */ +``` + +## Get Config Options + +You can always define custom options within you wdio config: + +```js +// wdio.conf.js +exports.config = { + // ... + fakeUser: 'maxmustermann', + fakePassword: 'foobar', + // ... +} +``` + +to then access it in your tests: + +```js +console.log(browser.config); +/** + * outputs: + * { + port: 4444, + protocol: 'http', + waitforTimeout: 10000, + waitforInterval: 250, + coloredLogs: true, + deprecationWarnings: true, + logLevel: 'debug', + baseUrl: 'http://localhost', + connectionRetryTimeout: 90000, + connectionRetryCount: 3, + sync: true, + specs: [ 'err.js' ], + fakeUser: 'maxmustermann', // <-- custom option + fakePassword: 'foobar', // <-- custom option + // ... + */ + +console.log(browser.config.fakeUser); // outputs: "maxmustermann" +``` + +## Mobile Flags + +If you need to modify your test based on whether or not your session runs on a mobile device, you can access the mobile flags to check, e.g.: + +```js +// wdio.conf.js +exports.config = { + // ... + capabilities: { + platformName: 'iOS', + app: 'net.company.SafariLauncher', + udid: '123123123123abc', + deviceName: 'iPhone', + // ... + } + // ... +}; +``` + +In your test you can access these flags like: + +```js +// Note: `driver` is the equivalent to the `browser` object but semantically more correct +// you can choose which global variable you want to use +console.log(driver.isMobile); // outputs: true +console.log(driver.isIOS); // outputs: true +console.log(driver.isAndroid); // outputs: false +``` + +This can be useful if you want to define selectors in your page objects based on the device type, e.g. + +```js +// mypageobject.page.js +import Page from './page'; + +class LoginPage extends Page { + // ... + get username () { + const selectorAndroid = 'new UiSelector().text("Cancel").className("android.widget.Button")'; + const selectorIOS = 'UIATarget.localTarget().frontMostApp().mainWindow().buttons()[0]'; + const selectorType = driver.isAndroid ? 'android' : 'ios'; + const selector = driver.isAndroid ? selectorAndroid : selectorIOS; + return $(`${selectorType}=${selector}`); + } + // ... +} +``` + +You can also use these flags to only run certain tests for certain device types: + +```js +// mytest.e2e.js +describe('my test', () => { + // ... + // only run test with Android devices + if (driver.isAndroid) { + it('tests something only for Android', () => { + // ... + }) + } + // ... +}) +``` \ No newline at end of file diff --git a/website/translated_docs/es-ES/CLI.md b/website/translated_docs/es-ES/CLI.md new file mode 100644 index 00000000000..89ca906dd65 --- /dev/null +++ b/website/translated_docs/es-ES/CLI.md @@ -0,0 +1,94 @@ +--- +id: clioptions +title: WDIO CLI Options +--- +WebdriverIO comes with its own test runner to help you get started with integration testing as quickly as possible. All the fiddling around hooking up WebdriverIO with a test framework belongs to the past. The WebdriverIO runner does all the work for you and helps you to run your tests as efficiently as possible. + +Starting with v5 of WebdriverIO the testrunner will be bundled as a seperated NPM package `@wdio/cli`. To see the command line interface help just type the following command in your terminal: + +```sh +$ npm install @wdio/cli +$ ./node_modules/.bin/wdio --help + +WebdriverIO CLI runner + +Usage: wdio [options] [configFile] +Usage: wdio config +Usage: wdio repl + +config file defaults to wdio.conf.js +The [options] object will override values from the config file. +An optional list of spec files can be piped to wdio that will override +configured specs + +Commands: + wdio.js repl Run WebDriver session in command line + +Options: + --help prints WebdriverIO help menu [boolean] + --version prints WebdriverIO version [boolean] + --host, -h automation driver host address [string] + --port, -p automation driver port [number] + --user, -u username if using a cloud service as automation backend + [string] + --key, -k corresponding access key to the user [string] + --watch watch specs for changes [boolean] + --logLevel, -l level of logging verbosity + [choices: "trace", "debug", "info", "warn", "error"] + --bail stop test runner after specific amount of tests have + failed [number] + --baseUrl shorten url command calls by setting a base url [string] + --waitforTimeout, -w timeout for all waitForXXX commands [number] + --framework, -f defines the framework (Mocha, Jasmine or Cucumber) to + run the specs [string] + --reporters, -r reporters to print out the results on stdout [array] + --suite overwrites the specs attribute and runs the defined + suite [array] + --spec run only a certain spec file - overrides specs piped + from stdin [array] + --exclude exclude spec file(s) from a run - overrides specs piped + from stdin [array] + --mochaOpts Mocha options + --jasmineOpts Jasmine options + --cucumberOpts Cucumber options +``` + +Sweet! Now you need to define a configuration file where all information about your tests, capabilities and settings are set. Switch over to the [Configuration File](ConfigurationFile.md) section to find out how that file should look like. With the `wdio` configuration helper it is super easy to generate your config file. Just run: + +```sh +$ ./node_modules/.bin/wdio config +``` + +and it launches the helper utility. It will ask you questions depending on the answers you give. This way you can generate your config file in less than a minute. + +![WDIO configuration utility](/img/config-utility.gif) + +Once you have your configuration file set up you can start your integration tests by calling: + +```sh +$ ./node_modules/.bin/wdio wdio.conf.js +``` + +That's it! Now, you can access to the selenium instance via the global variable `browser`. + +## Run the test runner programmatically + +Instead of calling the wdio command you can also include the test runner as module and run in within any arbitrary environment. For that you need to require the `@wdio/cli` package as module the following way: + +```js +import Launcher from '@wdio/cli'; +``` + +After that you create an instance of the launcher and run the test. The Launcher class expects as parameter the url to the config file and parameters that will overwrite the value in the config. + +```js +const wdio = new Launcher('/path/to/my/wdio.conf.js', opts); +wdio.run().then((code) => { + process.exit(code); +}, (error) => { + console.error('Launcher failed to start the test', error.stacktrace); + process.exit(1); +}); +``` + +The run command returns a [Promise](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) that gets resolved if the test ran successful or failed or gets rejected if the launcher was not able to start run the tests. \ No newline at end of file diff --git a/website/translated_docs/es-ES/CloudServices.md b/website/translated_docs/es-ES/CloudServices.md new file mode 100644 index 00000000000..34addee6a7c --- /dev/null +++ b/website/translated_docs/es-ES/CloudServices.md @@ -0,0 +1,117 @@ +--- +id: cloudservices +title: Using Cloud Services +--- +Using ondemand services like Sauce Labs, Browserstack or TestingBot with WebdriverIO is pretty simple. All you need to do is to set `user` and `key` in your options that are provided by the cloud provider. Optional you can also parametrize your test by setting cloud specific capabilities like `build`. If you only want to run cloud services in Travis, you can use the `CI` environment variable to check if you are in Travis and modify the config accordingly. + +```js +// wdio.conf.js + +var config = {...} +if (process.env.CI) { + config.user = process.env.SAUCE_USERNAME; + config.key = process.env.SAUCE_ACCESS_KEY; +} +exports.config = config +``` + +## [Sauce Labs](https://saucelabs.com/) + +It is easy to set up your tests to run remotely in Sauce Labs. + +The only requirement is to set the `user` and `key` in your config (either exported by `wdio.conf.js` or passed into `webdriverio.remote(...)`) to your Sauce Labs username and access key. + +You can also pass in any optional [test configuration option](https://docs.saucelabs.com/reference/test-configuration/#webdriver-api) as a key/value in the capabilities for any browser. + +### [Sauce Connect](https://wiki.saucelabs.com/display/DOCS/Sauce+Connect+Proxy) + +If you want to run tests against a server that is not accessible to the Internet (like on `localhost`), then you need to use Sauce Connect. + +It is out of the scope of WebdriverIO to support this, so you must start it by yourself. + +If you are using the WDIO testrunner download and configure the [`@wdio/sauce-service`](https://github.com/webdriverio/webdriverio/tree/master/packages/wdio-sauce-service) in your `wdio.conf.js`. It helps getting Sauce Connect running and comes with additional features that better integrate your tests into the Sauce service. + +### With Travis CI + +Travis CI, however, does [have support](http://docs.travis-ci.com/user/sauce-connect/#Setting-up-Sauce-Connect) for starting Sauce Connect before each test, so follow their directions for that if you are interested. + +If you do so, you must set the `tunnel-identifier` test configuration option in each browser's capabilities. Travis sets this to the `TRAVIS_JOB_NUMBER` environmental variable by default. + +Also if you want to have Sauce Labs group your tests by build number, you can set the `build` to `TRAVIS_BUILD_NUMBER`. + +Lastly if you set the `name`, this changes the name of this test in Sauce Labs for this build. If you are using the WDIO testrunner combined with the [`@wdio/sauce-service`](https://github.com/webdriverio/webdriverio/tree/master/packages/wdio-sauce-service) WebdriverIO automatically sets a proper name for the test. + +Example `desiredCapabilities`: + +```javascript +browserName: 'chrome', +version: '27.0', +platform: 'XP', +'tunnel-identifier': process.env.TRAVIS_JOB_NUMBER, +name: 'integration', +build: process.env.TRAVIS_BUILD_NUMBER +``` + +### Timeouts + +Since you are running your tests remotely, it might be necessary to increase some timeouts. + +You can change the [idle timeout](https://docs.saucelabs.com/reference/test-configuration/#idle-test-timeout) by passing `idle-timeout` as a test configuration option. This controls how long Sauce will wait between commands before closing the connection. + +## [BrowserStack](https://www.browserstack.com/) + +Browserstack is also supported easily. + +The only requirement is to set the `user` and `key` in your config (either exported by `wdio.conf.js` or passed into `webdriverio.remote(...)`) to your Browserstack automate username and access key. + +You can also pass in any optional [supported capabilities](https://www.browserstack.com/automate/capabilities) as a key/value in the capabilities for any browser. If you set `browserstack.debug` to `true` it will record a screencast of the session, which might be helpful. + +### [Local Testing](https://www.browserstack.com/local-testing#command-line) + +If you want to run tests against a server that is not accessible to the Internet (like on `localhost`), then you need to use Local Testing. + +It is out of the scope of WebdriverIO to support this, so you must start it by yourself. + +If you do use local, you should set `browserstack.local` to `true` in your capabilities. + +If you are using the WDIO testrunner download and configure the [`wdio-browserstack-service`](https://github.com/itszero/wdio-browserstack-service) in your `wdio.conf.js`. It helps getting BrowserStack running and comes with additional features that better integrate your tests into the BrowserStack service. + +### With Travis CI + +If you want to add Local Testing in Travis you have to start it by yourself. + +The following script will download and start it in the background. You should run this in Travis before starting the tests. + +```bash +wget https://www.browserstack.com/browserstack-local/BrowserStackLocal-linux-x64.zip +unzip BrowserStackLocal-linux-x64.zip +./BrowserStackLocal -v -onlyAutomate -forcelocal $BROWSERSTACK_ACCESS_KEY & +sleep 3 +``` + +Also, you might wanna set the `build` to the Travis build number. + +Example `desiredCapabilities`: + +```javascript +browserName: 'chrome', +project: 'myApp', +version: '44.0', +build: 'myApp #' + process.env.TRAVIS_BUILD_NUMBER + '.' + process.env.TRAVIS_JOB_NUMBER, +'browserstack.local': 'true', +'browserstack.debug': 'true' +``` + +## [TestingBot](https://testingbot.com/) + +The only requirement is to set the `user` and `key` in your config (either exported by `wdio.conf.js` or passed into `webdriverio.remote(...)`) to your TestingBot username and secret key. + +You can also pass in any optional [supported capabilities](https://testingbot.com/support/other/test-options) as a key/value in the capabilities for any browser. + +### [Local Testing](https://testingbot.com/support/other/tunnel) + +If you want to run tests against a server that is not accessible to the Internet (like on `localhost`), then you need to use Local Testing. TestingBot provides a JAVA based tunnel to allow you to test websites not accessible from the internet. + +Their tunnel support page contains the information necessary to get this up and running. + +If you are using the WDIO testrunner download and configure the [`@wdio/testingbot-service`](https://github.com/webdriverio/webdriverio/tree/master/packages/wdio-testingbot-service) in your `wdio.conf.js`. It helps getting TestingBot running and comes with additional features that better integrate your tests into the TestingBot service. \ No newline at end of file diff --git a/website/translated_docs/es-ES/ConfigurationFile.md b/website/translated_docs/es-ES/ConfigurationFile.md new file mode 100644 index 00000000000..510254d886d --- /dev/null +++ b/website/translated_docs/es-ES/ConfigurationFile.md @@ -0,0 +1,334 @@ +--- +id: configurationfile +title: Testrunner Configuration +--- +The configuration file contains all necessary information to run your test suite. It is a node module that exports a JSON. Here is an example configuration with all supported properties and additional information: + +```js +exports.config = { + + // ===================== + // Server Configurations + // ===================== + // Host address of the running Selenium server. This information is usually obsolete as + // WebdriverIO automatically connects to localhost. Also if you are using one of the + // supported cloud services like Sauce Labs, Browserstack or Testing Bot you also don't + // need to define host and port information because WebdriverIO can figure that out + // according to your user and key information. However if you are using a private Selenium + // backend you should define the host address, port, and path here. + // + host: '0.0.0.0', + port: 4444, + path: '/wd/hub', + // + // ================= + // Service Providers + // ================= + // WebdriverIO supports Sauce Labs, Browserstack and Testing Bot (other cloud providers + // should work too though). These services define specific user and key (or access key) + // values you need to put in here in order to connect to these services. + // + user: 'webdriverio', + key: 'xxxxxxxxxxxxxxxx-xxxxxx-xxxxx-xxxxxxxxx', + // + // If you run your tests on SauceLabs you can specify the region you want to run your tests + // in via the `region` property. Available short handles for regions are: + // us: us-west-1 (default) + // eu: eu-central-1 + region: 'us', + // + // ================== + // Specify Test Files + // ================== + // Define which test specs should run. The pattern is relative to the directory + // from which `wdio` was called. Notice that, if you are calling `wdio` from an + // NPM script (see https://docs.npmjs.com/cli/run-script) then the current working + // directory is where your package.json resides, so `wdio` will be called from there. + // + specs: [ + 'test/spec/**' + ], + // Patterns to exclude. + exclude: [ + 'test/spec/multibrowser/**', + 'test/spec/mobile/**' + ], + // + // ============ + // Capabilities + // ============ + // Define your capabilities here. WebdriverIO can run multiple capabilities at the same + // time. Depending on the number of capabilities, WebdriverIO launches several test + // sessions. Within your capabilities you can overwrite the spec and exclude option in + // order to group specific specs to a specific capability. + // + // + // First you can define how many instances should be started at the same time. Let's + // say you have 3 different capabilities (Chrome, Firefox and Safari) and you have + // set maxInstances to 1, wdio will spawn 3 processes. Therefor if you have 10 spec + // files and you set maxInstances to 10, all spec files will get tested at the same time + // and 30 processes will get spawned. The property basically handles how many capabilities + // from the same test should run tests. + // + maxInstances: 10, + // + // Or set a limit to run tests with a specific capability. + maxInstancesPerCapability: 10, + // + // If you have trouble getting all important capabilities together, check out the + // Sauce Labs platform configurator - a great tool to configure your capabilities: + // https://docs.saucelabs.com/reference/platforms-configurator + // + capabilities: [{ + browserName: 'chrome', + chromeOptions: { + // to run chrome headless the following flags are required + // (see https://developers.google.com/web/updates/2017/04/headless-chrome) + // args: ['--headless', '--disable-gpu'], + } + }, { + // maxInstances can get overwritten per capability. So if you have an in house Selenium + // grid with only 5 firefox instance available you can make sure that not more than + // 5 instance gets started at a time. + maxInstances: 5, + browserName: 'firefox', + specs: [ + 'test/ffOnly/*' + ], + "moz:firefoxOptions": { + // flag to activate Firefox headless mode (see https://github.com/mozilla/geckodriver/blob/master/README.md#firefox-capabilities for more details about moz:firefoxOptions) + // args: ['-headless'] + } + }], + // + // Additional list of node arguments to use when starting child processes + execArgv: [], + // + // =================== + // Test Configurations + // =================== + // Define all options that are relevant for the WebdriverIO instance here + // + // Level of logging verbosity: trace | debug | info | warn | error + logLevel: 'info', + // + // 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). + bail: 0, + // + // Set a base URL in order to shorten url command calls. If your `url` parameter starts + // with `/`, the base url gets prepended, not including the path portion of your baseUrl. + // If your `url` parameter starts without a scheme or `/` (like `some/path`), the base url + // gets prepended directly. + baseUrl: 'http://localhost:8080', + // + // Default timeout for all waitForXXX commands. + waitforTimeout: 1000, + // + // Add files to watch (e.g. application code or page objects) when running `wdio` command + // with `--watch` flag (globbing is supported). + filesToWatch: [ + // e.g. rerun tests if I change my application code + // './app/**/*.js' + ], + // + // Framework you want to run your specs with. + // The following are supported: mocha, jasmine and cucumber + // see also: http://webdriver.io/docs/frameworks.html + // + // Make sure you have the wdio adapter package for the specific framework installed before running any tests. + framework: 'mocha', + // + // Test reporter for stdout. + // The only one supported by default is 'dot' + // see also: http://webdriver.io/docs/dot-reporter.html and click on "Reporters" in left column + reporters: [ + 'dot', + ['allure', { + // + // If you are using the "allure" reporter you should define the directory where + // WebdriverIO should save all allure reports. + outputDir: './' + }] + ], + // + // Options to be passed to Mocha. + // See the full list at http://mochajs.org/ + mochaOpts: { + ui: 'bdd' + }, + // + // Options to be passed to Jasmine. + // See also: https://github.com/webdriverio/webdriverio/tree/master/packages/wdio-jasmine-framework#jasminenodeopts-options + jasmineNodeOpts: { + // + // Jasmine default timeout + defaultTimeoutInterval: 5000, + // + // The Jasmine framework allows it to intercept each assertion in order to log the state of the application + // or website depending on the result. For example it is pretty handy to take a screenshot every time + // an assertion fails. + expectationResultHandler: function(passed, assertion) { + // do something + }, + // + // Make use of Jasmine-specific grep functionality + grep: null, + invertGrep: null + }, + // + // If you are using Cucumber you need to specify where your step definitions are located. + // See also: https://github.com/webdriverio/webdriverio/tree/master/packages/wdio-cucumber-framework#cucumberopts-options + cucumberOpts: { + require: [], // (file/dir) require files before executing features + backtrace: false, // show full backtrace for errors + compiler: [], // ("extension:module") require files with the given EXTENSION after requiring MODULE (repeatable) + dryRun: false, // invoke formatters without executing steps + failFast: false, // abort the run on first failure + format: ['pretty'], // (type[:path]) specify the output format, optionally supply PATH to redirect formatter output (repeatable) + colors: true, // disable colors in formatter output + snippets: true, // hide step definition snippets for pending steps + source: true, // hide source URIs + profile: [], // (name) specify the profile to use + strict: false, // fail if there are any undefined or pending steps + tags: [], // (expression) only execute the features or scenarios with tags matching the expression + timeout: 20000, // timeout for step definitions + ignoreUndefinedDefinitions: false, // Enable this config to treat undefined definitions as warnings. + }, + // + // ===== + // Hooks + // ===== + // WebdriverIO provides a several hooks you can use to interfere the test process in order to enhance + // it and build services around it. You can either apply a single function to it or an array of + // methods. If one of them returns with a promise, WebdriverIO will wait until that promise got + // resolved to continue. + // + + /** + * Gets executed once before all workers get launched. + * @param {Object} config wdio configuration object + * @param {Array.} capabilities list of capabilities details + */ + onPrepare: function (config, capabilities) { + }, + /** + * Gets executed just before initialising the webdriver session and test framework. It allows you + * to manipulate configurations depending on the capability or spec. + * @param {Object} config wdio configuration object + * @param {Array.} capabilities list of capabilities details + * @param {Array.} specs List of spec file paths that are to be run + */ + beforeSession: function (config, capabilities, specs) { + }, + /** + * Gets executed before test execution begins. At this point you can access to all global + * variables like `browser`. It is the perfect place to define custom commands. + * @param {Array.} capabilities list of capabilities details + * @param {Array.} specs List of spec file paths that are to be run + */ + before: function (capabilities, specs) { + }, + /** + * Hook that gets executed before the suite starts + * @param {Object} suite suite details + */ + beforeSuite: function (suite) { + }, + /** + * Hook that gets executed _before_ a hook within the suite starts (e.g. runs before calling + * beforeEach in Mocha) + */ + beforeHook: function () { + }, + /** + * Hook that gets executed _after_ a hook within the suite ends (e.g. runs after calling + * afterEach in Mocha) + */ + afterHook: function () { + }, + /** + * Function to be executed before a test (in Mocha/Jasmine) or a step (in Cucumber) starts. + * @param {Object} test test details + */ + beforeTest: function (test) { + }, + /** + * Runs before a WebdriverIO command gets executed. + * @param {String} commandName hook command name + * @param {Array} args arguments that command would receive + */ + beforeCommand: function (commandName, args) { + }, + /** + * Runs after a WebdriverIO command gets executed + * @param {String} commandName hook command name + * @param {Array} args arguments that command would receive + * @param {Number} result 0 - command success, 1 - command error + * @param {Object} error error object if any + */ + afterCommand: function (commandName, args, result, error) { + }, + /** + * Function to be executed after a test (in Mocha/Jasmine) or a step (in Cucumber) ends. + * @param {Object} test test details + */ + afterTest: function (test) { + }, + /** + * Hook that gets executed after the suite has ended + * @param {Object} suite suite details + */ + afterSuite: function (suite) { + }, + /** + * Gets executed after all tests are done. You still have access to all global variables from + * the test. + * @param {Number} result 0 - test pass, 1 - test fail + * @param {Array.} capabilities list of capabilities details + * @param {Array.} specs List of spec file paths that ran + */ + after: function (result, capabilities, specs) { + }, + /** + * Gets executed right after terminating the webdriver session. + * @param {Object} config wdio configuration object + * @param {Array.} capabilities list of capabilities details + * @param {Array.} specs List of spec file paths that ran + */ + afterSession: function (config, capabilities, specs) { + }, + /** + * Gets executed after all workers got shut down and the process is about to exit. + * @param {Object} exitCode 0 - success, 1 - fail + * @param {Object} config wdio configuration object + * @param {Array.} capabilities list of capabilities details + * @param {} results object containing test results + */ + onComplete: function (exitCode, config, capabilities, results) { + }, + /** + * Gets executed when an error happens, good place to take a screenshot + * @ {String} error message + */ + onError: function(message) { + } + /** + * Cucumber specific hooks + */ + beforeFeature: function (feature) { + }, + beforeScenario: function (scenario) { + }, + beforeStep: function (step) { + }, + afterStep: function (stepResult) { + }, + afterScenario: function (scenario) { + }, + afterFeature: function (feature) { + } +}; +``` + +You can also find that file with all possible options and variations in the [example folder](https://github.com/webdriverio/webdriverio/blob/master/examples/wdio.conf.js). \ No newline at end of file diff --git a/website/translated_docs/es-ES/CustomCommands.md b/website/translated_docs/es-ES/CustomCommands.md new file mode 100644 index 00000000000..60320255dac --- /dev/null +++ b/website/translated_docs/es-ES/CustomCommands.md @@ -0,0 +1,54 @@ +--- +id: customcommands +title: Custom Commands +--- +If you want to extend the browser instance with your own set of commands there is a method called `addCommand` available from the browser object. You can write your command in a synchronous (default) way the same way as in your specs or asynchronous (like when using WebdriverIO in standalone mode). The following example shows how to add a new command that returns the current url and title as one result only using synchronous commands: + +```js +browser.addCommand("getUrlAndTitle", (customVar) => { + return { + url: this.getUrl(), + title: this.getTitle(), + customVar: customVar + }; +}); +``` + +Custom commands give you the opportunity to bundle a specific sequence of commands that are used frequently in a handy single command call. You can define custom commands at any point in your test suite, just make sure that the command is defined before you first use it (the before hook in your wdio.conf.js might be a good point to create them). Once defined you can use them as follows: + +```js +it('should use my custom command', () => { + browser.url('http://www.github.com'); + const result = browser.getUrlAndTitle('foobar'); + + assert.strictEqual(result.url, 'https://github.com/'); + assert.strictEqual(result.title, 'GitHub · Where software is built'); + assert.strictEqual(result.customVar, 'foobar'); +}); +``` + +Be careful to not overload the `browser` scope with custom commands. It is advised to rather define custom logic into page objects so they are bound to a specific page. + +## Integrate 3rd party libraries + +If you use external libraries (e.g. to do database calls) that support promises, a nice approach to easily integrate them is to wrap certain API methods within a custom command. When returning the promise, WebdriverIO ensures that it doesn't continue with the next command until the promise is resolved. If the promise gets rejected the command will throw an error. + +```js +import request from 'request'; + +browser.addCommand('makeRequest', (url) => { + return request.get(url).then((response) => response.body) +}); +``` + +Then just use it in your wdio test specs synchronously: + +```js +it('execute external library in a sync way', () => { + browser.url('...'); + const body = browser.makeRequest('http://...'); + console.log(body); // returns response body +}); +``` + +Note that the result of your custom command will be the result of the promise you return. Also there is no support for synchronous commands in standalone mode therefore you always have to handle asynchronous commands using promises. \ No newline at end of file diff --git a/website/translated_docs/es-ES/CustomReporter.md b/website/translated_docs/es-ES/CustomReporter.md new file mode 100644 index 00000000000..fe519a5ea6a --- /dev/null +++ b/website/translated_docs/es-ES/CustomReporter.md @@ -0,0 +1,78 @@ +--- +id: customreporter +title: Custom Reporter +--- +You can write your own custom reporter for the wdio test runner that fits your needs. All you need to do is to create a node module that inherits from the `@wdio/reporter` package so it can receive messages from the test. The basic construction should look like: + +```js +import WDIOReporter from '@wdio/reporter'; + +export default class CustomReporter extends WDIOReporter { + constructor (options) { + /** + * make reporter to write to output stream by default + */ + options = Object.assign(options, { stdout: true }); + super(options); + } + + onTestPass (test) { + this.write(`Congratulations! Your test "${test.title}" passed 👏`); + } +}; +``` + +The only thing to do now in order to use this reporter is to assign it to the reporter property. Therefor your wdio.conf.js file should look like this: + +```js +var CustomReporter = require('./reporter/my.custom.reporter'); + +exports.config = { + // ... + reporters: [[CustomReporter, { + someOption: 'foobar' + }]], + // ... +}; +``` + +You can also publish the reporter to NPM so everyone can use it. Name the package like other reporters `wdio--reporter` and tag it with keywords like `wdio` or `wdio-reporter`. + +## Event Handler + +You can register event handler for several events which get triggered during the test. All these handlers will receive payloads with useful information about the current state and progress. The structure of these payload objects depend on the event and are unified across the frameworks (Mocha, Jasmine and Cucumber). Once you implemented your custom reporter it should work for all frameworks. The following list contains all possible methods you can add to your reporter class: + +```js +import WDIOReporter from '@wdio/reporter'; + +export default class CustomReporter extends WDIOReporter { + onRunnerStart () {} + onBeforeCommand () {} + onAfterCommand () {} + onScreenshot () {} + onSuiteStart () {} + onHookStart () {} + onHookEnd () {} + onTestStart () {} + onTestPass () {} + onTestFail () {} + onTestSkip () {} + onTestEnd () {} + onSuiteEnd () {} + onRunnerEnd () {} +}; +``` + +The method names are pretty self explanatory. To print something on a certain event, use the `this.write(...)` method which is provided by the parent class (`WDIOReporter`). It either streams the content to stdout or to a log file depending on the options of the reporter. + +```js +import WDIOReporter from '@wdio/reporter'; + +export default class CustomReporter extends WDIOReporter { + onTestPass (test) { + this.write(`Congratulations! Your test "${test.title}" passed 👏`); + } +}; +``` + +Note that you can't defer the test execution in any way. All event handler should execute synchronous routines otherwise you will run into race conditions. Make sure you check out the [example section](https://github.com/webdriverio/webdriverio/tree/master/examples/wdio) where you can find an example for a custom reporter that prints the event name for each event. If you have implemented a custom reporter that can be useful for the community, don't hesitate to make a Pull Request so we can make the reporter available for the public. \ No newline at end of file diff --git a/website/translated_docs/es-ES/CustomServices.md b/website/translated_docs/es-ES/CustomServices.md new file mode 100644 index 00000000000..c0d38b0890a --- /dev/null +++ b/website/translated_docs/es-ES/CustomServices.md @@ -0,0 +1,55 @@ +--- +id: customservices +title: Custom Services +--- +You can write your own custom service for the wdio test runner that fits your needs. Services are addons to be created for reusable logic to simplify tests, manage your test suite and integrate results. Services have access to all the same [before/after hooks](ConfigurationFile.md) available in the `wdio.conf.js`. The basic construction of service should look like this: + +```js +export default class CustomService { + onPrepare (config, capabilities) { + // TODO: something before the workers launch + } + + onComplete (exitCode, config, capabilities) { + // TODO: something after the workers shutdown + }, + + // ... +} +``` + +The only thing to do now in order to use this service is to assign it to the services property. Therefor your `wdio.conf.js` file should look like this: + +```js +import CustomService from './service/my.custom.service'; + +exports.config = { + // ... + services: [[CustomService, { + someOption: true + }]], + // ... +}; +``` + +### NPM + +To make services easier to consume and discover by the webdriver.io community, please follow these recommendations: + +* services should use naming convention is `wdio-*-service` +* use NPM keywords `wdio-plugin`, `wdio-service` +* main entry should export an instance of the service. +* example services: [@wdio/sauce-service](https://github.com/webdriverio/webdriverio/tree/master/packages/wdio-sauce-service) + +Following the recommended naming pattern allows services to be added by name: + +```js +// Add wdio-custom-service +exports.config = { + // ... + services: ['custom'], + // ... +}; +``` + +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/packages/wdio-cli/src/config.js#L20-L34) so your package will be suggested if someone runs the wdio configurator. \ No newline at end of file diff --git a/website/translated_docs/es-ES/Debugging.md b/website/translated_docs/es-ES/Debugging.md new file mode 100644 index 00000000000..33eba136d44 --- /dev/null +++ b/website/translated_docs/es-ES/Debugging.md @@ -0,0 +1,86 @@ +--- +id: debugging +title: Debugging +--- +Debugging is significantly more difficult when there are several processes spawning dozens of tests in multiple browsers. + +For starters, it is extremely helpful to limit parallelism by setting `maxInstances` to 1 and targeting only those specs and browsers that need to be debugged. + +In `wdio.conf`: + +```js +exports.config = { + // ... + maxInstances: 1, + specs: [ + '**/myspec.spec.js' + ], + capabilities: [{ + browserName: 'firefox' + }], + // ... +} +``` + +## The Debug Command + +In many cases, you can use [`browser.debug()`](/docs/api/browser/debug.html) to pause your test and inspect the browser. Your command line interface will also switch into a REPL mode that allows you to fiddle around with commands and elements on the page. In REPL mode you can access the browser object or `$` and `$$` functions like you can in your tests. + +When using `browser.debug()` you will likely need to increase the timeout of the test runner to prevent the test runner from failing the test for taking to long. For example: + +In `wdio.conf`: + +```js +jasmineNodeOpts: { + defaultTimeoutInterval: (24 * 60 * 60 * 1000); +} +``` + +See [timeouts](Timeouts.md) for more information on how to do that using other frameworks. + +## Debugging in Chrome DevTools + +To get it working, you need to pass the `--inspect` flag down to the wdio command running tests like this: + +```sh +$ wdio wdio.conf.js --inspect +``` + +This will start the runner process with this inspect flag enabled. With that you can open the DevTools and can connect to the runner process. Make sure you set a `debugger` statement somewhere in order to start fiddling around with commands in the console. + +Tests will pause at `debugger` statements, but ONLY once dev-tools has been opened and the debugger attached. If you prefer to break on the first line, you can use `--inspect-brk` instead. + +Once execution has finished, the test doesn't actually finish until the devtools is closed. You'll need to do that yourself. + +## Dynamic configuration + +Note that `wdio.conf.js` can contain javascript. Since you probably do not want to permanently change your timeout value to 1 day, it can be often helpful to change these settings from the command line using an environment variable. This can used to dynamically change the configuration: + +```js +const debug = process.env.DEBUG; +const defaultCapabilities = ...; +const defaultTimeoutInterval = ...; +const defaultSpecs = ...; + +exports.config = { + // ... + maxInstances: debug ? 1 : 100, + capabilities: debug ? [{ browserName: 'chrome' }] : defaultCapabilities, + execArgv: debug ? ['--inspect'] : [], + jasmineNodeOpts: { + defaultTimeoutInterval: debug ? (24 * 60 * 60 * 1000) : defaultTimeoutInterval + } + // ... +} +``` + +You can then prefix the `wdio` command with the debug flag: + + DEBUG=true ./node_modules/.bin/wdio wdio.conf.js --spec ./tests/e2e/myspec.test.js + + +and debug your spec file with the DevTools. + +## Dynamic Repl with Atom + +If you are an [Atom](https://atom.io/) hacker you can try [wdio-repl](https://github.com/kurtharriger/wdio-repl) by [@kurtharriger](https://github.com/kurtharriger) which is a dynamic repl that allows you to execute single code lines in Atom. Watch [this](https://www.youtube.com/watch?v=kdM05ChhLQE) Youtube video to see a demo. \ No newline at end of file diff --git a/website/translated_docs/es-ES/Frameworks.md b/website/translated_docs/es-ES/Frameworks.md new file mode 100644 index 00000000000..8194589a026 --- /dev/null +++ b/website/translated_docs/es-ES/Frameworks.md @@ -0,0 +1,105 @@ +--- +id: frameworks +title: Frameworks +--- +The wdio runner currently supports [Mocha](http://mochajs.org/) and [Jasmine](http://jasmine.github.io/) and [Cucumber](https://cucumber.io/) (not yet supported in v5). To integrate each framework with WebdriverIO there are adapter packages on NPM that need to be downloaded and installed. Note that these packages need to be installed at the same place WebdriverIO is installed. If you've installed WebdriverIO globally make sure you have the adapter package installed globally as well. + +Within your spec files or step definition you can access the webdriver instance using the global variable `browser`. You don't need to initiate or end the Selenium session. This is taken care of by the wdio testrunner. + +## Using Mocha + +First you need to install the adapter package from NPM: + +```sh +npm install @wdio/mocha-framework --save-dev +``` + +If you like to use Mocha you should additionally install an assertion library to have more expressive tests, e.g. [Chai](http://chaijs.com). Initialise that library in the `before` hook in your configuration file: + +```js +before: function() { + var chai = require('chai'); + global.expect = chai.expect; + chai.Should(); +} +``` + +Once that is done you can write beautiful assertions like: + +```js +describe('my awesome website', () => { + it('should do some chai assertions', () => { + browser.url('http://webdriver.io'); + browser.getTitle().should.be.equal('WebdriverIO - WebDriver bindings for Node.js'); + }); +}); +``` + +WebdriverIO supports Mochas `BDD` (default), `TDD` and `QUnit` [interface](https://mochajs.org/#interfaces). If you like to write your specs in TDD language set the ui property in your `mochaOpts` config to `tdd`, now your test files should get written like: + +```js +suite('my awesome website', () => { + test('should do some chai assertions', () => { + browser.url('http://webdriver.io'); + browser.getTitle().should.be.equal('WebdriverIO - WebDriver bindings for Node.js'); + }); +}); +``` + +If you want to define specific Mocha settings you can do that by adding `mochaOpts` to your configuration file. A list of all options can be found on the [project website](http://mochajs.org/). + +**Note:** that since all commands are running synchronously there is no need to have async mode in Mocha enabled. Therefor you can't use the `done` callback: + +```js +it('should test something', () => { + done(); // throws "done is not a function" +}) +``` + +If you want to run something asynchronously you can either use the [`call`](api/browser/call.md) command or [custom commands](CustomCommands.md). + +## Using Jasmine + +First you need to install the adapter package from NPM: + +```sh +npm install @wdio/jasmine-framework --save-dev +``` + +Jasmine already provides assertion methods you can use with WebdriverIO. So there is no need to add another one. + +### Intercept Assertion + +The Jasmine framework allows it to intercept each assertion in order to log the state of the application or website depending on the result. For example it is pretty handy to take a screenshot everytime an assertion fails. In your `jasmineNodeOpts` you can add a property called `expectationResultHandler` that takes a function to execute. The function parameter give you information about the result of the assertion. The following example demonstrate how to take a screenshot if an assertion fails: + +```js +jasmineNodeOpts: { + defaultTimeoutInterval: 10000, + expectationResultHandler: function(passed, assertion) { + /** + * only take screenshot if assertion failed + */ + if(passed) { + return; + } + + browser.saveScreenshot('assertionError_' + assertion.error.message + '.png'); + } +}, +``` + +Please note that you can't stop the test execution to do something async. It might happen that the command takes too much time and the website state has changed. Though usually after 2 another commands the screenshot got taken which gives you still valuable information about the error. + +## Using Cucumber + +To use Cucumber you have to use WebdriverIO v4 until the framework has been migrated to v5. First you need to install the adapter package from NPM: + +```sh +npm install @wdio/cucumber-framework --save-dev +``` + +If you want to use Cucumber set the `framework` property to cucumber, either by adding `framework: 'cucumber'` to the [config file](ConfigurationFile.md) or by adding `-f cucumber` to the command line. + +Options for Cucumber can be given in the config file with cucumberOpts. Check out the whole list of options [here](https://github.com/webdriverio/webdriverio/tree/master/packages/wdio-cucumber-framework#cucumberopts-options). + +To get up and running quickly with Cucumber have a look on our [cucumber-boilerplate](https://github.com/webdriverio/cucumber-boilerplate) project that comes with all step definition you will probably need and allows you to start writing feature files right away. \ No newline at end of file diff --git a/website/translated_docs/es-ES/GettingStarted.md b/website/translated_docs/es-ES/GettingStarted.md new file mode 100644 index 00000000000..89e38c3daa1 --- /dev/null +++ b/website/translated_docs/es-ES/GettingStarted.md @@ -0,0 +1,180 @@ +--- +id: gettingstarted +title: Getting Started +--- +Welcome to the WebdriverIO documentation. It will help you to get started fast. If you run into problems you can find help and answers on our [Gitter Channel](https://gitter.im/webdriverio/webdriverio) or you can hit me on [Twitter](https://twitter.com/webdriverio). Also, if you encounter problems in starting up the server or running the tests after following this tutorial, ensure that the server and the geckodriver are listed in your project directory. If not, re-download them per steps 2 and 3 below. + +> **Note:** These are the docs for the latest version (v5.0.0) of WebdriverIO. If you are still using v4 or older please us the legacy docs website [v4.webdriver.io](http://v4.webdriver.io)! + +The following will give you a short step by step introduction to get your first WebdriverIO script up and running. + +## Taking the first step + +Let's suppose you have [Node.js](http://nodejs.org/) already installed. First thing we need to do is to download a browser driver that helps us automate the browser. To do so we create an example folder first: + +### Create a simple test folder + +```sh +$ mkdir webdriverio-test && cd webdriverio-test +``` + +*While still in this test folder:* + +### Download Geckodriver + +Download the latest version of geckodriver for your environment and unpack it in your project directory: + +Linux 64 bit + +```sh +$ curl -L https://github.com/mozilla/geckodriver/releases/download/v0.21.0/geckodriver-v0.21.0-linux64.tar.gz | tar xz +``` + +OSX + +```sh +$ curl -L https://github.com/mozilla/geckodriver/releases/download/v0.21.0/geckodriver-v0.21.0-macos.tar.gz | tar xz +``` + +Note: Other geckodriver releases are available [here](https://github.com/mozilla/geckodriver/releases). In order to automate other browser you need to run different drivers. You can find a list with all drivers in the [awesome-selenium](https://github.com/christian-bromann/awesome-selenium#driver) readme. + +### Start Browser Driver + +Start Geckodriver by running: + +```sh +$ /path/to/binary/geckodriver --port 4444 +``` + +This will start Geckodriver on `localhost:4444` with the WebDriver endpoint set to `/`. Keep this running in the background and open a new terminal window. Next step is to download WebdriverIO via NPM: + +### Download WebdriverIO + +By calling: + +```sh +$ npm install webdriverio +``` + +### Create Test File + +Create a test file (e.g. `test.js`) with the following content: + +```js +const { remote } = require('webdriverio'); + +(async () => { + const browser = await remote({ + logLevel: 'error', + path: '/', + capabilities: { + browserName: 'firefox' + } + }); + + await browser.url('http://webdriver.io'); + + const title = await browser.getTitle(); + console.log('Title was: ' + title); + + await browser.deleteSession(); +})().catch((e) => console.error(e)); +``` + +### Run your test file + +Make sure you have at least Node.js v8.11.2 or higher installed. To update your current running Node.js version install [nvm](https://github.com/creationix/nvm) and follow their instructions. Once that is done run the test script by calling: + +```sh +$ node test.js +``` + +this should output the following: + +```sh +Title was: WebdriverIO · Next-gen WebDriver test framework for Node.js +``` + +Yay, Congratulations! You've just run your first automation script with WebdriverIO. Let's step it up a notch and create a real test. + +## Let's get serious + +*(If you haven't already, navigate back to the project root directory)* + +This was just a warm up. Let's move forward and run WebdriverIO with the test runner. If you want to use WebdriverIO in your project for integration testing we recommend to use the test runner because it comes with a lot of useful features that makes your life easier. With WebdriverIO v5 and up the testrunner has moved into the [`@wdio/cli`](https://www.npmjs.com/package/@wdio/cli) NPM package. To get started, we need to install this first: + +```sh +$ npm i --save-dev @wdio/cli +``` + +### Generate Configuration File + +To do that just run the configuration utility: + +```sh +$ ./node_modules/.bin/wdio config +``` + +A question interface pops up. It will help to create the config easy and fast. If you are not sure what to answer follow this answers: + +__Q: Where should your tests be launched?__ +A: *local_ +
__Q: Shall I install the runner plugin for you?__ +A: _Yes_ +
__Q: Where do you want to execute your tests?__ +A: _On my local machine_ +
__Q: Which framework do you want to use?__ +A: _mocha_ +
__Q: Shall I install the framework adapter for you?__ +A: _Yes* (just press enter) +
__Q: Do you want to run WebdriverIO commands synchronous or asynchronous?__ +A: *sync* (just press enter, you can also run commands async and handle promises by yourself but for the sake of simplicity let's run them synchronously) +
__Q: Where are your test specs located?__ +A: *./test/specs/**/*.js* (just press enter) +
__Q: Which reporter do you want to use?__ +A: *dot* (just press space and enter) +
__Q: Shall I install the reporter library for you?__ +A: *Yes* (just press enter) +
__Q: Do you want to add a service to your test setup?__ +A: none (just press enter, let's skip this for simplicity) +
__Q: Level of logging verbosity:__ +A: *trace* (just press enter) +
__Q: In which directory should screenshots gets saved if a command fails?__ +A: *./errorShots/* (just press enter) +
__Q: What is the base url?__ +A: *http://localhost* (just press enter) + + +That's it! The configurator now installs all required packages for you and creates a config file with the name `wdio.conf.js`. Next step is to create your first spec file (test file). + +### Create Spec Files + +For that create a test folder like this: + +```sh +$ mkdir -p ./test/specs +``` + +Now let's create a simple spec file in that new folder: + +```js +const assert = require('assert'); + +describe('webdriver.io page', () => { + it('should have the right title', () => { + browser.url('http://webdriver.io'); + const title = browser.getTitle(); + assert.equal(title, 'WebdriverIO - WebDriver bindings for Node.js'); + }); +}); +``` + +### Kick Off Testrunner + +The last step is to execute the test runner. To do so just run: + +```sh +$ ./node_modules/.bin/wdio wdio.conf.js +``` + +Hurray! The test should pass and you can start writing integration tests with WebdriverIO. If you are interested in more in depth video on-boarding tutorials, feel free to check out our very own course called [learn.webdriver.io](https://learn.webdriver.io/?coupon=wdio). Also our community has collected a lot of [boilerplate projects](BoilerplateProjects.md) that can help you to get started. \ No newline at end of file diff --git a/website/translated_docs/es-ES/JenkinsIntegration.md b/website/translated_docs/es-ES/JenkinsIntegration.md new file mode 100644 index 00000000000..46509cd5153 --- /dev/null +++ b/website/translated_docs/es-ES/JenkinsIntegration.md @@ -0,0 +1,43 @@ +--- +id: jenkins +title: Jenkins Integration +--- +WebdriverIO offers a tight integration to CI systems like [Jenkins](https://jenkins-ci.org/). With the [junit reporter](https://github.com/webdriverio/wdio-junit-reporter) you can easily debug your tests as well as keep track of your test results. The integration is pretty easy. + +First we need to define `junit` as test reporter. Also make sure you have it installed (`$ npm install --save-dev wdio-junit-reporter`) and that we save our xunit results at a place where Jenkins can pick them up. Therefore we define our reporter in our config as follows: + +```js +// wdio.conf.js +module.exports = { + // ... + reporters: [ + 'dot', + ['junit', { + outputDir: './' + }] + ], + // ... +}; +``` + +It is up to you which framework you want to choose. The reports will be similar. This tutorial is going to use Jasmine. After you have written couple of tests you can begin to setup a new Jenkins job. Give it a name and a description: + +![Name And Description](/img/jenkins/jobname.png "Name And Description") + +Then make sure it grabs always the newest version of your repository: + +![Jenkins Git Setup](/img/jenkins/gitsetup.png "Jenkins Git Setup") + +Now the important part: create a build step to execute shell commands. That build step needs to build your project. Since this demo project only tests an external app we don't need to build anything but install the node dependencies and run our test command `npm test` which is an alias for `node_modules/.bin/wdio test/wdio.conf.js`. + +![Build Step](/img/jenkins/runjob.png "Build Step") + +After our test we want Jenkins to track our xunit report. To do so we have to add a post-build action called *"Publish JUnit test result report"*. You could also install an external xunit plugin to track your reports. The JUnit one comes with the basic Jenkins installation and is sufficient enough for now. + +According to our config file we store the xunit reports in our workspace root directory. These reports are xml files. So all we need to do in order to track the reports is to point Jenkins to all xml files in our root directory: + +![Post-build Action](/img/jenkins/postjob.png "Post-build Action") + +That's it! This is all you need to setup Jenkins to run your WebdriverIO jobs. Your job will now provide detailed test results with history charts, stacktrace information on failed jobs as well as a list of commands with payload that got used in each test. + +![Jenkins Final Integration](/img/jenkins/final.png "Jenkins Final Integration") \ No newline at end of file diff --git a/website/translated_docs/es-ES/Multiremote.md b/website/translated_docs/es-ES/Multiremote.md new file mode 100644 index 00000000000..a4eda25cf20 --- /dev/null +++ b/website/translated_docs/es-ES/Multiremote.md @@ -0,0 +1,101 @@ +--- +id: multiremote +title: Multiremote +--- +WebdriverIO allows you to run multiple WebDriver/Appium sessions in a single test. This becomes handy when you need to test application features where multiple users are required (e.g. chat or WebRTC applications). Instead of creating a couple of remote instances where you need to execute common commands like [newSession](/docs/api/webdriver.html#newsession) or [url](/docs/api/browser/url.html) on each of those instances, you can simply create a multiremote instance and control all browser at the same time. To do so just use the `multiremote` function and pass an object with named browser with their capabilities into it. By giving each capability a name you will be able to easy select and access that single instance when executing commands on a single instance. + +## Using Standalone Mode + +Here is an example demonstrating a how to create a multiremote WebdriverIO instance in **standalone mode**: + +```js +import { multiremote } from 'webdriverio'; + +(async () => { + const browser = await multiremote({ + myChromeBrowser: { + capabilities: { + browserName: 'chrome' + } + }, + myFirefoxBrowser: { + capabilities: { + browserName: 'firefox' + } + } + }); + + // open url with both browser at the same time + await browser.url('http://json.org'); + + // click on an element at the same time + const elem = await browser.$('#someElem'); + await elem.click(); + + // only click with one browser (Firefox) + await elem.myFirefoxBrowser.click(); +})() +``` + +## Using WDIO Testrunner + +In order to use multiremote in the wdio testrunner just define the `capabilities` object in your `wdio.conf.js` as an object with the browser names as keys (instead of a list of capabilities): + +```js +export.config = { + // ... + capabilities: { + myChromeBrowser: { + desiredCapabilities: { + browserName: 'chrome' + } + }, + myFirefoxBrowser: { + desiredCapabilities: { + browserName: 'firefox' + } + } + } + // ... +}; +``` + +This would create two WebDriver sessions with Chrome and Firefox. Instead of just Chrome and Firefox you can also boot up two mobile devices using [Appium](http://appium.io/). Any kind of OS/browser combination is possible here (e.g. cross platform like mobile device and desktop browser). All commands you call with the `browser` variable gets executed in parallel with each instance. This helps to streamline your integration test and speedup the execution a bit. For example open up an url: + +```js +browser.url('http://chat.socket.io/'); +``` + +Each command result will be an object with the browser names as key and the actual command result as value, e.g. + +```js +// wdio testrunner example +browser.url('https://www.whatismybrowser.com/'); + +const elem = $('.string-major'); +const result = elem.getText(); + +console.log(result.resultChrome); // returns: 'Chrome 40 on Mac OS X (Yosemite)' +console.log(result.resultFirefox); // returns: 'Firefox 35 on Mac OS X (Yosemite)' +``` + +You will notice that each command gets executed one by one. That means that the command finishes once all browser have executed it. This is helpful because it keeps the browser actions synced and it makes it easier to understand what currently happens. + +Sometimes it is necessary to do different things with each browser in order to test something. For instance if we want to test a chat application, there has to be one browser who inputs a text message while the other browser waits to receive that message and do an assertion on it. When using the WDIO testrunner it registers the browser names with their instances to the global scope, e.g. + +```js +myChromeBrowser.$('#message').setValue('Hi, I am Chrome'); +myChromeBrowser.$('#send').click(); + +const firefoxMessages = myFirefoxBrowser.$$('.messages') +// wait until messages arrive +firefoxMessages.waitForExist(); +// check if one of the messages contain the Chrome message +assert.true( + firefoxMessages.map((m) => m.getText()).includes('Hi, I am Chrome') +) +``` + +In that example the `myFirefoxBrowser` instance will start waiting on a messages once the `myChromeBrowser` instance clicked on the send button. Multiremote makes it easy and convenient to control multiple browser either doing the same thing in parallel or something different. + +**Note:** Multiremote is not meant to execute all your tests in parallel. It should help you to coordinate more than one browser for sophisticated integration tests. \ No newline at end of file diff --git a/website/translated_docs/es-ES/Options.md b/website/translated_docs/es-ES/Options.md new file mode 100644 index 00000000000..bb161fd5e9b --- /dev/null +++ b/website/translated_docs/es-ES/Options.md @@ -0,0 +1,174 @@ +--- +id: options +title: Options +--- +WebdriverIO is not only a WebDriver protocol binding like Selenium. It is a full test framework that comes with a lot of additional features and utilities. It is based on the [webdriver](https://www.npmjs.com/package/webdriver) package which is a lightweight, non-opinionated implementation of the WebDriver specification including mobile commands supported by Appium. WebdriverIO takes the protocol commands and creates smart user commands that make it easier to use the protocol for test automation. + +WebdriverIO enhances the WebDriver package with additional commands. They share the same set of options when run in a standalone script. When running tests using `@wdio/cli` (wdio testrunner) some additional options are available that belong into the `wdio.conf.js`. + +## WebDriver Options + +The following options are defined: + +### protocol + +Protocol to use when communicating with the driver server. + +Type: `String` +Default: `http` + +### host + +Host of your driver server. + +Type: `String` +Default: `0.0.0.0` + +### port + +Port your driver server is on. + +Type: `Number` +Default: `4444` + +### path + +Path to driver server endpoint. + +Type: `String` +Default: `/wd/hub` + +### queryParams + +Query paramaters that are propagated to the driver server. + +Type: `Object` +Default: `null` + +### capabilities + +Defines the capabilities you want to run in your WebDriver session. Check out the [WebDriver Protocol](https://w3c.github.io/webdriver/#capabilities) for more details. If you run an older driver that doesn't support WebDriver you need to apply the [JSONWireProtocol capabilities](https://github.com/SeleniumHQ/selenium/wiki/DesiredCapabilities) to successfuly run a session. Also a useful utility is the 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. + +Type: `Object` +Default: `{ browserName: 'firefox' }` + + +**Example:** + +```js +{ + browserName: 'chrome', // options: `firefox`, `chrome`, `opera`, `safari` + browserVersion: '27.0', // browser version + platformName: 'Windows 10' // OS platform +} +``` + +To run web or native tests on mobile devices capabilities differ from the WebDriver protocol. Have a look into the [Appium Docs](http://appium.io/docs/en/writing-running-appium/caps/) for more details. + +### logLevel + +Level of logging verbosity. + +Type: `String` +Default: `info` +Options: `trace` | `debug` | `info` | `warn` | `error` + +### 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. + +Type: `String|writeable stream` +Default: `null` + +### connectionRetryTimeout + +Timeout for any request to the Selenium server + +Type: `Number` +Default: `90000` + +### connectionRetryCount + +Count of request retries to the Selenium server + +Type: `Number` +Default: `3` + +* * * + +## WDIO Options + +The following options are defined for running WebdriverIO with the `@wdio/cli` testrunner: + +### specs + +Define specs for test execution. + +Type: `String[]` +Default: `[]` + +### exclude + +Exclude specs from test execution. + +Type: `String[]` +Default: `[]` + +### suites + +An object describing various of suites that can be specified when applying the `--suite` option to the `wdio` cli command. + +Type: `Object` +Default: `{}` + +### baseUrl + +Shorten `url` command calls by setting a base url. If your `url` parameter starts with `/`, the base url gets prepended, not including the path portion of your baseUrl. If your `url` parameter starts without a scheme or `/` (like `some/path`), the base url gets prepended directly. + +Type: `String` +Default: `null` + +### 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). *Note*: Please be aware that when using a third party test runner such as Mocha, additional configuration might be required. + +Type: `Number` +Default: `0` (don't bail, run all tests) + +### waitforTimeout + +Default timeout for all waitForXXX commands. Note the lowercase `f`. This timeout **only** affects commands starting with waitForXXX and their default wait time. To increase the timeout of the test please see the framework docs. + +Type: `Number` +Default: `3000` + +### waitforInterval + +Default interval for all waitForXXX commands to check if an expected state (e.g. visibility) has been changed. + +Type: `Number` +Default: `500` + +### framework + +Defines the test framework to be used by the wdio testrunner. + +Type: `String` +Default: `mocha` Options: `mocha` | `jasmine` | `cucumber` + +### reporters + +List of reporters to use. A reporter can be either a string or an array where the first element is a string with the reporter name and the second element an object with reporter options. + +Type: `String[]|Object[]` +Default: `[]` Example: + +```js +reporters: [ + 'dot', + ['spec', { + outputDir: __dirname + '/reports', + otherOption: 'foobar' + }] +] +``` \ No newline at end of file diff --git a/website/translated_docs/es-ES/OrganizingTestSuites.md b/website/translated_docs/es-ES/OrganizingTestSuites.md new file mode 100644 index 00000000000..8742cc717ac --- /dev/null +++ b/website/translated_docs/es-ES/OrganizingTestSuites.md @@ -0,0 +1,158 @@ +--- +id: organizingsuites +title: Organizing Test Suite +--- +While your project is growing you will inevitably add more and more integration tests. This will increase your build time and will also slow down your productivity. To prevent this you should start to run your tests in parallel. You might have already recognised that WebdriverIO creates for each spec (or feature file in cucumber) a single WebDriver session. In general, you should try to test a single feature in your app in one spec file. Try to not have too many or too few tests in one file. However, there is no golden rule about that. + +Once you get more and more spec files you should start running them concurrently. To do so you can adjust the `maxInstances` property in your config file. WebdriverIO allows you to run your tests with maximum concurrency meaning that no matter how many files and tests you have, they could run all in parallel. Though there are certain limits (computer CPU, concurrency restrictions). + +> Let's say you have 3 different capabilities (Chrome, Firefox, and Safari) and you have set maxInstances to 1, the wdio test runner will spawn 3 processes. Therefore, if you have 10 spec files and you set maxInstances to 10; all spec files will get tested at the same time and 30 processes will get spawned. + +You can define the `maxInstance` property globally to set the attribute for all browser. If you run your own WebDriver grid it could be that you have more capacity for one browser than for an other one. In this case you can limit the `maxInstance` in your capability object: + +```js +// wdio.conf.js +exports.config = { + // ... + // set maxInstance for all browser + maxInstances: 10, + // ... + capabilities: [{ + browserName: "firefox" + }, { + // maxInstances can get overwritten per capability. So if you have an in-house WebDriver + // grid with only 5 firefox instance available you can make sure that not more than + // 5 instance gets started at a time. + browserName: 'chrome' + }], + // ... +} +``` + +## Inherit From Main Config File + +If you run your test suite in multiple environments (e.g. dev and integration) it could be helpful to have multiple configuration files to keep them easy manageable. Similar to the [page object concept](PageObjects.md) you first create a main config file. It contains all configurations you share across environments. Then for each environment you can create a file and supplement the information from the main config file with environment specific ones: + +```js +// wdio.dev.config.js +import merge from 'deepmerge'; +import wdioConf from './wdio.conf.js'; + +// have main config file as default but overwrite environment specific information +exports.config = merge(wdioConf.config, { + capabilities: [ + // more caps defined here + // ... + ], + + // run tests on sauce instead locally + user: process.env.SAUCE_USERNAME, + key: process.env.SAUCE_ACCESS_KEY, + services: ['sauce'] +}, { clone: false }); + +// add an additional reporter +exports.config.reporters.push('allure'); +``` + +## Group Test Specs + +You can easily group test specs in suites and run single specific suites instead of all of them. To do so you first need to define your suites in your wdio config: + +```js +// wdio.conf.js +exports.config = { + // define all tests + specs: ['./test/specs/**/*.spec.js'], + // ... + // define specific suites + suites: { + login: [ + './test/specs/login.success.spec.js', + './test/specs/login.failure.spec.js' + ], + otherFeature: [ + // ... + ] + }, + // ... +} +``` + +Now, if you want to only run a single suite, you can pass the suite name as cli argument like: + +```sh +$ wdio wdio.conf.js --suite login +``` + +or run multiple suites at once: + +```sh +$ wdio wdio.conf.js --suite login --suite otherFeature +``` + +## Run Selected Tests + +In some cases, you may wish to only execute a single test or a subset of your suites. With the `--spec` parameter you can specify which suite (Mocha, Jasmine) or feature (Cucumber) should be run. For example if you only want to run your login test, do: + +```sh +$ wdio wdio.conf.js --spec ./test/specs/e2e/login.js +``` + +or run multiple specs at once: + +```sh +$ wdio wdio.conf.js --spec ./test/specs/signup.js --spec ./test/specs/forgot-password.js +``` + +If the spec passed in is not a path to a spec file, it is used as a filter for the spec file names defined in your configuration file. To run all specs with the word 'dialog' in the spec file names, you could use: + +```sh +$ wdio wdio.conf.js --spec dialog +``` + +Note that each test file is running in a single test runner process. Since we don't scan files in advance (see the next section for information on piping filenames to `wdio`) you *can't* use for example `describe.only` at the top of your spec file to say Mocha to only run that suite. This feature will help you though to do that in the same way. + +## Exclude Selected Tests + +When needed, if you need to exclude particular spec file(s) from a run, you can use the `--exclude` parameter (Mocha, Jasmine) or feature (Cucumber). For example if you want to exclude your login test from the test run, do: + +```sh +$ wdio wdio.conf.js --exclude ./test/specs/e2e/login.js +``` + +or exclude multiple spec files: + +```sh +$ wdio wdio.conf.js --exclude ./test/specs/signup.js --exclude ./test/specs/forgot-password.js +``` + +or exclude a spec file when filtering using a suite: + +```sh +$ wdio wdio.conf.js --suite login --exclude ./test/specs/e2e/login.js +``` + +## Run Suites and Test Specs + +This will allow you to run an entire suite along with individual spec's. + +```sh +$ wdio wdio.conf.js --suite login --spec ./test/specs/signup.js +``` + +## Run Multiple, Specific Test Specs + +It is sometimes necessary—in the context of continuous integration and otherwise—to specify multiple sets of specs to be run at runtime. WebdriverIO's `wdio` command line utility will accept piped input in the form of filenames (from `find`, `grep`, or others). These filenames will override the list of glob patterns or filenames specified in the configuration file's `spec` list. + +```sh +$ grep -r -l --include "*.js" "myText" | wdio wdio.conf.js +``` + +***Note:** This will* not *override the `--spec` flag for running a single spec.* + +## Stop testing after failure + +With the `bail` option you can specify when WebdriverIO should stop the test run after test failures. This can be helpful when you have a big test suite and want to avoid long test runs when you already know that your build will break. The option expects a number that specifies after how many spec failures it should stop the whole test run. The default is `0` meaning that it always runs all tests specs it can find. + +Please see [Options Page](Options.md) for additional information on the bail configuration. \ No newline at end of file diff --git a/website/translated_docs/es-ES/PageObjects.md b/website/translated_docs/es-ES/PageObjects.md new file mode 100644 index 00000000000..70d4a2e3fc9 --- /dev/null +++ b/website/translated_docs/es-ES/PageObjects.md @@ -0,0 +1,109 @@ +--- +id: pageobjects +title: Page Object Pattern +--- +The new version (v4) of WebdriverIO was designed with Page Object Pattern support in mind. By introducing the "elements as first class citizens" principle it is now possible to build up large test suites using this pattern. There are no additional packages required to create page objects. It turns out that `Object.create` provides all necessary features we need: + +- inheritance between page objects +- lazy loading of elements +- encapsulation of methods and actions + +The goal behind page objects is to abstract any page information away from the actual tests. Ideally you should store all selectors or specific instructions that are unique for a certain page in a page object, so that you still can run your test after you've completely redesigned your page. + +First off we need a main page object that we call `Page`. It will contain general selectors or methods all page objects will inherit from. Apart from all child page objects `Page` is created using the prototype model: + +```js +export default class Page { + constructor() { + this.title = 'My Page'; + } + + open(path) { + browser.url(path); + } +} +``` + +We will always export an instance of a page object and never create that instance in the test. Since we are writing end to end tests we always see the page as a stateless construct the same way as each http request is a stateless construct. Sure, the browser can carry session information and therefore can display different pages based on different sessions, but this shouldn't be reflected within a page object. These state changes should emerge from your actual tests. + +Let's start testing the first page. For demo purposes we use [The Internet](http://the-internet.herokuapp.com) website by [Elemental Selenium](http://elementalselenium.com/) as guinea pig. Let's try to build a page object example for the [login page](http://the-internet.herokuapp.com/login). First step is to write all important selectors that are required in our `login.page` object as getter functions. As mentioned above we are using the `Object.create` method to inherit the prototype of our main page: + +```js +// login.page.js +import Page from './page'; + +class LoginPage extends Page { + + get username() { return $('#username'); } + get password() { return $('#password'); } + get submitBtn() { return $('form button[type="submit"]'); } + get flash() { return $('#flash'); } + get headerLinks() { return $$('#header a'); } + + open() { + super.open('login'); + } + + submit() { + this.submitBtn.click(); + } + +} + +export default new LoginPage(); +``` + +Defining selectors in getter functions might look a bit verbose but it is really useful. These functions get evaluated when you actually access the property and not when you generate the object. With that you always request the element before you do an action on it. + +WebdriverIO internally remembers the last result of a command. If you chain an element command with an action command it finds the element from the previous command and uses the result to execute the action. With that you can remove the selector (first parameter) and the command looks as simple as: + +```js +LoginPage.username.setValue('Max Mustermann'); +``` + +which is basically the same thing as: + +```js +var elem = $('#username'); +elem.setValue('Max Mustermann'); +``` + +or + +```js +$('#username').setValue('Max Mustermann'); +``` + +After we've defined all required elements and methods for the page we can start to write the test for it. All we need to do to use the page object is to require it and that's it. The `Object.create` method returns an instance of that page so we can start using it right away. By adding an additional assertion framework you can make your tests even more expressive: + +```js +// login.spec.js +import { expect } 'chai'; +import LoginPage '../pageobjects/login.page'; + +describe('login form', () => { + it('should deny access with wrong creds', () => { + LoginPage.open(); + LoginPage.username.setValue('foo'); + LoginPage.password.setValue('bar'); + LoginPage.submit(); + + expect(LoginPage.flash.getText()).to.contain('Your username is invalid!'); + }); + + it('should allow access with correct creds', () => { + LoginPage.open(); + LoginPage.username.setValue('tomsmith'); + LoginPage.password.setValue('SuperSecretPassword!'); + LoginPage.submit(); + + expect(LoginPage.flash.getText()).to.contain('You logged into a secure area!'); + }); +}); +``` + +From the structural side it makes sense to separate spec files and page objects and put them into different directories. Additionally you can give each page object the ending: `.page.js`. This way it is easy to figure out that you actually require a page object if you execute `var LoginPage = require('../pageobjects/form.page');`. + +This is the basic principle of how to write page objects with WebdriverIO. Note that you can build up way more complex page object structures than this. For example have specific page objects for modals or split up a huge page object into different sections objects that inherit from the main page object. The pattern gives you really a lot of opportunities to encapsulate page information from your actual tests, which is important to keep your test suite structured and clear in times where the project and number of tests grows. + +You can find this and some more page object examples in the [example folder](https://github.com/webdriverio/webdriverio/tree/master/examples/pageobject) on GitHub. \ No newline at end of file diff --git a/website/translated_docs/es-ES/Proxy.md b/website/translated_docs/es-ES/Proxy.md new file mode 100644 index 00000000000..be697584c3d --- /dev/null +++ b/website/translated_docs/es-ES/Proxy.md @@ -0,0 +1,51 @@ +--- +id: proxy +title: Proxy Setup +--- +You can tunnel two different types of request through a proxy: + +- connection between your test script and the browser driver (or WebDriver endpoint) +- connection between the browser and the internet + +## Proxy Between Driver And Test + +If your company has a corporate proxy (e.g. on `http://my.corp.proxy.com:9090`) for all outgoing requests you can set it using the `PROXY` environment variable as explained in the [request module](https://github.com/request/request#controlling-proxy-behaviour-using-environment-variables). Before you start the test make sure you exported the variable in the terminal as follows: + +```sh +$ export HTTP_PROXY=http://my.corp.proxy.com:9090 +$ export HTTPS_PROXY=https://my.corp.proxy.com:9090 +$ wdio wdio.conf.js +``` + +If you use [Sauce Connect Proxy](https://wiki.saucelabs.com/display/DOCS/Sauce+Connect+Proxy) start it via: + +```sh +$ sc -u $SAUCE_USERNAME -k $SAUCE_ACCESS_KEY --no-autodetect -p http://my.corp.proxy.com:9090 +``` + +## Proxy Between Browser And Internet + +In order to tunnel the connection between the browser and the internet you can set up a proxy which can be useful e.g. to capture network information and other data using tools like [BrowserMob Proxy](https://github.com/lightbody/browsermob-proxy). The proxy parameters can be applied via the standard capabilities the following way: + +```js +// wdio.conf.js + +exports.config = { + // ... + capabilities: [{ + browserName: 'chrome', + // ... + proxy: { + proxyType: "manual", + httpProxy: "http://corporate.proxy:8080", + socksUsername: "codeceptjs", + socksPassword: "secret", + noProxy: "127.0.0.1,localhost" + }, + // ... + }], + // ... +} +``` + +For more information see the [WebDriver specification](https://w3c.github.io/webdriver/#proxy). \ No newline at end of file diff --git a/website/translated_docs/es-ES/Retry.md b/website/translated_docs/es-ES/Retry.md new file mode 100644 index 00000000000..6f2f9709ca5 --- /dev/null +++ b/website/translated_docs/es-ES/Retry.md @@ -0,0 +1,77 @@ +--- +id: retry +title: Retry Flaky Tests +--- +You can rerun certain tests with the WebdriverIO testrunner that turn out to be unstable due to e.g. flaky network or race conditions. However it is not recommended to just increase the rerun rate if tests become unstable. + +## Rerun suites in MochaJS + +Since version 3 of MochaJS you can rerun whole test suites (everything inside an `describe` block). If you use Mocha you should favor this retry mechanism instead of the WebdriverIO implementation that only allows you to rerun certain test blocks (everything within an `it` block). Here is an example how to rerun a whole suite in MochaJS: + +```js +describe('retries', function() { + // Retry all tests in this suite up to 4 times + this.retries(4); + + beforeEach(() => { + browser.url('http://www.yahoo.com'); + }); + + it('should succeed on the 3rd try', function () { + // Specify this test to only retry up to 2 times + this.retries(2); + console.log('run'); + expect(browser.isVisible('.foo')).to.eventually.be.true; + }); +}); +``` + +## Rerun single tests in Jasmine or Mocha + +To rerun a certain test block just apply the number of reruns as last parameter after the test block function: + +```js +describe('my flaky app', () => { + /** + * spec that runs max 4 times (1 actual run + 3 reruns) + */ + it('should rerun a test at least 3 times', () => { + // ... + }, 3); +}); +``` + +The same works for hooks too: + +```js +describe('my flaky app', () => { + /** + * hook that runs max 2 times (1 actual run + 1 rerun) + */ + beforeEach(() => { + // ... + }, 1) + + // ... +}); +``` + +It is **not** possible to rerun whole suites with Jasmine, only hooks or test blocks. + +## Rerun Step Definitions in Cucumber + +To define a rerun rate for a certain step definitions just apply a retry option to it, like: + +```js +module.exports = function () { + /** + * step definition that runs max 3 times (1 actual run + 2 reruns) + */ + this.Given(/^some step definition$/, { wrapperOptions: { retry: 2 } }, () => { + // ... + }) + // ... +}) +``` + +Reruns can only be defined in your step definitions file and not in your feature file. \ No newline at end of file diff --git a/website/translated_docs/es-ES/Selectors.md b/website/translated_docs/es-ES/Selectors.md new file mode 100644 index 00000000000..78e6f1b3b19 --- /dev/null +++ b/website/translated_docs/es-ES/Selectors.md @@ -0,0 +1,252 @@ +--- +id: selectors +title: Selectors +--- +The JsonWireProtocol provides several selector strategies to query an element. WebdriverIO simplifies them to keep selecting elements simple. The following selector types are supported: + +## CSS Query Selector + +```js +const elem = $('h2.subheading a'); +elem.click(); +``` + +## Link Text + +To get an anchor element with a specific text in it, query the text starting with an equal (=) sign. For example: + +```html +WebdriverIO +``` + +You can query this element by calling: + +```js +const link = $('=WebdriverIO'); +console.log(link.getText()); // outputs: "WebdriverIO" +console.log(link.getAttribute('href')); // outputs: "http://webdriver.io" +``` + +## Partial Link Text + +To find a anchor element whose visible text partially matches your search value, query it by using `*=` in front of the query string (e.g. `*=driver`) + +```html +WebdriverIO +``` + +You can query this element by calling: + +```js +const link = $('*=driver'); +console.log(link.getText()); // outputs: "WebdriverIO" +``` + +## Element with certain text + +The same technique can be applied to elements as well, e.g. query a level 1 heading with the text "Welcome to my Page": + +```html +

Welcome to my Page

+``` + +You can query this element by calling: + +```js +const header = $('h1=Welcome to my Page'); +console.log(header.getText()); // outputs: "Welcome to my Page" +console.log(header.getTagName()); // outputs: "h1" +``` + +or using query partial text + +```js +const header = $('h1*=Welcome'); +console.log(header.getText()); // outputs: "Welcome to my Page" +``` + +The same works for ids and class names: + +```html +WebdriverIO is the best +``` + +You can query this element by calling: + +```js +const classNameAndText = $('.someElem=WebdriverIO is the best'); +console.log(classNameAndText.getText()); // outputs: "WebdriverIO is the best" + +const idAndText = $('#elem=WebdriverIO is the best'); +console.log(idAndText.getText()); // outputs: "WebdriverIO is the best" + +const classNameAndPartialText = $('.someElem*=WebdriverIO'); +console.log(classNameAndPartialText.getText()); // outputs: "WebdriverIO is the best" + +const idAndPartialText = $('#elem*=WebdriverIO'); +console.log(idAndPartialText.getText()); // outputs: "WebdriverIO is the best" +``` + +## Tag Name + +To query an element with a specific tag name use `` or `` + +```html +WebdriverIO is the best +``` + +You can query this element by calling: + +```js +const classNameAndText = $(''); +console.log(classNameAndText.getText()); // outputs: "WebdriverIO is the best" +``` + +## xPath + +It is also possible to query elements via a specific [xPath](https://developer.mozilla.org/en-US/docs/Web/XPath). The selector has to have a format like `//BODY/DIV[6]/DIV[1]/SPAN[1]`. + +```html + + +

foobar

+

barfoo

+ + +``` + +You can query the second paragraph by calling: + +```js +const paragraph = $('//BODY/P[1]'); +console.log(paragraph.getText()); // outputs: "barfoo" +``` + +You can use xPath to also traverse up and down the DOM tree, e.g. + +```js +const parent = paragraph.$('..'); +console.log(parent.getTagName()); // outputs: "body" +``` + +## JS Function + +You can also use JS functions to fetch elements using web native APIs. This of course is only supported in a web environment (e.g. browser or web context in mobile). Given the following HTML structure: + +```html + + +

foobar

+

barfoo

+ + +``` + +You can query the sibling element of `#elem` as follows: + +```js +const elem = $('#elem') // or $(() => document.getElementById('elem')) +elem.$(() => this.nextSibling.nextSibling) // (first sibling is #text with value ("↵")) +``` + +## Mobile Selectors + +For (hybrid/native) mobile testing you have to use mobile strategies and use the underlying device automation technology directly. This is especially useful when a test needs some fine-grained control over finding elements. + +### Android UiAutomator + +Android’s UI Automator framework provides a number of ways to find elements. You can use the [UI Automator API](https://developer.android.com/tools/testing-support-library/index.html#uia-apis), in particular the [UiSelector class](https://developer.android.com/reference/android/support/test/uiautomator/UiSelector.html) to locate elements. In Appium you send the Java code, as a string, to the server, which executes it in the application’s environment, returning the element or elements. + +```js +const selector = 'new UiSelector().text("Cancel").className("android.widget.Button")'; +const Button = $(`android=${selector}`); +Button.click(); +``` + +### iOS UIAutomation + +When automating an iOS application, Apple’s [UI Automation framework](https://developer.apple.com/library/prerelease/tvos/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/UIAutomation.html) can be used to find elements. This JavaScript [API](https://developer.apple.com/library/ios/documentation/DeveloperTools/Reference/UIAutomationRef/index.html#//apple_ref/doc/uid/TP40009771) has methods to access to the view and everything on it. + +```js +const selector = 'UIATarget.localTarget().frontMostApp().mainWindow().buttons()[0]'; +const Button = $(`ios=${selector}`); +Button.click(); +``` + +You can also use predicate searching within iOS UI Automation in Appium, to control element finding even further. See [here](https://github.com/appium/appium/blob/master/docs/en/writing-running-appium/ios/ios-predicate.md) for details. + +### iOS XCUITest predicate strings and class chains + +With iOS 10 and above (using the XCUITest driver), you can use [predicate strings](https://github.com/facebook/WebDriverAgent/wiki/Predicate-Queries-Construction-Rules): + +```js +const selector = 'type == \'XCUIElementTypeSwitch\' && name CONTAINS \'Allow\''; +const Switch = $(`ios=predicate=${selector}`); +Switch.click(); +``` + +And [class chains](https://github.com/facebook/WebDriverAgent/wiki/Class-Chain-Queries-Construction-Rules): + +```js +const selector = '**/XCUIElementTypeCell[`name BEGINSWITH "D"`]/**/XCUIElementTypeButton'; +const Button = $(`ios=chain=${selector}`); +Button.click(); +``` + +### Accessibility ID + +The `accessibility id` locator strategy is designed to read a unique identifier for a UI element. This has the benefit of not changing during localization or any other process that might change text. In addition, it can be an aid in creating cross-platform tests, if elements that are functionally the same have the same accessibility id. + +- For iOS this is the `accessibility identifier` laid out by Apple [here](https://developer.apple.com/library/prerelease/ios/documentation/UIKit/Reference/UIAccessibilityIdentification_Protocol/index.html). +- For Android the `accessibility id` maps to the `content-description` for the element, as described [here](https://developer.android.com/training/accessibility/accessible-app.html). + +For both platforms getting an element, or multiple elements, by their `accessibility id` is usually the best method. It is also the preferred way, in replacement of the deprecated `name` strategy. + +```js +const elem = $('~my_accessibility_identifier'); +elem.click(); +``` + +### Class Name + +The `class name` strategy is a `string` representing a UI element on the current view. + +- For iOS it is the full name of a [UIAutomation class](https://developer.apple.com/library/prerelease/tvos/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/UIAutomation.html), and will begin with `UIA-`, such as `UIATextField` for a text field. A full reference can be found [here](https://developer.apple.com/library/ios/navigation/#section=Frameworks&topic=UIAutomation). +- For Android it is the fully qualified name of a [UI Automator](https://developer.android.com/tools/testing-support-library/index.html#UIAutomator) [class](https://developer.android.com/reference/android/widget/package-summary.html), such `android.widget.EditText` for a text field. A full reference can be found [here](https://developer.android.com/reference/android/widget/package-summary.html). + +```js +// iOS example +$('UIATextField').click(); +// Android example +$('android.widget.DatePicker').click(); +``` + +## Chain Selectors + +If you want to be more specific in your query, you can chain your selector until you've found the right element. If you call element before your actual command, WebdriverIO starts query from that element. For example if you have a DOM structure like: + +```html +
+
+ + + +
+
+ + + +
+
+ + + +
+
+``` + +And you want to add product B to the cart it would be difficult to do that just by using the CSS selector. With selector chaining it gets way easier as you can narrow down the desired element step by step: + +```js +$('.row .entry:nth-child(1)').$('button*=Add').click(); +``` \ No newline at end of file diff --git a/website/translated_docs/es-ES/SetupTypes.md b/website/translated_docs/es-ES/SetupTypes.md new file mode 100644 index 00000000000..f3f18bfcbd5 --- /dev/null +++ b/website/translated_docs/es-ES/SetupTypes.md @@ -0,0 +1,57 @@ +--- +id: setuptypes +title: How to setup WebdriverIO +--- +WebdriverIO can be used for various purposes. It implements the Webdriver protocol API and can run a 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 + +Probably the 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 +const { remote } = require('webdriverio'); + +(async () => { + const browser = await remote({ + logLevel: 'trace', + capabilities: { + browserName: 'chrome' + } + }) + + await browser.url('https://duckduckgo.com/') + + const inputElem = await browser.$('#search_form_input_homepage') + await inputElem.setValue('WebdriverIO') + + const submitBtn = await browser.$('#search_button_homepage') + await submitBtn.click() + + console.log(await browser.getTitle()) // outputs: "Title is: WebdriverIO (Software) at DuckDuckGo" + + await browser.deleteSession() +})().catch((e) => console.error(e)) +``` + +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 a 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 the same example from above written as a test spec and executed by wdio: + +```js +describe('DuckDuckGo search', () => { + it('searches for WebdriverIO', () => { + browser.url('https://duckduckgo.com/') + + $('#search_form_input_homepage').setValue('WebdriverIO') + $('#search_button_homepage').click() + + const 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](GettingStarted.md) section for more information. \ No newline at end of file diff --git a/website/translated_docs/es-ES/Timeouts.md b/website/translated_docs/es-ES/Timeouts.md new file mode 100644 index 00000000000..2144ccfae16 --- /dev/null +++ b/website/translated_docs/es-ES/Timeouts.md @@ -0,0 +1,124 @@ +--- +id: timeouts +title: Timeouts +--- +Each command in WebdriverIO is an asynchronous operation where a request is fired to the Selenium server (or a cloud service like [Sauce Labs](https://saucelabs.com/)), and its response contains the result once the action has completed or failed. Therefore time is a crucial component in the whole testing process. When a certain action depends on the state of a different action, you need to make sure that they get executed in the right order. Timeouts play an important role when dealing with these issues. + +## Selenium timeouts + +### Session Script Timeout + +A session has an associated session script timeout that specifies a time to wait for asynchronous scripts to run. Unless stated otherwise it is 30 seconds. You can set this timeout via: + +```js +browser.setTimeout({ 'script': 60000 }); +browser.executeAsync((done) => { + console.log('this should not fail'); + setTimeout(done, 59000); +}); +``` + +### Session Page Load Timeout + +A session has an associated session page load timeout that specifies a time to wait for the page loading to complete. Unless stated otherwise it is 300,000 milliseconds. You can set this timeout via: + +```js +browser.setTimeout({ 'pageLoad': 10000 }); +``` + +> The `pageLoad` keyword is a part of the official WebDriver [specification](https://www.w3.org/TR/webdriver/#set-timeouts), but might not be [supported](https://github.com/seleniumhq/selenium-google-code-issue-archive/issues/687) for your browser (the previous name is `page load`). + +### Session Implicit Wait Timeout + +A session has an associated session implicit wait timeout that specifies a time to wait for the implicit element location strategy when locating elements using the [`findElement`](/docs/api/webdriver.html#findelement) or [`findElements`](/docs/api/webdriver.html#findelements) commands (respectively [`$`](/docs/api/browser/$.html) or [`$$`](/docs/api/browser/$$.html) when running WebdriverIO with or without wdio testrunner). Unless stated otherwise it is zero milliseconds. You can set this timeout via: + +```js +browser.setTimeout({ 'implicit': 5000 }); +``` + +## WebdriverIO related timeouts + +### WaitForXXX timeout + +WebdriverIO provides multiple commands to wait on elements to reach a certain state (e.g. enabled, visible, existing). These commands take a selector argument and a timeout number which declares how long the instance should wait for that element to reach the state. The `waitforTimeout` option allows you to set the global timeout for all waitFor commands so you don't need to set the same timeout over and over again. Note the lowercase `f`. + +```js +// wdio.conf.js +exports.config = { + // ... + waitforTimeout: 5000, + // ... +}; +``` + +In your test you now can do this: + +```js +const myElem = $('#myElem'); +myElem.waitForVisible(); + +// you can also overwrite the default timeout if needed +myElem.waitForVisible(10000); +``` + +## Framework related timeouts + +Also the testing framework you use with WebdriverIO has to deal with timeouts especially since everything is asynchronous. It ensures that the test process don't get stuck if something went wrong. By default the timeout is set to 10 seconds which means that a single test should not take longer than that. A single test in Mocha looks like: + +```js +it('should login into the application', () => { + browser.url('/login'); + + const form = $('form'); + const username = $('#username'); + const password = $('#password'); + + username.setValue('userXY'); + password.setValue('******'); + form.submit(); + + expect(browser.getTitle()).to.be.equal('Admin Area'); +}); +``` + +In Cucumber the timeout applies to a single step definition. However if you want to increase the timeout because your test takes longer than the default value you need to set it in the framework options. This is for Mocha: + +```js +// wdio.conf.js +exports.config = { + // ... + framework: 'mocha', + mochaOpts: { + timeout: 20000 + }, + // ... +} +``` + +For Jasmine: + +```js +// wdio.conf.js +exports.config = { + // ... + framework: 'jasmine', + jasmineNodeOpts: { + defaultTimeoutInterval: 20000 + }, + // ... +} +``` + +and for Cucumber: + +```js +// wdio.conf.js +exports.config = { + // ... + framework: 'cucumber', + cucumberOpts: { + timeout: 20000 + }, + // ... +} +``` \ No newline at end of file diff --git a/website/translated_docs/es-ES/TypeScript.md b/website/translated_docs/es-ES/TypeScript.md new file mode 100644 index 00000000000..a1bd7c2df88 --- /dev/null +++ b/website/translated_docs/es-ES/TypeScript.md @@ -0,0 +1,39 @@ +--- +id: typescript +title: TypeScript Setup +--- +Similar to Babel setup, you can register [TypeScript](http://www.typescriptlang.org/) to compile your .ts files in your before hook of your config file. You will need [ts-node](https://github.com/TypeStrong/ts-node) and [tsconfig-paths](https://github.com/dividab/tsconfig-paths) as the installed devDependencies. + +```js + before: function() { + require('ts-node/register'); + }, +``` + +Similarly for mocha: + +```js + mochaOpts: { + ui: 'bdd', + compilers: [ + 'ts-node/register', + 'tsconfig-paths/register' + ] + }, +``` + +and: + +```json + //tsconfig.json + "compilerOptions": { + "baseUrl": ".", + "paths": { + "*": [ "./*" ], + "src/*": ["./src/*"] + } + }, + "include": [ + "./src/**/*.ts" + ] +``` \ No newline at end of file diff --git a/website/translated_docs/es-ES/WatchFiles.md b/website/translated_docs/es-ES/WatchFiles.md new file mode 100644 index 00000000000..fb3f3b08f84 --- /dev/null +++ b/website/translated_docs/es-ES/WatchFiles.md @@ -0,0 +1,25 @@ +--- +id: watcher +title: Watch Test Files +--- +With the WDIO testrunner you can watch files while you are working on them. They automatically rerun if you change either something in your app or in your test files. By adding a `--watch` flag when calling the `wdio` command the testrunner will wait for file changes after it ran all tests, e.g. + +```sh +$ wdio wdio.conf.js --watch +``` + +By default it only watches for changes in your `specs` files. However by setting a `filesToWatch` property in your `wdio.conf.js` that contains a list of file paths (globbing supported) it will also watch for these files to be changed in order to rerun the whole suite. This is useful if you want to automatically rerun all your tests if you have changed your application code, e.g. + +```js +// wdio.conf.js +export.config = { + // ... + filesToWatch: [ + // watch for all JS files in my app + './src/app/**/*.js' + ], + // ... +} +``` + +**Note:** ensure that you run as much tests in parallel as possible. E2E tests are by nature slow and rerunning tests is only useful if you can keep the individual testrun time short. In order to save time the testrunner keeps the WebDriver sessions alive while waiting for file changes. Make sure your WebDriver backend can be modified so that it doesn't automatically close the session if no command was executed after some specific time. \ No newline at end of file diff --git a/website/translated_docs/es-ES/repl.md b/website/translated_docs/es-ES/repl.md new file mode 100644 index 00000000000..2a8b5dfb058 --- /dev/null +++ b/website/translated_docs/es-ES/repl.md @@ -0,0 +1,21 @@ +--- +id: repl +title: REPL interface +--- +With `v4.5.0` WebdriverIO introduces a [REPL](https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop) interface that helps you to not only discover the framework API but also debug and inspect your tests. It can be used in multiple ways. First you can use it as CLI command and spawn a WebDriver session from the command line, e.g. + +```sh +$ wdio repl chrome +``` + +This would open a Chrome browser that you can control with the REPL interface. Make sure you have a browser driver running on port `4444` in order to initiate the session. If you have a [SauceLabs](https://saucelabs.com) (or other cloud vendor) account you can also directly run the browser on your command line in the cloud via: + +```sh +$ wdio repl chrome -u $SAUCE_USERNAME -k $SAUCE_ACCESS_KEY +``` + +You can apply any options (see `wdio --help`) available for your REPL session. + +![WebdriverIO REPL](http://webdriver.io/images/repl.gif) + +Another way to use the REPL is in between your tests via the [`debug`](/api/utility/debug.html) command. It will stop the browser when executed and enables you to jump into the application (e.g. to the dev tools) or control the browser from the command line. This is helpful when some commands don't trigger a certain action as expected. With the REPL you can then try out the commands to see which are working most reliable. \ No newline at end of file