Quelle est la différence entre NightwatchJS et WebdriverIO?

Question

Comme le titre l'indique, quelle est la différence entre Nightwatch.js et Webdriver.io?

On dirait qu'ils ont un peu la même syntaxe et font presque la même chose. Comment sont-ils différents?

J'ai besoin de choisir entre eux.

QualiT · Accepted Answer

J'ai écrit plusieurs fois une suite de tests en utilisant chacun de ces outils.

Webdriver.io vous permet d'écrire vos scénarios de test "à partir de zéro" et d'avoir un contrôle important sur la génération de rapports, en intégrant par exemple slack à l'aide de slack npm et d'autres packages. Vous devez connaître ou apprendre rapidement node.js. En plus de fonctionner très bien avec les navigateurs de bureau, il s’intègre bien avec Appium, Android Studio et Xcode afin que vous puissiez exécuter vos tests automatisés sur Android émulateurs et Des simulateurs iOS localement. Vous devrez les installer et écrire du code pour indiquer à Appium les pilotes à utiliser, sélectionner les fonctionnalités, etc.

Nightwatch est une solution assez complète qui utilise un itérateur pour réessayer automatiquement les tests jusqu'à trois fois en cas d'échec. Nightwatch prend en charge correctement l'intégration avec VM, comme SauceLabs, de sorte que vous puissiez théoriquement exécuter vos scénarios de test sur plus de 700 combinaisons de plates-formes/navigateurs/versions différentes sans écrire de code pour gérer chaque pilote. . Nightwatch gère le démarrage et la fermeture de Selenium pour vous. Bien que ce dernier semble très impressionnant, en réalité, il faut beaucoup de travail pour atteindre et maintenir ce niveau de couverture de test. Nightwatch a également une séparation assez intégrée des problèmes, vous permettant de définir des commandes personnalisées et de les exiger dans votre scénario de test de base ou vos tests individuels. Vous pouvez modulariser certaines parties des tests et les importer afin de ne pas avoir à réécrire constamment, par exemple, le test de connexion pour une utilisation dans plusieurs cas. En outre, vous pouvez utiliser des commandes personnalisées pour importer des sélecteurs en tant que paires clé-valeur.

Après les avoir utilisées, je les résumerais ainsi:

webdriver.io: Si vous recherchez plus de contrôle, une solution très personnalisée et que vous n'avez pas besoin d'un itérateur, vous êtes confiant en savez suffisamment pour écrire du code afin de sélectionner le pilote de votre navigateur, définir les capacités et vous souhaitez un contrôle personnalisé de vos rapports.

Nightwatch: si vous voulez commencer à écrire des tests rapidement, sachez qu'il sera relativement facile de les exécuter sur des plateformes/navigateurs/versions spécifiques et que vous permettent toujours une grande flexibilité pour étendre vos tests en écrivant des commandes personnalisées.

Une autre option est Dalek.js, qui a la création facile de script de Nightwatch, mais sans tous les gadgets.

Avant d'exécuter nightwatch, vous pouvez configurer les navigateurs dans le fichier Magellan.json. Lorsque vous exécutez votre test, vous appelez les navigateurs ou un ensemble de navigateurs (un "profil") en tant qu'arguments de ligne de commande.

Pour les navigateurs locaux:

./node_modules/.bin/magellan --serial --browsers=chrome,firefox

En supposant que vous ayez configuré un compte saucelabs et ajouté votre nom d'utilisateur et votre clé d'accès, vous pouvez appeler un profil de navigateur tel que celui-ci:

./node_modules/.bin/magellan --serial --profile=myBrowsers

Cela suppose que vous avez configuré un profil appelé myBrowsers dans le fichier Magellan.json, comme suit:

