paint-brush
Test des fonctionnalités natives dans les applications Flutter avec Patrol et Codemagicpar@codemagic
802 lectures
802 lectures

Test des fonctionnalités natives dans les applications Flutter avec Patrol et Codemagic

par Codemagic CI/CD9m2023/11/06
Read on Terminal Reader

Trop long; Pour lire

Patrol est un nouvel outil de test de LeanCode qui vous permet de tester les fonctionnalités natives de la plate-forme dans les applications Flutter. Vous pouvez désormais interagir avec les flux d'authentification Google et Apple, les vues Web, basculer entre les modes clair et sombre, etc. Dans cet article, vous apprendrez également comment utiliser Patrol dans vos flux de travail Codemagic CI/CD.
featured image - Test des fonctionnalités natives dans les applications Flutter avec Patrol et Codemagic
Codemagic CI/CD HackerNoon profile picture
0-item
1-item

"Ça ne sert à rien ! Je n'arrive pas à faire un test de bout en bout avec les tests d'intégration de Flutter", s'exclamait un de nos clients il y a environ 9 mois. J'ai demandé quel était le problème et ils ont expliqué qu'ils utilisaient l'authentification Google pour se connecter et utilisaient le package google_sign_in , mais qu'il n'était pas possible d'utiliser les tests d'intégration de Flutter pour interagir avec les écrans de connexion. Je n'ai toujours pas bien compris quel était le problème, puis ça a cliqué : ce plugin utilise des composants d'interface utilisateur natifs avec lesquels les tests d'intégration ne fonctionnent pas.


J'ai été assez déçu de ne pas pouvoir proposer de solution à ce moment-là et j'ai dû en rester là. Cependant, revenons rapidement à aujourd'hui et une nouvelle solution géniale s'est présentée, appelée "Patrol" par Code Lean . Je vais tout vous dire, mais avant de plonger dans le vif du sujet, récapitulons simplement pourquoi il est important d'exécuter des tests, de quels outils vous disposiez jusqu'à présent, puis parlons de la façon de démarrer avec Patrol.

Pourquoi tester les applications Flutter de toute façon ?

L'une des principales raisons pour lesquelles les équipes de développement utilisent des services d'intégration continue (CI) tels que Codemagie est d'obtenir un retour immédiat sur le code qu'ils s'engagent dans leur dépôt. Les tests peuvent être exécutés automatiquement dans le cadre de votre pipeline pour garantir un niveau de qualité et de stabilité, car les bugs ou les problèmes peuvent être détectés tôt et corrigés immédiatement. Nous encourageons toujours nos clients à mettre en œuvre des tests lors de la configuration de leurs flux de travail, mais il n'est pas rare d'entendre « Nous n'avons pas le temps d'écrire des tests ». J'espère que vous n'êtes pas dans ce bateau et que vous utilisez les tests dans le cadre de votre cycle de développement d'applications pour fournir des applications de grande qualité et sans bug !

Quels sont les principaux moyens automatisés de tester les applications Flutter ?

Il existe quatre méthodes de test principales qui peuvent être automatisées dans le cadre de votre flux de travail CI. Les tests sont un sujet en soi, je serai donc bref, mais l'utilisation d'une combinaison de ces méthodes de test vous aidera à améliorer la qualité de votre application et à détecter les problèmes le plus tôt possible.


Premièrement, il existe les « tests unitaires » qui sont couramment utilisés pour tester vos fonctions et méthodes de manière isolée afin de vous assurer qu'elles fonctionnent comme prévu. Des tests unitaires peuvent également être écrits pour garantir que votre logique métier fonctionne dans différents scénarios sans résultats inattendus.


Ensuite, nous avons les « tests de widgets » Flutter qui vous permettent de tester vos composants d'interface utilisateur et de vous assurer qu'ils s'affichent correctement et fonctionnent comme prévu.


Ensuite, il y a les « tests d'intégration » qui vous permettent de tester si les unités et les composants de votre application fonctionnent ensemble comme prévu.


