🥇Lancement des tests instrumentaux dans Firebase Test Lab. Partie 1 : projet iOS

Je m'appelle Dmitry, je travaille comme testeur dans l'entreprise MEL Science. Récemment, j'ai terminé d'explorer une fonctionnalité relativement récente de Firebase Test Lab — à savoir, le test d'applications iOS à l'aide du framework de test natif XCUITest.

Avant cela, j'avais déjà essayé Firebase Test Lab pour Android et cela m'avait beaucoup plu, donc j'ai décidé d'essayer de mettre en place une infrastructure de test iOS sur les mêmes bases. J'ai dû beaucoup chercher sur Google et tout n'a pas fonctionné du premier coup, c'est pourquoi j'ai décidé d'écrire un article-tutoriel pour ceux qui devront encore le faire.

Donc, si vous avez des tests UI sur un projet iOS, vous pourrez dès aujourd'hui essayer de les exécuter sur de vrais appareils, gracieusement fournis par la Corporation du Bien. Les intéressés, bienvenue sous le teaser.

Dans le récit, j'ai décidé de partir de certaines données de base — un dépôt privé sur GitHub et le système de construction CircleCI. Le nom de l'application est AmazingApp, bundleID — com.company.amazingapp. Je donne ces données tout de suite, afin de réduire la confusion ultérieure.

Si vous avez mis en œuvre certaines solutions différemment dans votre projet, partagez votre expérience dans les commentaires.

1. Les tests eux-mêmes

Créons une nouvelle branche de projet pour les tests UI :

$ git checkout develop
$ git pull
$ git checkout -b “feature\/add-ui-tests”

Ouvrons le projet dans XCode et créons une nouvelle Cible (Target) avec des tests UI [XCode -> Fichier -> Nouveau -> Cible -> Bundle de test iOS], donnons-lui un nom évocateur : AmazingAppUITests.

Nous allons dans la section Phases de Construction de la Cible créée et vérifions la présence des Dépendances de Cible — AmazingApp, dans Sources de Compilation — AmazingAppUITests.swift.

Il est de bonne pratique de séparer différentes options de construction en Schémas distincts. Créons un schéma pour nos tests UI [XCode -> Produit -> Schéma -> Nouveau Schéma] et donnons-lui le même nom : AmazingAppUITests.

La construction du schéma créé doit inclure la Cible de l'application principale — AmazingApp et la Cible de tests UI — AmazingAppUITests — voir la capture d'écran

Ensuite, créons une nouvelle configuration de construction pour les tests UI. Dans XCode, nous cliquons sur le fichier du projet, allons dans la section Info. Cliquons sur “+” et créons une nouvelle configuration, par exemple XCtest. Cela nous sera nécessaire ultérieurement pour éviter des complications lors de la signature des codes.

Dans votre projet, vous avez au moins trois Cibles : l'application principale, les tests unitaires (car ils existent, n'est-ce pas ?) et la Cible de tests UI que nous avons créée.

Accédez à Target AmazingApp, onglet Build Settings, section Code Signing Identity. Pour la configuration XCtest, choisissez iOS Developer. Dans la section Code Signing Style, sélectionnez Manual. Nous n'avons pas encore généré de profil de provisionnement, mais nous y reviendrons un peu plus tard.

Pour Target AmazingAppUITests, faisons la même chose, mais dans le champ Product Bundle Identifier, saisissons com.company.amazingappuitests.

2. Configuration du projet dans le programme Apple Developer

Rendez-vous sur la page du programme Apple Developer, allez dans la section Certificates, Identifiers & Profiles, puis dans le champ App IDs du point Identifiers. Créez un nouvel App ID nommé AmazingAppUITests avec le bundleID com.company.amazingappuitests.

Nous avons maintenant la possibilité de signer nos tests avec un certificat distinct, mais… La procédure de création d'un build pour les tests implique la création de l'application elle-même et des builds du runner de tests. Par conséquent, nous sommes confrontés au problème de la signature de deux bundle ID avec un seul profil de provisionnement. Heureusement, il existe une solution simple et élégante : Wildcard App ID. Répétez la procédure de création d'un nouvel App ID, mais au lieu de Explicit App ID, choisissez Wildcard App ID comme sur la capture d'écran.

À ce stade, le travail avec developer.apple.com est terminé, mais nous ne devons pas fermer la fenêtre du navigateur. Accédez à le site de documentation de Fastlane et lisez sur l'outil Match de A à Z.