{ "profiles": { "myBrowsers": [ { "browser": "chrome_46_OS_X_10_10_Desktop" }, { "browser": "firefox_42_Windows_2012_R2_Desktop" }, { "browser": "safari_8_OS_X_10_10_Desktop" }, { "browser": "safari_7_OS_X_10_9_Desktop" }, { "browser": "safari_9_OS_X_10_11_Desktop" }, { "browser": "IE_10_Windows_2012_Desktop" }, { "browser": "IE_11_Windows_2012_R2_Desktop" }, { "browser": "chrome_45_OS_X_10_8_Desktop" }, { "browser": "chrome_45_OS_X_10_9_Desktop" }, { "browser": "chrome_45_OS_X_10_10_Desktop" }, { "browser": "chrome_45_OS_X_10_11_Desktop" }, { "browser": "chrome_46_OS_X_10_10_Desktop" }, { "browser": "chrome_45_Windows_10_Desktop" }, { "browser": "chrome_45_Windows_2003_Desktop" }, { "browser": "chrome_45_Windows_2008_Desktop" }, { "browser": "chrome_45_Windows_2012_Desktop" }, { "browser": "chrome_45_Windows_2012_R2_Desktop" }, { "browser": "chrome_46_Windows_10_Desktop" }, { "browser": "chrome_46_Windows_2003_Desktop" }, { "browser": "chrome_46_Windows_2008_Desktop" }, { "browser": "chrome_46_Windows_2012_Desktop" }, { "browser": "chrome_46_Windows_2012_R2_Desktop" }, { "browser": "firefox_42_OS_X_10_9_Desktop" }, { "browser": "firefox_42_Windows_2012_R2_Desktop" }, { "browser": "Android_4_4_Linux_Samsung_Galaxy_S4_Emulator", "orientation": "portrait" }, { "browser": "ipad_8_4_iOS_iPad_Simulator", "orientation": "landscape"}, { "browser": "ipad_8_4_iOS_iPad_Simulator", "orientation": "landscape"}, { "browser": "ipad_9_0_iOS_iPad_Simulator", "orientation": "landscape"}, { "browser": "ipad_9_0_iOS_iPad_Simulator", "orientation": "portrait"}, { "browser": "ipad_9_1_iOS_iPad_Simulator", "orientation": "landscape"}, { "browser": "ipad_9_1_iOS_iPad_Simulator", "orientation": "portrait"}, { "browser": "iphone_9_1_iOS_iPhone_Simulator", "orientation": "portrait"}, { "browser": "iphone_9_1_iOS_iPhone_Simulator", "orientation": "landscape"} ] }

}

CERTAINS DES ARGS DE LIGNE DE COMMANDE LES PLUS UTILES (facultatif):

le fait de basculer l'argument --serial entraîne la sérialisation de l'exécution du test et offre une expérience de test plus détaillée, dans laquelle vous pouvez consulter les erreurs renvoyées lors d'une exécution. L'exécution des tests prend également beaucoup plus de temps car elle attend la fin des tests.

en ajoutant l'argument --sauce une fois que vos scénarios de test fonctionnent pour les navigateurs existants sur votre ordinateur local, vous pouvez accéder aux 760 navigateurs actuellement pris en charge par Sauce Labs. Allez-y, collez ceci dans le terminal et appuyez sur Entrée:

./node_modules/.bin/magellan --serial --list_browsers

Pour chaque périphérique/navigateur que vous souhaitez tester, vous ajoutez simplement la liste dans la colonne Option de ligne de commande Copier-coller sous forme de valeurs séparées par des virgules après --browser = lors de l'exécution du script. REMARQUE: lorsque vous exécutez sans --sauce, vous pouvez simplement utiliser --browser = chrome ou --browser = chrome, firefox

BREAKING IT DOWN:

Utiliser nightwatch sans --sauce mais avec --serial est un excellent moyen de commencer. Travaillez sur votre script jusqu'à ce que vous ayez validé les éléments que vous souhaitez vérifier et lorsque vous êtes sûr que tous les tests doivent réussir, exécutez-le avec les laboratoires de sauce et les principaux navigateurs que vous souhaitez tester. Une fois que vous êtes sûr que les principaux navigateurs sont couverts, vous pouvez le lancer sans --serial pour réduire le temps d'exécution (utile sur Sauce Labs, ce qui coûtera de l'argent).

Mais assez de prosélytisme, vous pouvez trouver ce dont vous avez besoin à propos de Saucelabs ici: https://wiki.saucelabs.com/display/DOCS/The+Sauce+Labs+Cookbook+Home

Et pour un exemple standard de Nightwatch, faites le monde canonique du salut: essayez ce chauffeur

MISES À JOUR: Quelques points que les gens soulèvent et qui me sont venus à l'esprit depuis la publication de cet article.

Webdriver.io: Comme il n'y a pas d'itérateur, la capacité de récupération après échec lors d'une exécution de test est réduite, cela signifie que les échecs sont plus définitifs. Parce que cela est purement asynchrone, vous pouvez avoir des maux de tête pour retracer l'origine exacte de la défaillance. ~~Vous devrez peut-être également créer des scripts de démontage distincts pour toutes les données que vous créez afin d'éviter les collisions de données lors de l'exécution.~~

Nightwatch.js: Comme l’itérateur vous permet d’essayer à nouveau, vous serez souvent en mesure de localiser l’échec de votre script. Cela peut vous permettre de trouver plus rapidement le défaut au lieu de vous concentrer sur les raisons de l'échec de votre script. Il est également plus facile de désactiver vos scripts individuels.

MISE À JOUR 2:

Avec Nightwatch, des tests plus courts sont utiles/encouragés. Parce que l'itérateur lit les fichiers de test en mémoire à chaque itération juste avant son exécution, vous pouvez littéralement éditer les tests entre chaque exécution d'itération. Permettez-moi de dire que d'une manière différente: Votre suite Nightwatch:

test_1 starts test_1 FAIL // because you made a trivial error in your test case test-2 starts // while it is running, you make the change, save it test-2 PASS test_1 starts // the iteration starts * with your change! * test_1 PASS ============= Suite Complete ============= Status: PASSED Runtime: 2m 48.3s Total tests: 2 Successful: 2 / 2 1 test(s) have retried: 1 time(s)

D'autre part, il est facile de configurer des webhooks Slack avec node/webdriver.io. Cela signifie que vous pouvez configurer vos tests de noeud/webdriver.io pour qu'ils fassent rapport à Slack lorsqu'ils sont terminés. Les clients apprécient cela, car une fois la construction terminée, ils voient rapidement les résultats de l’automatisation, tels que:

Testing Test automatisé de [nom du client/produit ici] Sprint ##. #. # Transmis à [URL du serveur ou adresse IP] avec OS X Firefox 59.0.2

❌ Les tests automatisés de [nom du client/produit ici] Sprint ##. #. # Ont échoué le [URL du serveur ou l'adresse IP] avec OS X Firefox 59.0.2.

UPDATE 3 (6 août 2017)

Après avoir passé une année et demie à travailler quotidiennement avec les deux, je souhaite ajouter les points suivants.

Un nombre similaire de packages NPM s'intègrent à chacun, mais vous remarquerez qu'il existe beaucoup plus de questions Stackoverflow concernant Nightwatch (4x). Je pense que cela est dû au fait que Webdriver.io est davantage une approche autonome du test automatisé [c'est mon opinion, et j'apprécie les retours/réactions en retour]. Ceux qui l'utilisent n'auront pas de questions sur son utilisation, mais sur des techniques spécifiques.

Nightwatch serait un meilleur point d’entrée pour une personne ayant une expérience étendue de Selenium IDE) et de javascript solide. Elle propose de nombreuses solutions utiles prédéfinies. Quel peu d’expérience que je possède avec Dalek suggère que ce serait pareil être une bonne option.

Quelqu'un avec plus de javascript et peut-être un peu de programmation orientée objet et une expérience unix trouverait probablement Webdriver.io comme meilleur. Comme je le fais actuellement, c’est une excellente option pour créer votre propre cadre personnalisé. Si vous pouvez imaginer comment vous souhaitez que votre initialisation, votre contrôle de flux et vos rapports fonctionnent, et que vous soyez prêt à investir dans la sueur du capital, c'est tout indiqué.

On m'a demandé ci-dessous ce que je préfère, et je préfère Webdriver.io pour les tests e2e approfondis de loin. Bien que j'utilise souvent un référentiel Nightwatch personnalisé pour la plupart des travaux clients construits sur notre plate-forme, cela peut changer dans un proche avenir si je construis ma propre solution Webdriver.io.