Enfin, il existe des « tests d'interface utilisateur de bout en bout » où vous testez l'application comme si elle était utilisée par un utilisateur réel. Dans un flux de travail CI, cela est généralement automatisé à l'aide de simulateurs ou d'émulateurs pour tester différents chemins à travers votre application afin de vous assurer qu'il n'y a aucun problème après avoir apporté des modifications à votre code.


C'est là que le client dont je parlais au début était bloqué car il ne pouvait pas exécuter ses tests d'interface utilisateur de bout en bout car il n'était pas possible de se connecter à l'application. À l'époque, ils ont testé une version « dev » qui contournait la partie connexion.


Cependant, ce n'est plus nécessaire maintenant que « Patrol » est disponible !

Entrez, scène à gauche, Patrouille !

Alors tout d’abord, qu’est-ce que Patrol ? Eh bien, je pense que la documentation le dit mieux :


Patrol est un nouveau framework de test d'interface utilisateur open source pour Flutter développé par LeanCode. Il s'appuie sur les outils de test existants de Flutter pour vous permettre de faire des choses qui étaient auparavant impossibles. Patrol vous permet d'accéder aux fonctionnalités natives de la plate-forme sur laquelle l'application Flutter s'exécute.


La partie la plus importante ici est qu'elle vous permet d'accéder aux fonctionnalités natives de la plate-forme sur laquelle votre application Flutter s'exécute.


Cela signifie que vous pouvez désormais faire des choses telles que :


  1. Interagissez avec les boîtes de dialogue de demande d'autorisation pour rejeter ou accepter les demandes.
  2. Interagissez avec les WebViews.
  3. Réduisez et maximisez votre application.
  4. Interagissez avec les flux d'authentification comme l'authentification Google ou Apple.
  5. Interagissez avec d'autres fonctionnalités natives telles que l'ouverture de la barre de notifications, l'appui sur le bouton Accueil, l'activation ou la désactivation de la connectivité Wi-Fi ou le passage de l'appareil en mode sombre, etc.


D'accord, cela semble génial, mais quel est le problème ?


Eh bien, il n'y en a pas ! Et en plus, c'est non seulement gratuit mais aussi Open source !


De plus, Patrol introduit également des « chercheurs personnalisés » qui vous offrent une syntaxe plus concise pour rédiger vos tests. Vous pouvez en savoir plus à leur sujet ici .

Installation et configuration de Patrol

Pour démarrer avec Patrol, vous devrez installer la CLI, ajouter la dépendance Patrol à votre pubspec.yaml et configurer certaines configurations dans vos projets iOS et Android.


LeanCode a créé une excellente documentation ici qui vous guide à travers le processus pour chaque plateforme que vous pouvez trouver ici. Leur guide étape par étape vous guidera tout au long de la configuration pour iOS et Android .


Si vous rencontrez des problèmes, le meilleur endroit pour obtenir de l'aide est le serveur Patrol Community Discord que vous pouvez rejoindre. ici .


Si vous trouvez des bugs, vous pouvez soulever un problème ici .

Installation et configuration de Patrol

Pour démarrer avec Patrol, vous devrez installer la CLI, ajouter la dépendance Patrol à votre pubspec.yaml et configurer certaines configurations dans vos projets iOS et Android.


LeanCode a créé une excellente documentation ici qui vous guide à travers le processus pour chaque plateforme que vous pouvez trouver ici. Leur guide étape par étape vous guidera tout au long de la configuration pour iOS et Android .


Si vous rencontrez des problèmes, le meilleur endroit pour obtenir de l'aide est le serveur Patrol Community Discord que vous pouvez rejoindre. ici .


Si vous trouvez des bugs, vous pouvez soulever un problème ici .

Écrire des tests de fonctionnalités natifs avec Patrol

Maintenant que vous êtes prêt, commençons à tester quelques fonctionnalités natives. Pour l'essayer moi-même, j'ai configuré une simple application Flutter avec un bouton élevé qui, lorsque vous cliquez dessus, ouvre une boîte de dialogue d'alerte native .


