Aller au contenu principal

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​

  1. Identifier la bonne webview parmi plusieurs options.
  2. Récupérer des métadonnées supplémentaires telles que le titre, l'URL ou le nom du package pour un meilleur contexte.
  3. Gérer les différences spécifiques à la plateforme entre Android et iOS.
  4. 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​

  1. Métadonnées détaillées : Récupérez des détails complets pour le débogage et le changement de contexte fiable.
  2. Cohérence multiplateforme : Comportement unifié pour Android et iOS, gérant les particularités spécifiques à la plateforme de maniÚre transparente.
  3. 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.
Remarques et limitations
  • Android fournit des mĂ©tadonnĂ©es supplĂ©mentaires, telles que packageName et webviewPageId, tandis qu'iOS se concentre sur bundleId.
  • 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 est false.
    • 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 de 10 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 de 5000 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.

Welcome! How can I help?

WebdriverIO AI Copilot