UPDATE 4 (2 mai 2018)

Mise à jour pour clarifier le contrôle de Selenium et des pilotes de navigateur, ainsi que l'ajout de détails sur l'utilisation d'Appium et de Xcode/Android Studio.

iamdanchiv · Answer

Cette question est devenue un véritable carrefour pour de nombreuses implémentations POC et/ou MVP d'automatisation Web. Je ne veux pas que cela dicte la mauvaise direction!

Ainsi, j'estime qu'il faut une réponse plus complète, avec une portée plus large (facilité d'installation, dépendances, plugins importants, services, rapporteurs, documentation, support et autres intégrations}) et, espérons-le, une prestation plus subjective que la réponse acceptée.

❒ TL; DR: (pour les lazies!)

Si vous êtes débutant, commencez avec l’automatisation Web ou souhaitez développer la couverture de test pour une application Web de taille petite à moyenne, puis choisissez des deux! (pourrait tout aussi bien faire une pièce de monnaie!) Les différences entre les deux sont très minces à un niveau inférieur. _ {Les fissures deviennent des lacunes} _ uniquement lorsque vous atteignez des défis plus complexes, plus tard.

Si vous envisagez de construire n harnais d'automatisation à part entière et lourd} _ afin de garantir la qualité d'une grande entreprise une application Web ou un portail Web massif, puis lisez l'intégralité du message (ou suivez mes conseils et passez à WDIO!)

❒ Titres de compétence: (Qu'est-ce qui me recommande d'avoir son mot à dire?)

Je travaille avec les {frameworks de test basés sur NodeJS} _ depuis début 2013, après avoir occupé divers rôles en ingénierie d'automatisation de l'assurance qualité, du premier échelon au supérieur, en passant par le responsable de l'assurance qualité. Je vais résumer mon expérience de travail avec ces frameworks et l'automatisation Web:

❒ Recommandation: Si vous devez choisir entre les deux pour la mise en oeuvre d'un POC , je vous recommande de lire toute cette réponse. Ce n’est qu’alors que vous pourrez disposer d’un Outlook complet sur l’ensemble du tablea.

❒ Détails du projet:

.-------------.---------.-----------.----------.-------------.--------------. | project | ⭐️stars | ????????forks | ????issues| ???? open PRs | ???? updated | :-------------+---------+-----------+----------+-------------+--------------: | webdriverio | 5050 | 1450 | 68 | 6 | 12.Jul.2019 | :-------------+---------+-----------+----------+-------------+--------------: | nightwatch | 9450 | 930 | 116|⁺306| 15 | 01.Jul.2019 | '-------------'---------'-----------'----------'-------------'--------------'

⁺ - la deuxième valeur représente la somme de Problèmes non résolus _ (libellé open) & Problèmes obsolètes} _ (stale étiquette, 238 d'entre eux ). Si vous êtes curieux, (je sais que je l'étais!) stale représente l'étiquette attribuée aux tickets ouverts inactifs depuis un moment, à l'aide d'un bot. (C'est assez méfiant!)

❖ À emporter peu profonds: (Il s'agit d'une interprétation personnelle des chiffres ci-dessus, veuillez donc les prendre avec un grain de sel)

➮ (???? Force) NightwatchJS est a solution plus largement utilisée} (idée mise en œuvre par le nombre total d'étoiles Github), elle a rapidement gagné en notoriété après avoir été intégrée et évangélisée par les équipes d'assurance qualité de plusieurs grandes entreprises (par exemple: LinkedIn, AirBnB, GoPro, etc.)

➮ (???? Force) En raison de son {robustesse, modularité et extensibilité} _, WebdriverIO propose un plus grand nombre de forks. Les intégrations récentes avec de nombreux services populaires et à la demande (par exemple: ChromeDevTools, React & VisualRegression}) _) ont également renforcé la confiance de la communauté de test dans la solution.