Cliquer sur "OK" ou "Annuler" ferme simplement la boîte de dialogue.


Testez l'application avec des fonctionnalités natives


Encore une fois, je recommanderais d'utiliser la propre documentation de Patrol que vous pouvez trouver ici pour ajouter votre premier fichier de test.


Donc, pour mon test, j'ai voulu cliquer sur le bouton surélevé qui contient le texte "Cliquez sur moi !". Il s'agit d'un widget Flutter standard, il peut donc être exploité à l'aide du outil de recherche Patrol suivant :


 await $('Click me!').tap();


La boîte de dialogue native devrait alors être affichée, nous pouvons donc maintenant commencer à interagir avec un composant d'interface utilisateur natif. Ajoutons donc le finder natif qui nous permettra d'appuyer sur le bouton "OK":


 await $('Click me!').tap(); await $.native.tap(Selector(text: 'OK'));


C'était facile! Je souhaite également tester le bouton « Annuler », alors tapons sur le bouton « Cliquez-moi ! » à nouveau, puis appuyez sur le bouton "Annuler" de la boîte de dialogue native en ajoutant quelques lignes supplémentaires comme suit :


 await $('Click me!').tap(); await $.native.tap(Selector(text: 'OK')); await $('Click me!').tap(); await $.native.tap(Selector(text: 'Cancel'));


Votre fichier de test terminé devrait ressembler à ceci :


 import 'package:cmpatrol/main.dart'; import 'package:patrol/patrol.dart'; void main() { patrolTest( 'Native tests', nativeAutomation: true, ($) async { await $.pumpWidgetAndSettle(const MyApp()); await $('Click me!').tap(); await $.native.tap(Selector(text: 'OK')); await $('Click me!').tap(); await $.native.tap(Selector(text: 'Cancel')); await $('Click me!').tap(); await $.native.tap(Selector(text: 'NO')); }, ); }


Vous devriez maintenant pouvoir exécuter ce test sur votre émulateur ou sur un appareil réel en utilisant la commande pour lancer le test. Mon fichier de test d'intégration s'appelait "button_test" j'ai donc démarré les tests depuis Terminal comme suit :


 patrol test -t integration_test/button_test.dart


Vous verrez si vos tests réussissent ou échouent directement dans le terminal. Si les tests échouent, vous recevrez un lien vers le rapport de test complet. Alternativement, si vous exécutez vos tests sur Android comme je l'ai fait, vous pouvez accéder au rapport en cliquant sur index.html dans le répertoire suivant :


 ./build/app/reports/androidTest/connected 


Index Gradle.html


Vous pouvez expérimenter davantage avec d'autres fonctionnalités natives telles que l'ouverture de la barre de notifications, la désactivation du wifi, l'activation du mode sombre, la réduction et l'agrandissement de l'application :


 // minimize app await $.native.pressHome(); await $.native.openNotifications(); await $.native.disableWifi(); await $.native.enableDarkMode(); // maximize app await $.native.openApp();


⚠️ Notez qu'il n'est pas possible de fermer complètement votre application puis de la rouvrir car cela mettrait fin à l'ensemble du test et, par conséquent, le ferait échouer.


Consultez la Patrouille Documentation pour plus d'exemples.

Utiliser Patrol dans vos flux de travail Codemagic

Pour intégrer Patrol dans vos flux de travail, vous devrez d'abord installer la CLI Patrol sur la machine de build. Cela ne prend que quelques secondes et une fois cela fait, vous pouvez exécuter votre script de test. Vous trouverez ci-dessous un exemple de la façon dont vous ajouteriez ces étapes à la section « scripts » de votre fichier de configuration codemagic.yaml . Je recommanderais d'exécuter le script pour installer la CLI Patrol comme l'une des premières étapes de script, puis vous pourrez exécuter vos tests Patrol soit immédiatement après, soit après tout autre test que vous souhaiterez peut-être également exécuter au préalable.


