"Ç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
L'une des principales raisons pour lesquelles les équipes de développement utilisent des services d'intégration continue (CI) tels que
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 !
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 :
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
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
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
Si vous rencontrez des problèmes, le meilleur endroit pour obtenir de l'aide est le serveur Patrol Community Discord que vous pouvez rejoindre.
Si vous trouvez des bugs, vous pouvez soulever un problème
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
Si vous rencontrez des problèmes, le meilleur endroit pour obtenir de l'aide est le serveur Patrol Community Discord que vous pouvez rejoindre.
Si vous trouvez des bugs, vous pouvez soulever un problème
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.
Encore une fois, je recommanderais d'utiliser la propre documentation de Patrol que vous pouvez trouver
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
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
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 ...
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 :
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 ...
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
Cet article est rédigé par Kevin Suhajda, responsable de l'ingénierie des solutions chez
Également publié ici .