Je m'appelle Dmitry, je travaille comme testeur dans l'entreprise . Tout récemment, j'ai fini de m'occuper d'une fonctionnalité relativement récente de - à savoir, avec des tests instrumentaux d'applications iOS à l'aide du framework de test natif XCUITest.
Avant cela, j'avais déjà essayé Firebase Test Lab pour Android et j'avais vraiment tout aimé, j'ai donc décidé d'essayer de mettre l'infrastructure de test iOS du projet sur le même pied. J'ai dû beaucoup chercher sur Google et tout n'a pas fonctionné du premier coup, j'ai donc décidé d'écrire un article tutoriel pour ceux qui ont encore des difficultés.
Ainsi, si vous avez des tests d'interface utilisateur sur un projet iOS, vous pouvez déjà essayer de les exécuter sur de vrais appareils dès aujourd'hui, gracieusement fournis par Good Corporation. Pour ceux que cela intéresse, bienvenue au chat.
Dans l'histoire, j'ai décidé de m'appuyer sur certaines données initiales - un référentiel privé sur GitHub et le système de build CircleCI. Le nom de l'application est AmazingApp, le bundleID est com.company.amazingapp. Je présente ces données immédiatement pour réduire toute confusion ultérieure.
Si vous avez implémenté certaines solutions différemment dans votre projet, 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”
Ouvrons le projet dans XCode et créons une nouvelle cible avec des tests d'interface utilisateur [XCode -> Fichier -> Nouveau -> Cible -> iOS Testing Bundle], en lui donnant le nom explicite AmazingAppUITests.
Accédez à la section Build Phases de la cible créée et vérifiez la présence de Target Dependencies - AmazingApp, dans Compile Sources - AmazingAppUITests.swift.
Une bonne pratique consiste à séparer les différentes options de construction en schémas distincts. Nous créons un schéma pour nos tests d'interface utilisateur [XCode -> Produit -> Schéma -> Nouveau schéma] et lui donnons le même nom : AmazingAppUITests.
La construction du schéma créé doit inclure la cible de l'application principale - Tests AmazingApp et Target UI - AmazingAppUITests - voir capture d'écran
Ensuite, nous créons une nouvelle configuration de build pour les tests d'interface utilisateur. Dans XCode, cliquez sur le fichier du projet et accédez à 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.
Il y a au moins trois Targets dans votre projet : l'application principale, les tests unitaires (après tout, ils existent, n'est-ce pas ?) et les tests Target UI que nous avons créés.
Accédez à Target AmazingApp, onglet Paramètres de construction, section Identité de signature de code. Pour la configuration XCtest, sélectionnez Développeur iOS. Dans la section Style de signature de code, sélectionnez Manuel. Nous n'avons pas encore généré de profil d'approvisionnement, mais nous y reviendrons certainement un peu plus tard.
Pour Target AmazingAppUITests, nous faisons la même chose, mais dans la colonne Product Bundle Identifier, nous entrons com.company.amazingappuitests.
2. Mise en place d'un projet dans le programme pour développeurs Apple
Accédez à la page du programme pour développeurs Apple, accédez à la section Certificats, identifiants et profils, puis à la colonne ID d'application de l'élément Identifiants. Créez un nouvel identifiant d'application appelé AmazingAppUITests et bundleID com.company.amazingappuitests.
Nous avons maintenant la possibilité de signer nos tests avec un certificat séparé, mais... La procédure d'assemblage d'une build pour les tests implique l'assemblage de l'application elle-même et l'assemblage du lanceur de tests. En conséquence, nous sommes confrontés au problème de la signature de deux ID de bundle avec un seul profil d'approvisionnement. Heureusement, il existe une solution simple et élégante : Wildcard App ID. Nous répétons la procédure de création d'un nouvel ID d'application, mais au lieu d'ID d'application explicite, sélectionnez ID d'application Wildcard comme dans la capture d'écran.
À ce stade, nous avons fini de travailler avec Developer.apple.com, mais nous ne réduirons pas la fenêtre du navigateur. Allons à et découvrez l'utilitaire Match d'un bout à l'autre.
Un lecteur attentif a remarqué que pour utiliser cet utilitaire, nous aurons besoin d'un référentiel privé et d'un compte avec accès à la fois au programme pour développeurs Apple et à Github. Nous créons (si du coup il n'y a rien de tel) un compte rendu du formulaire [email protected], trouvez un mot de passe fort, enregistrez-le sur Developer.apple.com et nommez-le en tant qu'administrateur de projet. Ensuite, nous donnons au compte l'accès au référentiel github de votre entreprise et créons un nouveau référentiel privé avec un nom comme AmazingAppMatch.
3. Configuration de Fastlane et de l'utilitaire de correspondance
Ouvrez un terminal, accédez au dossier contenant le projet et initialisez Fastlane comme indiqué dans . Après avoir entré la commande
$ fastlane initVous serez invité à sélectionner les configurations d'utilisation disponibles. Sélectionnez la quatrième option : configuration manuelle du projet.
Le projet dispose d'un nouveau répertoire fastlane, qui contient deux fichiers - Appfile et Fastfile. En un mot, nous stockons les données de service dans Appfile et écrivons des tâches dans Fastfile, appelées voies dans la terminologie Fastlane. Je recommande de lire la documentation officielle : , .
Ouvrez l'Appfile dans votre éditeur de texte préféré et amenez-le sous la forme suivante :
app_identifier "com.company.amazingapp" # Bundle ID
apple_dev_portal_id "[email protected]" # Созданный инфраструктурный аккаунт, имеющий право на редактирование iOS проекта в Apple Developer Program.
team_id "LSDY3IFJAY9" # Your Developer Portal Team ID
Nous retournons au terminal et selon le manuel officiel, nous commençons à configurer le match.
$ fastlane match init
$ fastlane match development
Ensuite, entrez les données demandées - référentiel, compte, mot de passe, etc.
Important: Lorsque vous lancez l'utilitaire de correspondance pour la première fois, il vous sera demandé de saisir un mot de passe pour déchiffrer le référentiel. Il est très important de sauvegarder ce mot de passe, nous en aurons besoin lors de la configuration du serveur CI !
Un nouveau fichier est apparu dans le dossier fastlane - Matchfile. Ouvrez-le dans votre éditeur de texte préféré et affichez-le comme ceci :
git_url("https://github.com/YourCompany/AmazingAppMatch") #Созданный приватный репозиторий для хранения сертификатов и профайлов.
type("development") # The default type, can be: appstore, adhoc, enterprise or development
app_identifier("com.company.amazingapp")
username("[email protected]") # Your Infrastructure account Apple Developer Portal username
Nous le remplissons exactement de cette façon si nous souhaitons utiliser match à l'avenir pour signer des builds à afficher dans Crashlytics et/ou AppStore, c'est-à-dire pour signer l'ID de bundle de votre application.
Mais, comme nous nous en souvenons, nous avons créé un ID Wildcard spécial pour signer la version de test. 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" # создаем отдельный бранч для development сертификата для подписи тестовой сборки.
)
end
Enregistrez et entrez dans le terminal
fastlane testing_build_for_firebaseet nous voyons comment fastlane a créé un nouveau certificat et l'a placé dans le référentiel. Super!
Ouvrez XCode. Nous disposons désormais du profil de provisionnement nécessaire sous la forme Match Development com.company.*, qui doit être spécifié dans la section Profil de provisionnement pour les cibles AmazingApp et AmazingAppUITests.
Il reste à ajouter une voie pour assembler les tests. Allons à un projet de plugin pour fastlane qui facilite la configuration de l'exportation vers Firebase Test Lab et suit les instructions.
Copions-collons à partir de l'exemple original pour que notre lane testing_build_for_firebase finisse par ressembler à ceci :
lane :testing_build_for_firebase do
match(
type: "development",
readonly: true,
app_identifier: "com.company.*",
git_branch: "uitests"
)
scan(
scheme: 'AmazingAppUITests', # UI Test scheme
clean: true, # Recommended: This would ensure the build would not include unnecessary files
skip_detect_devices: true, # Required
build_for_testing: true, # Required
sdk: 'iphoneos', # Required
should_zip_build_products: true, # Must be true to set the correct format for Firebase Test Lab
)
firebase_test_lab_ios_xctest(
gcp_project: 'AmazingAppUITests', # Your Google Cloud project name (к этой строчке вернемся позже)
devices: [ # Device(s) to run tests on
{
ios_model_id: 'iphonex', # Device model ID, see gcloud command above
ios_version_id: '12.0', # iOS version ID, see gcloud command above
locale: 'en_US', # Optional: default to en_US if not set
orientation: 'portrait' # Optional: default to portrait if not set
}
]
)
end
Pour des informations complètes sur la configuration de Fastlane dans CircleCI, je vous recommande de lire la documentation officielle .
N'oubliez 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 # обновляем зависимости
- run:
name: install gcloud-sdk # на mac машину необходимо установить gcloud
command: |
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" < /dev/null 2> /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 # запускаем lane сборки и отправки в firebase
4. Qu'en est-il de notre banc d'essai ? Configuration de Firebase.
Revenons à la raison pour laquelle l'article a été écrit.
Peut-être que votre application utilise Firebase avec un forfait gratuit, ou peut-être pas du tout. Il n'y a absolument aucune différence fondamentale, car pour les besoins de tests, nous pouvons créer un projet séparé avec un an d'utilisation gratuite (cool, non ?)
Nous nous connectons à notre compte d'infrastructure (ou tout autre, peu importe), et allons sur . Créez un nouveau projet nommé 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 nous conviennent plutôt bien.
Ne fermez pas l'onglet, inscrivez-vous sous le même compte dans - c'est une mesure nécessaire, puisque la communication avec Firebase s'effectue via l'interface de la console gcloud.
Google offre 300 $ par an, ce qui, dans le cadre de la réalisation d'autotests, équivaut à un an d'utilisation gratuite du service. Nous entrons vos informations de paiement, attendons le débit test de 1 $ et recevons 300 $ sur votre compte. Après un an, le projet sera automatiquement transféré vers un plan tarifaire gratuit, vous n'avez donc pas à vous soucier d'une éventuelle perte d'argent.
Revenons à l'onglet avec le projet Firebase et transférons-le vers le plan tarifaire Blaze - nous avons maintenant quelque chose à payer si la limite est dépassée.
Dans l'interface gcloud, sélectionnez notre projet Firebase, sélectionnez l'élément de menu principal « Répertoire » et ajoutez l'API Cloud Testing et l'API Cloud Tools Result.
Accédez ensuite à l'élément de menu « IAM et administration » -> Comptes de service -> Créer un compte de service. Nous accordons 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 la configuration du Test Lab terminée.
5. Configuration de CircleCI
Une question raisonnable se pose : que faire des mots de passe ? Le mécanisme de variable d'environnement de notre machine de construction nous aidera à stocker en toute sécurité nos mots de passe et autres données sensibles. Dans les paramètres du projet CircleCI, sélectionnez Variables d'environnement
Et configurez les variables suivantes :
- clé : GOOGLE_APPLICATION_CREDENTIALS
valeur : contenu du fichier json de la clé du compte de service gcloud - clé : MATCH_PASSWORD
value : mot de passe pour déchiffrer le dépôt github avec les certificats - clé : FASTLANE_PASSWORD
valeur : mot de passe du compte d'infrastructure du portail de développement Apple
Nous enregistrons les modifications, créons un PR et l'envoyons à notre chef d'équipe pour examen.
Les résultats de
Grâce à ces manipulations simples, nous avons reçu un bon support de travail stable avec la possibilité d'enregistrer une vidéo sur l'écran de l'appareil au moment des tests. Dans l'exemple de test, j'ai spécifié le modèle d'appareil iPhone X, mais la ferme propose une riche sélection parmi une combinaison de différents modèles et versions iOS.
La deuxième partie sera consacrée à la configuration étape par étape de Firebase Test Lab pour un projet Android.
Source: habr.com