➮ (???? Weakness) Même s'il ne s'agit pas d'une critique spécifique à la technologie, je suis récemment devenu mécontent du manque constant de professionnalisme entourant le NightwatchJS équipe. Ainsi, mis à part le billets périmés , vous pouvez toujours trouver votre BUG parfaitement valide, soudainement fermé, avec peu d'informations, voire aucune. Parfois, vous obtenez quelque chose de drôle comme this .

➮ (???? Opportunity) Les deux catégories suivantes (Problèmes ouverts, PRs ouverts) sont en fait, une image fidèle du ratio de validation des contributions} _ : NightwatchJS est principalement géré par Andrei Rus et une poignée d’autres, alors que WebdriverIO se démarque en tant que projet mené par le principal contributeur Christian Bromann , et soutenu par une communauté très active et effervescente.

➮ (???? Subjective) Personnellement, j'ai parfois le sentiment que Nightwatch , en tant que cadre d’automatisation Web, a déjà été semi-mis de côté et le principal contributeur s'intéresse davantage à génération reven à partir de tilisateurs , que de résoudre les problèmes actuels. Comprenez-moi bien ... je n'ai rien contre le marketing et la promotion de soi-même _ , mais je préférerais de beaucoup mettre l'accent sur les efforts dans le produit et le respect de mes utilisateurs actifs, FIRST!

❒ Déni de responsabilité!

Les notes suivantes (on a scale of 1-5 ⭐️) Constituent mon évaluation personnelle après avoir beaucoup travaillé avec les deux cadres. Ils ne reflètent rien d'autre que ma propre expérience avec les outils fournis.

❒ Configuration d'un projet:

WebdriverIO ( 5/5 ⭐️ )
NightwatchJS ( 4.0/5 ⭐️ )

Configurer un WDIO, ou Nightwatch, ou n’importe quel framework de test basé sur NodeJS à partir de ce jour est assez simple:

➊ installez le paquet:

npm install --save webdriverio // or npm install --save nightwatch

Installer et lancer un paquet Selenium Server:

npm install --save-dev Selenium-standalone // don't forget to ... cd ./node_modules/.bin ./Selenium-standalone install ./Selenium-standalone start

Créer une structure de dossier de test rapide:

./ ├── /test | ├── /features (test-files go here) | | └── test.js (your first test here) | ├── /pages (page-objects go here) | ├── /assets (everything goes in here) | └── /custom_commands (custom methods go here) └── package.json

Générer le fichier de configuration (wdio.conf.js Ou nightwatch.conf.js):

➮ (???? Force) C’est à ce stade que WebdriverIO a un avantage, car il vient out-of-the-box avec n assistant CLI sur mesure _ pour ne configuration simple et directe} du fichier wdio.conf.js (vous pouvez démarrer l'assistant via le wdio config commander)

Night avec Nightwatch, vous devez copier-coller un fichier nightwatch.conf.js Factice} de la section Mise en route

➮ Ce n’est pas que Nightwatch manque à cet égard, mais j’estime personnellement que cela laisse plus de place à l’interprétation sur certains aspects, tels que les clés de configuration obligatoires, ce qui est nightwatch.json Et en quoi cela diffère-t-il de nightwatch.conf.js, Etc. Il semble juste qu'après avoir lu la documentation de configuration initiale, je parte avec plus de questions que de réponses.

❖ Aide à la configuration de WebdriverIO (assistant CLI):

❒ Rédaction et exécution de notre premier test:

WebdriverIO ( 5/5 ⭐️ )
NightwatchJS ( 4.5/5 ⭐️ )

OK, vous avez enfin fini de configurer votre projet, vous avez toutes vos dépendances logicielles sous contrôle, ce n'est pas le moment d'écrire notre premier test. Votre projet à cette étape actuelle devrait ressembler à ceci:

./ ├── /test | ├── /features | | └── test.js | ├── /pages | ├── /assets | └── /custom_commands ├── wdio.conf.js or nightwatch.conf.js └── package.json

J'aime beaucoup et j'apprécie le fait que Nightwatch et WebdriverIO proposent des exemples de Nice, prêts à l'emploi, sur leur page d'accueil respective. Branchez & jouez!