Le lecteur attentif aura remarqué que pour utiliser cet outil, nous aurons besoin d'un dépôt privé et d'un compte ayant accès à la fois au programme Apple Developer et à Github. Créons (si ce n'est pas déjà fait) un compte de type InfrastructureAccount@your.company.domain, inventons un mot de passe puissant, inscrivons-le sur developer.apple.com et désignons-le comme administrateur du projet. Ensuite, accordez au compte l'accès au dépôt github de votre entreprise et créez un nouveau dépôt privé portant un nom comme AmazingAppMatch.

3. Configuration de Fastlane et de l'outil match

Ouvrez le terminal, accédez au dossier du projet et initialisez fastlane comme indiqué dans le manuel officiel. Après avoir saisi la commande

$ fastlane init

vous serez invité à sélectionner les configurations d'utilisation disponibles. Choisissez la quatrième option — configuration manuelle du projet.

Un nouveau répertoire fastlane est apparu dans le projet, contenant deux fichiers — Appfile et Fastfile. En quelques mots, dans Appfile, nous stockons des informations de service, et dans Fastfile, nous décrivons des jobs, appelés lanes dans la terminologie Fastlane. Je recommande la lecture de la documentation officielle : un, deux.

Ouvrez Appfile dans votre éditeur de texte préféré et mettez-le sous la forme suivante :

app_identifier "com.company.amazingapp"       # Identifiant du bundle
apple_dev_portal_id "infrastructureaccount@your.company.domain"  # Compte d'infrastructure créé, avec la permission de modifier le projet iOS dans le programme Apple Developer.
team_id "LSDY3IFJAY9" # Votre ID d'équipe sur le portail développeur

Retour à la terminal et, selon le manuel officiel, commençons à configurer match.

$ fastlane match init
$ fastlane match development

Ensuite, saisissons les informations demandées : dépôt, compte, mot de passe, etc.

Important : Lors du premier lancement, l'outil match demandera le mot de passe pour déchiffrer le dépôt. Il est très important de conserver ce mot de passe, car il sera utile lors de la configuration du serveur CI !

Un nouveau fichier — Matchfile — a été créé dans le dossier fastlane. Ouvrons-le dans notre éditeur de texte préféré et modifions-le comme suit :

git_url("https://github.com/YourCompany/AmazingAppMatch") # Dépôt privé créé pour stocker les certificats et profils.
type("development") # Le type par défaut, peut être : appstore, adhoc, enterprise ou development
app_identifier("com.company.amazingapp")
username("infrastructureaccount@your.company.domain") # Votre nom d'utilisateur pour le portail développeur Apple

Nous remplissons de cette manière, si nous souhaitons par la suite utiliser match pour signer les builds à déployer sur Crashlytics et/ou AppStore, c'est-à-dire pour signer l'identifiant de bundle de votre application.

Mais, comme nous nous en souvenons, pour signer le build de test, nous avons créé un identifiant wildcard spécial. Donc, ouvrons Fastfile et ajoutons un nouveau lane :

lane :testing_build_for_firebase do

    match(
      type: "development",
      readonly: true,
      app_identifier: "com.company.*",
      git_branch: "uitests"  # Créons une branche séparée pour le certificat development pour signer le build de test.
    )

end

Enregistrer, entrer dans le terminal

fastlane testing_build_for_firebase

et nous voyons comment fastlane a créé un nouveau certificat et l'a placé dans le dépôt. Super !

Ouvrons XCode. Maintenant, nous avons le profil de provisioning dont nous avons besoin, de type Match Development com.company.*, qui doit être spécifié dans la section Profil de provisioning pour les cibles AmazingApp et AmazingAppUITests.

Il nous reste à ajouter un lane pour la construction des tests. Allons dans dépôt projet du plugin pour fastlane, facilitant la configuration de l'exportation vers Firebase Test Lab et suivons les instructions.

Copions-collons à partir de l'exemple source, afin que notre lane 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',      # Schéma de test UI
      clean: true,                        # Recommandé : Cela garantirait que la build n'inclut pas de fichiers inutiles
      skip_detect_devices: true,          # Requis
      build_for_testing: true,            # Requis
      sdk: 'iphoneos',                    # Requis
      should_zip_build_products: true,     # Doit être vrai pour définir le format correct pour Firebase Test Lab
    )

    firebase_test_lab_ios_xctest(
      gcp_project: 'AmazingAppUITests', # Nom de votre projet Google Cloud (nous reviendrons à cette ligne plus tard)
      devices: [                          # Appareil(s) pour exécuter des tests
        {
          ios_model_id: 'iphonex',        # ID du modèle de l'appareil, voir la commande gcloud ci-dessus
          ios_version_id: '12.0',         # ID de la version iOS, voir la commande gcloud ci-dessus
          locale: 'en_US',                # Optionnel : par défaut à en_US si non défini
          orientation: 'portrait'         # Optionnel : par défaut à portrait si non défini
        }
      ]
    )

  end

