Em dic Dmitry, treballo com a provador a l'empresa
Abans d'això, ja havia provat Firebase Test Lab per a Android i m'ha agradat molt tot, així que vaig decidir intentar posar la infraestructura de prova d'iOS del projecte en el mateix peu. Vaig haver de buscar molt a Google i no tot va funcionar la primera vegada, així que vaig decidir escriure un article tutorial per a aquells que encara estan lluitant.
Per tant, si teniu proves d'interfície d'usuari en un projecte d'iOS, ja podeu provar d'executar-les en dispositius reals avui, proporcionades amablement per Good Corporation. Per als interessats, benvinguts a cat.
A la història, vaig decidir basar-me en algunes dades inicials: un dipòsit privat a GitHub i el sistema de compilació CircleCI. El nom de l'aplicació és AmazingApp, bundleID és com.company.amazingapp. Presento aquestes dades immediatament per reduir la confusió posterior.
Si heu implementat determinades solucions al vostre projecte de manera diferent, compartiu la vostra experiència als comentaris.
1. Les proves en si
Creeu una branca de projecte nova per a proves d'IU:
$ git checkout develop
$ git pull
$ git checkout -b “feature/add-ui-tests”
Obrim el projecte a XCode i creem un nou Target amb proves d'interfície d'usuari [XCode -> Fitxer -> Nou -> Destí -> iOS Testing Bundle], donant-li el nom autoexplicatiu AmazingAppUITests.
Aneu a la secció Fases de compilació de l'objectiu creat i comproveu la presència de dependències de destinació - AmazingApp, a Fonts de compilació - AmazingAppUITests.swift.
Una bona pràctica és separar diferents opcions de compilació en esquemes separats. Creem un esquema per a les nostres proves d'IU [XCode -> Producte -> Esquema -> Esquema nou] i li donem el mateix nom: AmazingAppUITests.
La compilació de l'esquema creat ha d'incloure l'objectiu de l'aplicació principal: proves AmazingApp i Target UI - AmazingAppUITests - vegeu la captura de pantalla
A continuació, creem una nova configuració de compilació per a les proves d'IU. A XCode, feu clic al fitxer del projecte i aneu a la secció Informació. Feu clic a "+" i creeu una nova configuració, per exemple XCtest. Això ho necessitarem en el futur per evitar ballar amb un tamborí a l'hora de signar codi.
Hi ha almenys tres Targets al vostre projecte: l'aplicació principal, les proves unitàries (després de tot, existeixen, oi?) i les proves de la interfície d'usuari Target que hem creat.
Aneu a Target AmazingApp, pestanya Configuració de creació, secció Identitat de signatura de codi. Per a la configuració XCtest, seleccioneu Desenvolupador iOS. A la secció Estil de signatura de codi, seleccioneu Manual. Encara no hem generat un perfil d'aprovisionament, però segur que hi tornarem una mica més tard.
Per a Target AmazingAppUITests fem el mateix, però a la columna Product Bundle Identifier introduïm com.company.amazingappuitests.
2. Configuració d'un projecte a l'Apple Developer Program
Aneu a la pàgina del Programa per a desenvolupadors d'Apple, aneu a la secció Certificats, identificadors i perfils i després a la columna ID d'aplicació de l'element Identificadors. Creeu un nou identificador d'aplicació anomenat AmazingAppUITests i bundleID com.company.amazingappuitests.
Ara tenim l'oportunitat de signar les nostres proves amb un certificat a part, però... El procediment per muntar una compilació per a proves consisteix a muntar l'aplicació en si mateixa i muntar l'executor de proves. En conseqüència, ens enfrontem al problema de signar dos identificadors de paquet amb un perfil de subministrament. Afortunadament, hi ha una solució senzilla i elegant: ID de l'aplicació Wildcard. Repetim el procediment per crear un nou ID d'aplicació, però en comptes de l'identificador d'aplicació explícit, seleccioneu ID d'aplicació Wildcard com a la captura de pantalla.
En aquest moment, hem acabat de treballar amb developer.apple.com, però no minimitzarem la finestra del navegador. Anem a
Un lector atent va notar que per utilitzar aquesta utilitat necessitarem un repositori privat i un compte amb accés tant al Programa per a desenvolupadors d'Apple com a Github. Creem (si de sobte no hi ha tal cosa) un compte de la forma [protegit per correu electrònic], obteniu una contrasenya segura, registreu-la a developer.apple.com i designeu-la com a administrador del projecte. A continuació, donem al compte accés al dipòsit github de la vostra empresa i creem un nou dipòsit privat amb un nom com AmazingAppMatch.
3. Configuració de Fastlane i la utilitat de coincidència
Obriu un terminal, aneu a la carpeta amb el projecte i inicialitzeu Fastlane tal com s'indica a
$ fastlane init
Se us demanarà que seleccioneu les configuracions d'ús disponibles. Seleccioneu la quarta opció: configuració manual del projecte.
El projecte té un nou directori fastlane, que conté dos fitxers: Appfile i Fastfile. En poques paraules, emmagatzemem dades de servei a Appfile i escrivim treballs a Fastfile, anomenats carrils en terminologia de Fastlane. Recomano llegir la documentació oficial:
Obriu l'Appfile al vostre editor de text preferit i porteu-lo al següent formulari:
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
Tornem al terminal i segons el manual oficial comencem a configurar el partit.
$ fastlane match init
$ fastlane match development
A continuació, introduïu les dades sol·licitades: dipòsit, compte, contrasenya, etc.
Important: Quan inicieu la utilitat de concordança, se us demanarà que introduïu una contrasenya per desxifrar el dipòsit. És molt important desar aquesta contrasenya; la necessitarem quan configurem el servidor CI!
Ha aparegut un fitxer nou a la carpeta Fastlane: Matchfile. Obriu-lo al vostre editor de text preferit i mostra-lo així:
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
L'emplenarem exactament d'aquesta manera si volem utilitzar match en el futur per signar compilacions per mostrar-les a Crashlytics i/o AppStore, és a dir, per signar l'identificador del paquet de la vostra aplicació.
Però, com recordem, vam crear un identificador de comodí especial per signar la compilació de prova. Per tant, obriu Fastfile i introduïu un nou carril:
lane :testing_build_for_firebase do
match(
type: "development",
readonly: true,
app_identifier: "com.company.*",
git_branch: "uitests" # создаем отдельный бранч для development сертификата для подписи тестовой сборки.
)
end
Guarda i entra al terminal
fastlane testing_build_for_firebase
i veiem com Fastlane va crear un nou certificat i el va posar al repositori. Genial!
Obriu XCode. Ara tenim el perfil d'aprovisionament necessari del formulari Match Development com.company.*, que s'ha d'especificar a la secció Perfil d'aprovisionament per als objectius AmazingApp i AmazingAppUITests.
Queda per afegir carril per a proves de muntatge. Anem a
Copiem i enganxem de l'exemple original perquè el nostre carril testing_build_for_firebase acabi semblant així:
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
Per obtenir informació completa sobre la configuració de Fastlane a CircleCI, us recomano llegir la documentació oficial
No oblideu afegir una tasca nova al nostre 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è passa amb el nostre banc de proves? Configuració de Firebase.
Anem a veure per a què va ser escrit l'article.
Potser la vostra aplicació utilitza Firebase en un pla gratuït, o potser no. No hi ha absolutament cap diferència fonamental, perquè per a les necessitats de prova podem crear un projecte separat amb un any d'ús gratuït (genial, oi?)
Iniciem sessió al nostre compte d'infraestructura (o qualsevol altre, no importa) i anem a
Important: En el pas anterior del Fastfile al carril firebase_test_lab_ios_xctest, el paràmetre gcp_project hauria de coincidir amb el nom del projecte.
La configuració predeterminada ens va molt bé.
No tanqueu la pestanya, registreu-vos amb el mateix compte
Google dona 300 dòlars durant un any, que en el context de realitzar autotests equival a un any d'ús gratuït del servei. Introduïm la vostra informació de pagament, esperem el dèbit de prova d'1 $ i rebem 300 $ al vostre compte. Després d'un any, el projecte es transferirà automàticament a un pla tarifari gratuït, de manera que no cal que us preocupeu per una possible pèrdua de diners.
Tornem a la pestanya amb el projecte Firebase i el transferim al pla de tarifes Blaze; ara tenim alguna cosa a pagar si se supera el límit.
A la interfície de gcloud, seleccioneu el nostre projecte Firebase, seleccioneu l'element del menú principal "Directori" i afegiu l'API Cloud Testing i l'API de resultats de Cloud Tools.
A continuació, aneu a l'element del menú "IAM i administració" -> Comptes de servei -> Crea un compte de servei. Atorguem drets per editar el projecte.
Creeu una clau API en format JSON
Necessitarem el JSON descarregat una mica més tard, però de moment considerarem que la configuració del laboratori de proves està completa.
5. Configuració de CircleCI
Sorgeix una pregunta raonable: què fer amb les contrasenyes? El mecanisme de variable d'entorn de la nostra màquina de compilació ens ajudarà a emmagatzemar de manera segura les nostres contrasenyes i altres dades sensibles. A la configuració del projecte CircleCI, seleccioneu Variables d'entorn
I configureu les variables següents:
- clau: GOOGLE_APPLICATION_CREDENTIALS
valor: contingut del fitxer json de la clau del compte del servei gcloud - clau: MATCH_PASSWORD
valor: contrasenya per desxifrar el repositori github amb certificats - clau: FASTLANE_PASSWORD
valor: contrasenya del compte d'infraestructura del portal de desenvolupadors d'Apple
Desem els canvis, creem un PR i l'enviem al responsable del nostre equip perquè la revisi.
Resultats de
Com a resultat d'aquestes manipulacions senzilles, vam rebre un suport de treball bo i estable amb la possibilitat de gravar vídeo a la pantalla del dispositiu en el moment de la prova. A l'exemple de prova, vaig especificar el model de dispositiu iPhone X, però la granja ofereix una selecció rica entre una combinació de diferents models i versions d'iOS.
La segona part es dedicarà a la configuració pas a pas de Firebase Test Lab per a un projecte Android.
Font: www.habr.com