❖ Exemple NightwatchJS: (teste une recherche Google pour Rembrandt)

module.exports = { 'Demo test Google' : function (client) { client .url('http://www.google.com') .waitForElementVisible('body', 1000) .assert.title('Google') .assert.visible('input[type=text]') .setValue('input[type=text]', 'rembrandt van rijn') .waitForElementVisible('button[name=btnG]', 1000) .click('button[name=btnG]') .pause(1000) .assert.containsText('ol#rso li:first-child', 'Rembrandt - Wikipedia') .end(); } };

❖ Exemple WebdriverIO: (teste une recherche DuckDuckGo pour WebdriverIO)

❯ wdio-v5 Exemple:

describe('DuckDuckGo - Search Test, () => { it('Should test the DuckDuckGo search page', async () => { await browser.url('https://duckduckgo.com/'); await browser.setValue('#search_form_input_homepage', 'WebdriverIO'); await $('#search_button_homepage').click(); // const title = await browser.getTitle(); assert.equal(title, 'WebdriverIO at DuckDuckGo', `Checking the title ...`); }); });

❯ wdio-v4 Exemple:

const webdriverio = require('webdriverio'); const options = { desiredCapabilities: { browserName: 'chrome' } }; const client = webdriverio.remote(options); client .init() .url('https://duckduckgo.com/') .setValue('#search_form_input_homepage', 'WebdriverIO') .click('#search_button_homepage') .getTitle().then(function(title) { console.log('Title is: ' + title); // outputs: "Title is: WebdriverIO (Software) at DuckDuckGo" }) .end();

Cela devient particulièrement pratique lorsque vous souhaitez montrer à quelqu'un le déploiement rapide d'une infrastructure de test, ou enseigner un cours d'automatisation, et qu'il vous manque un exemple concret pour tester le travail à effectuer.

➮ (???? Force) Juste avant de passer votre premier test, WebdriverIO vous donne la décision de le faire. Voulez-vous écrire votre code synchrone ou asynchrone? Ceci offre ne immense flexibilité, dès le départ, vous permettant de choisir la façon dont vous voulez écrire vos tests (en utilisant le drapeau sync).

❗Remarque: C’était une fonction spécifique de wdio-v4! La nouvelle implémentation de WebdriverIO (wdio-v5) Est centrée sur une approche synchrone pour tester l’écriture, tout en exploitant les appels asynchrones sous le capot. Afin de conserver une représentation fidèle de l’ancienne version, je garderai les exemples ci-dessous, bien qu’ils ne soient plus valides pour wdio-v4.

// By default WebdriverIO commands are executed in a synchronous way using // the wdio-sync package. If you still want to run your tests in an async way // e.g. using promises you can set the sync option to false. sync: true,

❖ Exemple sync: true:

describe('DuckDuckGo - Search Test, () => { it('Should test the DuckDuckGo search page', () => { browser.url('https://duckduckgo.com/'); browser.setValue('#search_form_input_homepage', 'WebdriverIO'); browser.click('#search_button_homepage'); const title = browser.getTitle(); console.log('Title is: ' + title); }); });

❖ Exemple sync: false:

describe('DuckDuckGo - Search Test, () => { it('Should test the DuckDuckGo search page', () => { return browser .url('https://duckduckgo.com/') .setValue('#search_form_input_homepage', 'WebdriverIO') .click('#search_button_homepage') .getTitle().then(function(title) { console.log('Title is: ' + title) // outputs: "Title is: WebdriverIO (Software) at DuckDuckGo" }); }); });

❒ Objets de page:

WebdriverIO ( 5/5 ⭐️ )
NightwatchJS ( 5/5 ⭐️ )

De nos jours, il est quasiment impossible d'avoir une discussion sur automatisation Web & ne pas se retrouver dans une discussion animée sur objets de la page , leur utilité, leur implémentation ou la Modèle d'objet de page en général.

Avant d’explorer comment les objets de page peuvent être implémentés dans ces deux frameworks de test NodeJS, j’ai le sentiment que nous devons comprendre POURQUOI? nous les utilisons.

POURQUOI (pourquoi utilisons-nous des objets de page?)

Il y a un dicton, ne réinventez pas la roue, donc je ne le ferai pas. Au lieu de cela, je citerai (ThoughtWork's Martin Fawler qui IMHO l'a dit le mieux:

"Lorsque vous écrivez des tests sur une page Web, vous devez faire référence à des éléments de cette page Web afin de cliquer sur des liens et de déterminer ce qui est affiché. Toutefois, si vous écrivez des tests manipulant directement les éléments HTML, vos tests seront fragiles Un objet de page encapsule une page HTML, ou un fragment, avec une API spécifique à l’application, vous permettant de manipuler les éléments de la page sans fouiller dans le code HTML. " _

QUOI? (que nous fournissent les objets de page?)

ils créent une séparation des préoccupations: test vs page

ils créent une abstraction de haut niveau de l'application

ils (devraient) contiennent toutes les informations statiques sur la page

ils offrent la possibilité de repenser l'application sans changer les tests

ils peuvent représenter n'importe quel élément (objet) de la page, ou la page entière elle-même

COMMENT? (comment crée-t-on de tels objets de page?)

Assez blabber! Voyons comment nous pouvons facilement implémenter des objets de page dans notre framework de test.

Exemple d'objet de page WebdriverIO:

❖ page.js (C'est votre base d'objet de page})

export default class Page { open (path) { browser.url(path); // !Note: if you want to make sure your page was completely // loaded, then maybe add some logic to wait for // document.readyState = "complete", or "interactive" // Use a /custom_command for this! Go D.R.Y. principle! RAWWWWR! } }

❖ form.page.js (Exemple d'exemple d'objet page de formulaire de connexion):

import Page from './page' class FormPage extends Page { // // > define your elements here < // get username () { return $('#username') } get password () { return $('#password') } get submitButton () { return $('#login button[type=submit]') } get flash () { return $('#flash') } // // > define or overwrite page methods here < // open () { super.open('login') } submit () { this.submitButton.click() } } export default new FormPage()

Exemple d'objet de page NightwatchJS:

❖ homepage.js (Ceci est un exemple d'objet de page d'accueil):

const homepageCustomCommands = { checkHomePage: function() { this.api.perform((done) => { // // > do some homepage checks here < // }); return this; } }; const homepage = { url() { return `${this.api.globals.baseUrl}/homepage`; }, elements: { 'generic': '#generic', 'elements': '#elements', 'gohere': '#gohere', sections: { header: { selector: '#header', elements: { 'these': '#these', 'are': '#are', 'your': '#your', 'selectors': '#selectors' }, }, footer: { selector: '#footer', elements: { // > footer selectors go here < }, }, }, } commands: [homepageCustomCommands] }; module.exports = homepage;

❒ Documentation et support:

WebdriverIO ( 5/5 ⭐️ )
NightwatchJS ( 3/5 ⭐️ )

Tant NightwatchJS que WebdriverIO ont un support important en matière de documentation:

❯ WebdriverIO: Mise en route | API DOCs | Gitter Chat

❯ NightwatchJS: Mise en route | API DOC

➮ (???? Force) les deux projets ont une documentation très propre et informative pour aller avec de grands exemples

➮ (???? Opportunity) remarque: je me trouvais parfois à la recherche de solutions à un ou plusieurs problèmes de fonctionnalité de Nightwatch, ou à des limitations de la structure, niquement pour trouver la solution sur certains Gist ou backblog de back-allley}. Je serais gentil si de telles réponses et contributions (comme les présentations de fonctionnalités laissées ouvertes) seraient centralisées et documentées

➮ (???? Weakness) Je ne sais pas avec certitude où se situe le goulet d'étranglement en ce qui concerne le cycle de développement lent de Nightwatch & terne (au mieux) prise en charge des bogues communautaires, des demandes de fonctionnalités ou même des relations publiques soumises. À mes yeux, cela apparaît encore plus comme un défaut qui contraste avec la dynamique communauté de développement autour de WDIO ou avec le très utile Gitter canal de discussion

❒ À suivre ...

❒ Rapport

❒ Intégration du système CI/CD

❒ Différences architecturales