Je m'appelle Dmitry, je travaille comme testeur chez
MEL Science . Plus récemment, j'ai fini par m'occuper d'une fonctionnalité relativement récente du
Firebase Test Lab - Ă savoir, les tests instrumentaux des applications iOS en utilisant le framework de test natif XCUITest.
Avant cela, j'avais déjà essayé le Firebase Test Lab pour Android et j'ai vraiment tout aimé, alors j'ai décidé d'essayer de mettre l'infrastructure de test du projet iOS sur la même piste. J'ai dû beaucoup google et tout n'a pas fonctionné correctement la première fois, j'ai donc décidé d'écrire un tutoriel pour ceux qui doivent encore le faire.
Donc, si vous avez des tests d'interface utilisateur sur un projet iOS, vous pouvez aujourd'hui essayer de les exécuter sur de vrais appareils aimablement fournis par Good Corporation. Intéressé - bienvenue au chat.
Dans l'histoire, j'ai décidé de construire sur certaines données sources - un référentiel privé sur GitHub et le système de construction CircleCI. Le nom de l'application est AmazingApp, bundleID est com.company.amazingapp. Je cite ces données immédiatement, pour réduire la confusion ultérieure.
Si vous avez implémenté différentes solutions dans votre projet différemment - partagez votre expérience dans les commentaires.
1. Les tests eux-mĂŞmes
Créez une nouvelle branche de projet pour les tests d'interface utilisateur:
$ git checkout develop $ git pull $ git checkout -b “feature/add-ui-tests”
Ouvrez le projet dans Xcode et créez une nouvelle cible avec les tests d'interface [XCode -> Fichier -> Nouveau -> Cible -> Bundle de tests iOS], donnez-lui le nom parlant AmazingAppUITests.
Accédez à la section Build Phases de la cible créée et vérifiez la présence de dépendances cibles - AmazingApp, dans Compile Sources - AmazingAppUITests.swift.
Il est recommandé d'isoler les différentes options d'assemblage dans des schémas distincts. Nous créons un schéma pour nos tests d'interface utilisateur [XCode -> Produit -> Schéma -> Nouveau schéma] et nous lui donnons le même nom: AmazingAppUITests.
Construire le schéma créé doit inclure la cible de l'application principale - AmazingApp et tests de l'interface utilisateur cible - AmazingAppUITests - voir capture d'écran
Ensuite, créez une nouvelle configuration de construction pour les tests d'interface utilisateur. Dans Xcode, cliquez sur le fichier projet, allez dans la section Info. Cliquez sur «+» et créez une nouvelle configuration, par exemple XCtest. Nous en aurons besoin à l'avenir afin d'éviter de danser avec un tambourin en matière de signature de code.
Votre projet a au moins trois cibles: l'application principale, les tests unitaires (parce qu'ils le sont, non?) Et les tests d'interface cible que nous avons créés.
Accédez à Target AmazingApp, onglet Paramètres de construction, section Identité de signature de code. Pour configurer XCtest, sélectionnez iOS Developer. Dans la section Style de signature de code, sélectionnez Manuel. Nous n'avons pas encore généré le profil de provisioning, mais un peu plus tard, nous y reviendrons certainement.
Pour Target AmazingAppUITests, nous faisons de mĂŞme, mais dans la colonne Identifiant de l'ensemble de produits, nous saisissons com.company.amazingappuitests.
2. Configuration d'un projet dans le programme pour développeurs Apple
Nous allons à la page du programme pour développeurs Apple, allons à la section Certificats, identificateurs et profils, puis à la colonne ID d'application de l'élément Identificateurs. Créez un nouvel ID d'application nommé AmazingAppUITests et bundleID com.company.amazingappuitests.
Nous avons maintenant la possibilité de signer nos tests avec un certificat séparé, mais ... La procédure de génération pour les tests implique la construction de l'application elle-même et la construction du lanceur de test. Par conséquent, nous sommes confrontés au problème de la signature de deux ID de bundle avec un profil d'approvisionnement. Heureusement, il existe une solution simple et élégante - Wildcard App ID. Nous répétons la procédure pour créer un nouvel ID d'application, mais au lieu de l'ID d'application explicite, sélectionnez l'ID d'application générique comme dans la capture d'écran.
Nous avons fini de travailler avec developer.apple.com Ă ce stade, mais nous ne minimiserons pas la fenĂŞtre du navigateur. Nous allons sur le
site avec de la documentation sur Fastlane et lisons sur l'utilitaire Match de couverture en couverture.
Un lecteur attentif a remarqué que pour utiliser cet utilitaire, nous aurons besoin d'un référentiel privé et d'un compte ayant accès à la fois au programme pour développeurs Apple et à Github. Nous créons (si ce n'est soudainement pas le cas) un compte de la forme InfrastructureAccount@your.company.domain, trouvons un mot de passe puissant, l'enregistrons dans developer.apple.com et le nommons administrateur de projet. Ensuite, donnez à votre compte l'accès au référentiel github de votre entreprise et créez un nouveau référentiel privé avec un nom comme AmazingAppMatch.
3. Configuration de Fastlane et de l'utilitaire de correspondance
Ouvrez le terminal, accédez au dossier du projet et initialisez fastlane comme indiqué dans le
manuel officiel . Après avoir entré la commande
$ fastlane init
Vous serez invité à sélectionner les configurations d'utilisation disponibles. Nous sélectionnons le quatrième élément - configuration manuelle du projet.
Un nouveau répertoire fastlane est apparu dans le projet, dans lequel il y a deux fichiers - Appfile et Fastfile. En bref - dans l'Appfile, nous stockons les données de service et dans Fastfile, nous écrivons des travaux, dans la terminologie Fastlane appelée voies. Je recommande de lire la documentation officielle:
un ,
deux .
Ouvrez l'Appfile dans votre éditeur de texte préféré et amenez-le sous la forme suivante:
app_identifier "com.company.amazingapp"
Nous retournons au terminal et selon le manuel officiel, nous commençons à configurer la correspondance.
$ fastlane match init $ fastlane match development
Ensuite, entrez les données demandées - référentiel, compte, mot de passe, etc.
Important: la première fois que vous démarrez l'utilitaire de correspondance, il vous sera demandé d'entrer un mot de passe pour décrypter le référentiel. Il est très important de conserver ce mot de passe, au stade de la configuration du serveur CI il nous sera utile!
Un nouveau fichier est apparu dans le dossier fastlane - Matchfile. Ouvrez dans votre éditeur de texte préféré et apportez au formulaire:
git_url("https://github.com/YourCompany/AmazingAppMatch")
Nous le remplissons de cette façon si nous voulons utiliser match pour signer des builds à publier dans Crashlytics et / ou AppStore, c'est-à -dire pour signer l'ID de bundle de votre application.
Mais, comme nous nous en souvenons, pour créer une version de test, nous avons créé un ID générique spécial. Par conséquent, ouvrez Fastfile et entrez une nouvelle voie:
lane :testing_build_for_firebase do match( type: "development", readonly: true, app_identifier: "com.company.*", git_branch: "uitests"
Enregistrez, entrez dans le terminal
fastlane testing_build_for_firebase
et voyez comment fastlane a créé un nouveau certificat et l'a placé dans le référentiel. Super!
Ouvrez Xcode. Nous avons maintenant le profil de provisionnement nécessaire de Match Development com.company. * Type, qui doit être spécifié dans la section Profil de provisioning pour les cibles AmazingApp et AmazingAppUITests.
Il reste Ă ajouter une voie pour construire les tests. Nous allons au
référentiel du projet de plugin pour fastlane, ce qui facilite la configuration de l'exportation vers Firebase Test Lab et suit les instructions.
Copiez de l'exemple d'origine pour que notre piste testing_build_for_firebase ressemble finalement Ă ceci:
lane :testing_build_for_firebase do match( type: "development", readonly: true, app_identifier: "com.company.*", git_branch: "uitests" ) scan( scheme: 'AmazingAppUITests',
Pour des informations complètes sur la configuration de fastlane dans CircleCI, je vous recommande de lire la documentation officielle
un, deux .
N'oubliez pas d'ajouter notre config.yml avec une nouvelle tâche:
build-for-firebase-test-lab: macos: xcode: "10.1.0" working_directory: ~/project shell: /bin/bash --login -o pipefail steps: - checkout - attach_workspace: at: ~/project - run: sudo bundle install
4. Mais qu'en est-il de notre banc d'essai? Configurez Firebase.
Nous procédons, en fait, à la raison pour laquelle l'article a été rédigé.
Peut-être que votre application utilise Firebase sur un plan tarifaire gratuit, peut-être qu'elle ne l'utilise pas du tout. Il n'y a absolument aucune différence fondamentale, car pour tester les besoins, nous pouvons créer un projet séparé avec une année d'utilisation gratuite (cool, non?)
Connectez-vous Ă notre compte d'infrastructure (ou tout autre, aucune diffĂ©rence) et accĂ©dez Ă
la page de la console Firebase . Créez un nouveau projet appelé AmazingAppUITests.
Important: À l'étape précédente du Fastfile dans la voie firebase_test_lab_ios_xctest, le paramètre gcp_project doit correspondre au nom du projet.
Les paramètres par défaut sont assez bien avec nous.
Nous ne
fermons pas l'onglet, sous le mĂŞme compte que nous enregistrons dans
Gcloud - c'est une mesure
nécessaire , car la communication avec Firebase se fait à l'aide de l'interface de la console gcloud.
Google donne 300 $ par an, ce qui équivaut dans le cadre de tests automatiques à une année d'utilisation gratuite du service. Nous entrons les données de paiement, attendons les frais de test de 1 $ et obtenons 300 $ sur le compte. Après un an, le projet sera automatiquement transféré vers un plan tarifaire gratuit, vous ne devez donc pas vous inquiéter d'une éventuelle perte d'argent.
Revenons à l'onglet avec le projet Firebase et transférons-le dans le plan tarifaire Blaze - nous avons maintenant quelque chose à payer en cas de dépassement de la limite.
Dans l'interface gcloud, sélectionnez notre projet Firebase, sélectionnez l'élément de menu principal "Catalogue" et ajoutez l'API Cloud Testing et l'API Cloud Tools Result.
Allez ensuite dans le menu "IAM et Administration" -> Comptes de service -> Créer un compte de service. Nous nous réservons le droit de modifier le projet.
Créer une clé API au format JSON
Nous aurons besoin du JSON téléchargé un peu plus tard, mais pour l'instant, nous considérerons que la configuration de Test Lab est terminée.
5. Configurer CircleCI
Une question raisonnable se prépare - que faire des mots de passe? Enregistrer de manière fiable nos mots de passe et autres données sensibles nous aidera au mécanisme des variables d'environnement de notre build-machine. Dans les paramètres du projet CircleCI, sélectionnez Variables d'environnement
Et démarrez les variables suivantes:
- clé: GOOGLE_APPLICATION_CREDENTIALS
valeur: fichier de clé de compte de service gcloud json - clé: MATCH_PASSWORD
valeur: mot de passe pour déchiffrer le référentiel github avec des certificats - clé: FASTLANE_PASSWORD
valeur: mot de passe du compte d'infrastructure du portail des développeurs Apple
Nous enregistrons les modifications, créons un PR et l'envoyons pour révision pour notre chef d'équipe.
Résumé
Grâce à ces manipulations simples, nous avons obtenu un bon support de travail stable avec la possibilité d'enregistrer des vidéos sur l'écran de l'appareil au moment du test. Dans un cas de test, j'ai spécifié un modèle d'appareil iPhone X, mais la batterie de serveurs propose une large sélection de combinaisons de différents modèles et versions d'iOS.
La deuxième partie sera consacrée à la configuration pas à pas du Firebase Test Lab pour un projet Android.