Introduction aux commandes mobiles personnalisées et améliorées dans WebdriverIO
Tester des applications mobiles et des applications web mobiles présente ses propres défis, en particulier lorsqu'il s'agit de gérer les différences spécifiques aux plateformes entre Android et iOS. Bien qu'Appium offre la flexibilité nécessaire pour gérer ces différences, il vous oblige souvent à plonger profondément dans une documentation complexe et dépendante de la plateforme (Android, iOS) et des commandes. Cela peut rendre l'écriture de scripts de test plus chronophage, sujette aux erreurs et difficile à maintenir.
Pour simplifier le processus, WebdriverIO introduit des commandes mobiles personnalisées et améliorées spécialement conçues pour les tests web mobiles et d'applications natives. Ces commandes font abstraction des complexités des API Appium sous-jacentes, vous permettant d'écrire des scripts de test concis, intuitifs et indépendants de la plateforme. En mettant l'accent sur la facilité d'utilisation, nous visons à réduire la charge supplémentaire lors du développement de scripts Appium et à vous permettre d'automatiser les applications mobiles sans effort.
Pourquoi des commandes mobiles personnalisĂ©es ?â
1. Simplification des API complexesâ
Certaines commandes Appium, comme les gestes ou les interactions avec les éléments, impliquent une syntaxe verbeuse et complexe. Par exemple, l'exécution d'une action d'appui long avec l'API native d'Appium nécessite de construire manuellement une chaßne d'action
:
const element = $('~Contacts')
await browser
.action( 'pointer', { parameters: { pointerType: 'touch' } })
.move({ origin: element })
.down()
.pause(1500)
.up()
.perform()
Avec les commandes personnalisĂ©es de WebdriverIO, la mĂȘme action peut ĂȘtre effectuĂ©e avec une seule ligne de code expressive :
await $('~Contacts').longPress();
Cela réduit considérablement le code standard, rendant vos scripts plus propres et plus faciles à comprendre.
2. Abstraction multiplateformeâ
Les applications mobiles nécessitent souvent une gestion spécifique à la plateforme. Par exemple, le défilement dans les applications natives diffÚre considérablement entre Android et iOS. WebdriverIO comble cette lacune en fournissant des commandes unifiées comme scrollIntoView()
qui fonctionnent parfaitement sur toutes les plateformes, quelle que soit l'implémentation sous-jacente.
await $('~element').scrollIntoView();
Cette abstraction garantit que vos tests sont portables et ne nécessitent pas de branchement constant ou de logique conditionnelle pour tenir compte des différences entre systÚmes d'exploitation.
3. ProductivitĂ© accrueâ
En réduisant la nécessité de comprendre et d'implémenter des commandes Appium de bas niveau, les commandes mobiles de WebdriverIO vous permettent de vous concentrer sur le test des fonctionnalités de votre application plutÎt que de lutter avec les nuances spécifiques à la plateforme. Cela est particuliÚrement bénéfique pour les équipes ayant une expérience limitée en automatisation mobile ou celles qui cherchent à accélérer leur cycle de développement.
4. CohĂ©rence et maintenabilitĂ©â
Les commandes personnalisées apportent de l'uniformité à vos scripts de test. Au lieu d'avoir des implémentations variables pour des actions similaires, votre équipe peut s'appuyer sur des commandes standardisées et réutilisables. Cela rend non seulement la base de code plus maintenable, mais abaisse également la barriÚre pour l'intégration de nouveaux membres dans l'équipe.
Pourquoi amĂ©liorer certaines commandes mobiles ?â
1. Ajouter de la flexibilitĂ©â
Certaines commandes mobiles sont améliorées pour fournir des options et des paramÚtres supplémentaires qui ne sont pas disponibles dans les API Appium par défaut. Par exemple, WebdriverIO ajoute une logique de réessai, des délais d'attente et la possibilité de filtrer les webviews selon des critÚres spécifiques, permettant un meilleur contrÎle sur des scénarios complexes.
// Exemple : Personnalisation des intervalles de réessai et des délais d'attente pour la détection de webview
await driver.getContexts({
returnDetailedContexts: true,
androidWebviewConnectionRetryTime: 1000, // Réessayer toutes les 1 seconde
androidWebviewConnectTimeout: 10000, // Délai d'attente aprÚs 10 secondes
});
Ces options aident à adapter les scripts d'automatisation au comportement dynamique de l'application sans code standard supplémentaire.
2. AmĂ©liorer la convivialitĂ©â
Les commandes améliorées font abstraction des complexités et des modÚles répétitifs trouvés dans les API natives. Elles vous permettent d'effectuer plus d'actions avec moins de lignes de code, réduisant la courbe d'apprentissage pour les nouveaux utilisateurs et rendant les scripts plus faciles à lire et à maintenir.
// Exemple : Commande améliorée pour changer de contexte par titre
await driver.switchContext({
title: 'My Webview Title',
});
Par rapport aux méthodes Appium par défaut, les commandes améliorées éliminent la nécessité d'étapes supplémentaires comme la récupération manuelle des contextes disponibles et le filtrage à travers eux.
3. Standardiser le comportementâ
WebdriverIO garantit que les commandes améliorées se comportent de maniÚre cohérente sur les plateformes comme Android et iOS. Cette abstraction multiplateforme minimise le besoin de logique de branchement conditionnel basée sur le systÚme d'exploitation, conduisant à des scripts de test plus maintenables.
// Exemple : Commande de défilement unifiée pour les deux plateformes
await $('~element').scrollIntoView();
Cette standardisation simplifie les bases de code, en particulier pour les équipes qui automatisent les tests sur plusieurs plateformes.
4. Augmenter la fiabilitĂ©â
En incorporant des mécanismes de réessai, des valeurs par défaut intelligentes et des messages d'erreur détaillés, les commandes améliorées réduisent la probabilité de tests instables. Ces améliorations garantissent que vos tests sont résistants aux problÚmes tels que les retards dans l'initialisation de la webview ou les états transitoires de l'application.
// Exemple : Changement de webview amélioré avec une logique de correspondance robuste
await driver.switchContext({
url: /.*my-app\/dashboard/,
androidWebviewConnectionRetryTime: 500,
androidWebviewConnectTimeout: 7000,
});
Cela rend l'exécution des tests plus prévisible et moins sujette aux échecs causés par des facteurs environnementaux.
5. AmĂ©liorer les capacitĂ©s de dĂ©bogageâ
Les commandes améliorées renvoient souvent des métadonnées plus riches, permettant un débogage plus facile des scénarios complexes, en particulier dans les applications hybrides. Par exemple, les commandes comme getContext et getContexts peuvent renvoyer des informations détaillées sur les webviews, y compris le titre, l'URL et le statut de visibilité.
// Exemple : Récupération de métadonnées détaillées pour le débogage
const contexts = await driver.getContexts({ returnDetailedContexts: true });
console.log(contexts);
Ces métadonnées aident à identifier et à résoudre les problÚmes plus rapidement, améliorant l'expérience globale de débogage.
En améliorant les commandes mobiles, WebdriverIO non seulement facilite l'automatisation mais s'aligne également sur sa mission de fournir aux développeurs des outils puissants, fiables et intuitifs à utiliser.
Applications hybridesâ
Les applications hybrides combinent du contenu web avec des fonctionnalités natives et nécessitent une gestion spécialisée pendant l'automatisation. Ces applications utilisent des webviews pour afficher du contenu web au sein d'une application native. WebdriverIO fournit des méthodes améliorées pour travailler efficacement avec les applications hybrides.
Comprendre les webviewsâ
Une webview est un composant similaire à un navigateur intégré dans une application native :
- Android : Les webviews sont basées sur Chrome/System Webview et peuvent contenir plusieurs pages (similaires aux onglets du navigateur). Ces webviews nécessitent ChromeDriver pour automatiser les interactions. Appium peut automatiquement déterminer la version de ChromeDriver requise en fonction de la version de System WebView ou Chrome installée sur l'appareil et la télécharger automatiquement si elle n'est pas déjà disponible. Cette approche assure une compatibilité transparente et minimise la configuration manuelle. Consultez la documentation Appium UIAutomator2 pour savoir comment Appium télécharge automatiquement la version correcte de ChromeDriver.
- iOS : Les webviews sont alimentées par Safari (WebKit) et identifiées par des identifiants génériques comme
WEBVIEW_{id}
.
DĂ©fis avec les applications hybridesâ
- Identifier la bonne webview parmi plusieurs options.
- Récupérer des métadonnées supplémentaires telles que le titre, l'URL ou le nom du package pour un meilleur contexte.
- Gérer les différences spécifiques à la plateforme entre Android et iOS.
- Passer de maniĂšre fiable au contexte correct dans une application hybride.
Commandes clĂ©s pour les applications hybridesâ
1. getContext
â
RécupÚre le contexte actuel de la session. Par défaut, il se comporte comme la méthode getContext d'Appium mais peut fournir des informations de contexte détaillées lorsque returnDetailedContext
est activé. Pour plus d'informations, voir getContext
2. getContexts
â
Renvoie une liste détaillée des contextes disponibles, améliorant la méthode contexts d'Appium. Cela facilite l'identification de la bonne webview pour l'interaction sans avoir à appeler des commandes supplémentaires pour déterminer le titre, l'url ou le bundleId|packageName
actif. Pour plus d'informations, voir getContexts
3. switchContext
â
Bascule vers une webview spécifique en fonction du nom, du titre ou de l'url. Offre une flexibilité supplémentaire, comme l'utilisation d'expressions réguliÚres pour la correspondance. Pour plus d'informations, voir switchContext
FonctionnalitĂ©s clĂ©s pour les applications hybridesâ
- Métadonnées détaillées : Récupérez des détails complets pour le débogage et le changement de contexte fiable.
- Cohérence multiplateforme : Comportement unifié pour Android et iOS, gérant les particularités spécifiques à la plateforme de maniÚre transparente.
- Logique de réessai personnalisée (Android) : Ajustez les intervalles de réessai et les délais d'attente pour la détection de webview.
- Android fournit des métadonnées supplémentaires, telles que
packageName
etwebviewPageId
, tandis qu'iOS se concentre surbundleId
. - La logique de réessai est personnalisable pour Android mais non applicable à iOS.
- Il existe plusieurs cas oĂč iOS ne peut pas trouver la Webview. Appium fournit diffĂ©rentes capacitĂ©s supplĂ©mentaires pour le
appium-xcuitest-driver
pour trouver la Webview. Si vous pensez que la Webview n'est pas trouvée, vous pouvez essayer de définir l'une des capacités suivantes :appium:includeSafariInWebviews
: Ajoute les contextes web Safari à la liste des contextes disponibles pendant un test d'application native/webview. Ceci est utile si le test ouvre Safari et doit pouvoir interagir avec lui. La valeur par défaut estfalse
.appium:webviewConnectRetries
: Le nombre maximum de tentatives avant d'abandonner la détection des pages de webview. Le délai entre chaque tentative est de 500 ms, la valeur par défaut est de10
tentatives.appium:webviewConnectTimeout
: Le temps maximum en millisecondes à attendre pour qu'une page de webview soit détectée. La valeur par défaut est de5000
ms.
Pour des exemples avancés et des détails, consultez la documentation de l'API Mobile WebdriverIO.
Notre ensemble croissant de commandes reflĂšte notre engagement Ă rendre l'automatisation mobile accessible et Ă©lĂ©gante. Que vous effectuiez des gestes complexes ou que vous travailliez avec des Ă©lĂ©ments d'application native, ces commandes s'alignent sur la philosophie de WebdriverIO de crĂ©er une expĂ©rience d'automatisation fluide. Et nous ne nous arrĂȘtons pas lĂ â s'il y a une fonctionnalitĂ© que vous aimeriez voir, nous accueillons vos commentaires. N'hĂ©sitez pas Ă soumettre vos demandes via ce lien.