Pour obtenir des informations complètes sur la configuration de fastlane dans CircleCI, je recommande la lecture de la documentation officielle. une fois, deux.

N'oublions pas d'ajouter une nouvelle tâche à notre config.yml :

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     # met à jour les dépendances
     - run:
         name: install gcloud-sdk   # il est nécessaire d'installer gcloud sur la machine mac
         command: |
           ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"  /dev/null ; brew install caskroom/cask/brew-cask 2> /dev/null
           brew cask install google-cloud-sdk
     - run:
         name: build app for testing
         command: fastlane testing_build_for_firebase  # lance la lane de construction et l'envoi dans firebase

4. Et notre environnement de test ? Configurons Firebase.

Passons maintenant à ce pour quoi cet article a été écrit.

Peut-être que votre application utilise Firebase sur un plan gratuit, peut-être ne l'utilise-t-elle pas du tout. Il n'y a absolument aucune différence fondamentale, car pour les besoins des tests, nous pouvons créer un projet distinct avec une année d'utilisation gratuite (génial, n'est-ce pas ?)

Connectons-nous à notre compte d'infrastructure (ou tout autre, peu importe), et allons à la page de la console Firebase.Créons un nouveau projet avec le nom AmazingAppUITests.

Important : À l'étape précédente, dans Fastfile, dans la lane firebase_test_lab_ios_xctest, le paramètre gcp_project doit correspondre au nom du projet.

Les paramètres par défaut nous conviennent parfaitement.

Ne fermez pas l'onglet, sous le même compte, inscrivez-vous à Gcloud. C'est une mesure nécessaire, car la communication avec Firebase se fait via l'interface de la console gcloud.

Google offre 300 $ pour une année, ce qui, dans le cadre des tests automatisés, équivaut à une année d'utilisation gratuite du service. Nous saisissons les informations de paiement, attendons la transaction test de 1 $ et recevons 300 $ sur notre compte. Après un an, le projet sera automatiquement transféré sur un plan tarifaire gratuit, donc il n'est pas nécessaire de s'inquiéter d'une éventuelle perte d'argent.

Retournez à l'onglet du projet Firebase et changez pour le plan tarifaire Blaze — maintenant nous avons de quoi payer en cas de dépassement du quota.

Dans l'interface gcloud, sélectionnez notre projet Firebase, allez dans le menu principal « Catalogue » et ajoutez l'API Cloud Testing et l'API Cloud Tools Result.

Ensuite, allez dans le menu « IAM et administration » -> Comptes de service -> Créer un compte de service. Accordez les droits d'édition du projet.

Créez une clé API au format JSON.

Le JSON téléchargé nous sera utile un peu plus tard, pour l'instant, considérons que la configuration de Test Lab est terminée.

5. Configuration de CircleCI

Une question légitime se pose — que faire des mots de passe ? Pour sauvegarder en toute sécurité nos mots de passe et autres données sensibles, nous utiliserons le mécanisme des variables d'environnement de notre machine de build. Dans les paramètres du projet CircleCI, sélectionnez Variables d'environnement.

Et créez les variables suivantes :

key: GOOGLE_APPLICATION_CREDENTIALS
value: contenu du fichier JSON de clé du compte de service gcloud
key: MATCH_PASSWORD
value: mot de passe pour déchiffrer le dépôt github avec les certificats
key: FASTLANE_PASSWORD
value: mot de passe du compte d'infrastructure Apple Developer Portal

Enregistrez les modifications, créez un PR et envoyez-le pour révision à votre team lead.

Résultats

Grâce à ces manipulations simples, nous avons obtenu un bon stand fonctionnant de manière stable avec la possibilité d'enregistrer une vidéo de l'écran de l'appareil lors des tests. Dans l'exemple de test, j'ai indiqué le modèle d'appareil iPhone X, mais la ferme propose un large choix de combinaisons de différents modèles et versions d'iOS.

La deuxième partie sera consacrée à une configuration étape par étape de Firebase Test Lab pour un projet Android.

Source : habr.com

Lancement des tests d'outils dans Firebase Test Lab. Partie 1 : projet iOS