Sign / Sign out Feature @livestorm.co

POC de tests d'acceptation UI avec Capybara et WebdriverIo.

🚀 POC

📋 Objectifs

Résumé	Capybara	Wdio	Remarque(s)
Rédiger des exemples (test d'acceptation) permettant de valider les features Sign in et Sign out @livestorm.co.	✅	✅	cf. Couverture des Tests d'acceptation UI
Exécuter automatiquement les tests avec circleci	✅	✅	cf. CircleCi
Utiliser des containers docker pour l'exécution des tests	✅	✅	cf CircleCi et Serveur Selenium en local
Exécuter les tests en remote avec browserstack	✅	✅	cf. Ruby / Capybara et NodeJS / WebdriverIo
🎁 Générer/Publier le reporting des tests avec allure	✅	✅	cf. Ruby / Capybara et NodeJS / WebdriverIo
🎁 Comparaison/Retour d'expériences Capybara Vs. WebdriverIO pour l'implémentation de tests automatisés de pages web	✅	✅	cf. Tableau comparatif WebdriverIO VS. Capybara

🔍 Couverture des Tests d'acceptation UI

Liste des tests d'acceptation UI (Rspec et Mocha) :

• 🔽 Sign in Failures
  • ✅ should not be signed in with incorrect password
  • ✅ should redirect to login page in case of sign in failure on server side
• 🔽 Sign in Field Errors
  • ✅ each invalid field should return an error
  • ✅ email with invalid format should return an error
  • ✅ empty email should return an error
  • ✅ empty password should return an error
  • ✅ password too short should return an error
• 🔽 Sign in Form Errors
  • ✅ unknown email should return an error
  • ✅ incorrect password should return an error
• 🔽 Sign in Success
  • ✅ should be signed in
  • ✅ should redirect to Webinars page
• 🔽 Sign Out Success
  • ✅ should destroy session
  • ✅ should redirect to sign in page

Notes :

1. Les tests décrivent le comportement du système, c'est à dire ce qu'il fait (et non comment) et chaque test vérifie une seule intension à la fois.
2. C'est à un niveau unitaire qu'il faut être exhaustif sur le domaine/la fonctionnalité. Au niveau e2e, il est recommandé de couvrir les cas les plus importants (happy path) de manière à limiter les coûts, la maintenance et à avoir une boucle de feedback rapide.
3. Dans un contexte projet avec les méthodologies agiles, pour rédiger ces exemples il est souhaitable de collaborer au travers du célèbre "three amigos" avec dev/qa/po pour avoir les exemples avant de démarrer l'implémentation (aka. BDD/ATDD/TDD).
4. Les tests utilisent le design pattern page object model.

Références :

• PageObject
• Creating Fast, Reliable, Focused UI Automation With Atomic Tests
• The world's most misunderstood collaboration tool
• Introducing Example Mapping

🏆 Tableau comparatif WebdriverIO VS. Capybara

Critères	WebdriverIO	Capybara	Commentaires
Mise en place	👍	👎	Plus de code à écrire et de configuration à mettre en place avec capybara (capabilities, test en parallèle, allure, browserstack), cli pour la mise en place avec wdio et gestion de la configuration via fichiers built-in.
Fonctionnalités	👍	👎	Wdio est un framework riche pour l'automatisation de tests e2e avec de nombreux services disponibles (shared store, selenium, browserstack, appium), protocoles (webdriver, appiup, devtools) et nombreux format de supporting géré (allure, junit, cucumber, etc)
Allure (Reporting)	👍	👎	fonctionnalités non supportées avec allure-ruby e.g addArgument, plus de fonctionnalités pour le reporting avec mocha VS. Rspec.
Utilisation webdriver	👎	👍	Pas de gestion d'attente nécessaire avec Capybara, téléchargement automatique des webdrivers avec wdio et Capybara
Framework de tests	👍	👍	Tous deux supportent plusieurs frameworks de tests.
Learning / Documentation / Communauté	👍	👎	Documentation wdio accessible avec nombreux exemples et communauté d'utilisateurs importante. Utilisé dans de nombreux projets open source, e.g appium.
Debug / Analyse statique	👍	👎	Analyse statique du code puissante avec typescript et debug efficace avec la commande wdio browser.debug() permettant d'exécuter du code via un REPL (Read Eval Print Loop).

🎮 Démo

Pré-requis : Après avoir cloné le projet et avant d'exécuter les tests :

1. Dupliquer les fichiers fixtures/users.fixture.default.json et config/browserstack.default.config.yml
2. Les renommer en fixtures/users.fixture.json et config/browserstack.config.yml
3. Configurer vos identifiants :
   • modifier validUser dans users.fixture.json
   • modifier user et key dans browserstack.config.yml

💎 Ruby / Capybara

☕ Exécution des tests

Important: pour le reporting allure, l'installation de java est nécessaire ainsi que le client allure, on utilise le package npm allure-commandline qui n'a pas d'équivalent avec ruby.

# installation
$ npm i -g allure-commandline
# génération du reporting allure et ouverture
$ allure genenate -c allure-results && allure open

Une fois allure installé :

$ cd ruby-capybara
# Installation
$ bundle install
# Exécution des tests en local avec chromedriver
$ rake e2e
# Exécution des tests en remote avec un serveur selenium
# (serveur selenium à démarrer au préalable, cf. Serveur Selenium en local)
$ rake e2e:chrome_remote
# Exécution des tests en parallèle avec browserstack
$ rake e2e:parallel_bs

Note : le rapport allure est généré et ouvert automatiquement lors de l'utilisation d'une tâche rake (pour la Ci il est uniquement généré).

🤖 NodeJS / WebdriverIo

☕ Exécution des tests

$ cd nodejs-wdio
# Installation
$ npm install
# Exéuction des tests en local avec un serveur selenium
# (serveur démarré automatiquement en tant que service par wdio)
$ npm test
# Exéuction des tests en remote avec browserstack
$ npm run e2e:bs
# Génération du reporting et ouverture
$ npm run report

🚚 CircleCi

➡️ Accès CircleCi ⬅️

🚪 Gestion des secrets

La gestion des secrets s'effectue conjointement avec secrethub et les variables d'environnement circleci.

Liste des secrets :

• fixtures/users.fixture.json : contient les users nécessaires à l'authentification. Stocké dans secrethub.
• config/browserstack.config.yml : contient la configuration browserstack (credentials, capabilities) pour Capybara. Stocké dans secrethub.
• var d'env circleci BROWSERSTACK_USERNAME et BROWSERSTACK_ACCESS_KEY accès browser pour WebdriverIO.
• var d'env circleci CIRCLE_TOKEN : token d'accès à l'api (build artefacts)
• var d'env circleci SECRETHUB_CREDENTIAL : token d'accès pour secrethub

🐹 Capybara

1. Exécution des tests avec webdriver dans un container docker :
   • Reporting junit : OK / KO
   • Reporting Allure : OK / KO

🤖 WebdriverIo

1. Exécution d'un serveur selenium dans le container docker :
   • Reporting junit : OK
   • Reporting Allure : OK
2. Exécution avec browserstack
   • Reporting Allure : OK. Note : le tesk KO est lié à l'exécution précédente avec le selenium en local, le report allure permet d'avoir tous les résultats des tests dans un seul report.

🐳 Serveur Selenium en local

Pour lancer un serveur selenium en local nous pouvons aussi utiliser Selenoid :

# Récupération des images docker pour les browsers
$ docker pull selenoid/chrome
$ docker pull selenoid/firefox
# Démarrage de Selenoid
$ docker-compose up -d

Note : Ouvrir http://localhost:8080 une fois démarré pour avoir accès à la UI et voir les tests s'exécuter et utiliser l'adresse http://localhost:4444/wd/hub pour configurer l'adresse du serveur remote.