Avant d'exécuter vos tests Patrol, vous devrez démarrer l'émulateur. Nous ajouterons donc un script pour lancer l'émulateur et attendrons qu'il soit complètement démarré. Notez que les émulateurs Android ne sont pas disponibles sur les machines utilisant des machines Apple Silicon M1 ou M2 car Apple Virtualization Framework ne prend pas en charge la virtualisation imbriquée. Par conséquent, je recommanderais d’utiliser une instance Linux lors du test des applications Android.


La section scripts de votre codemagic.yaml devrait ressembler à ceci :


 scripts: ... - name: Install Patrol CLI script: dart pub global activate patrol_cli - name: Launch Android emulator script: | cd $ANDROID_HOME/tools emulator -avd emulator & adb wait-for-device - name: Run tests with Patrol script: patrol test -t integration_test/your_test.dart ignore_failure: true ...


Affichage des résultats des tests Patrol dans les journaux de build Codemagic

Les résultats des tests Patrol sont également disponibles au format JUnit XML , ce qui signifie qu'ils peuvent être affichés dans les journaux de build sur l'écran de présentation de la build Codemagic. Il vous suffit d'ajouter la propriété test_report pass dans le chemin d'accès au fichier XML JUnit généré. Vous pouvez utiliser la propriété ignore_failure avec un booléen pour contrôler si vous souhaitez que le reste du flux de travail continue de s'exécuter ou non. Si vous souhaitez télécharger vos résultats sur un système de gestion de tests comme décrit dans la section suivante, vous devez définir cette valeur sur true .


Voici un exemple de ce à quoi devrait ressembler votre script :


 scripts: ... - name: Run tests with Patrol script: | patrol test -t integration_test/your_test.dart test_report: build/app/outputs/androidTest-results/connected/*.xml ignore_failure: true ...


Un test qui échoue peut ressembler à ceci :


Échec du résultat du test XML JUnit dans le journal de construction Codemagic

Rassembler le rapport de test Patrol en tant qu'artefact de construction

Une chose supplémentaire que vous souhaiterez peut-être faire est de rassembler la sortie du rapport de test en tant qu'artefact de construction afin que vous puissiez afficher le rapport complet en cas d'erreur. Cela rendra le rapport disponible au téléchargement sous forme de fichier zip sur l'écran de présentation de la construction dans la section « Artefacts » sur le côté gauche. Le moyen le plus simple de procéder consiste à copier le répertoire dans lequel se trouvent les fichiers de rapport dans le répertoire utilisé par Codemagic pour exporter les artefacts. Il existe une variable d'environnement intégrée appelée $CM_EXPORT_DIR qui fait référence à ce répertoire que vous pouvez utiliser dans votre script.


Le script pour faire cela devrait ressembler à ceci :


 scripts: ... - name: Export Patrol test report script: | cp -r build/app/reports/androidTests/connected $CM_EXPORT_DIR/report ...


Conclusion

Patrol a enfin surmonté le problème de l'exécution de tests d'interface utilisateur et d'intégration impliquant des fonctionnalités natives. Il est désormais possible de tester les fonctionnalités natives et d'interagir avec les flux d'authentification, les boîtes de dialogue natives et même de basculer entre les fonctionnalités natives telles que le wifi, le cellulaire, le mode sombre, et même de minimiser et de maximiser votre application. De plus, il est à la fois gratuit et open source et apporte une solution à un problème réel qui existe depuis le lancement de Flutter. De plus, il est simple de l'ajouter et de l'utiliser dans vos flux de travail Codemagic. Si vous souhaitez soutenir l'excellent travail réalisé par LeanCode, donnez un like à Patrol sur pub.dev ici et donnez une étoile au dépôt Patrol GitHub ici .




Cet article est rédigé par Kevin Suhajda, responsable de l'ingénierie des solutions chez Codemagie . Vous pouvez retrouver Kevin sur X , GitHub , et LinkedIn .


Également publié ici .