Mi chiamo Dmitry, lavoro come tester in un'azienda . Più di recente, ho finito di occuparmi di una funzionalità relativamente nuova di - in particolare, con test strumentali di applicazioni iOS utilizzando il framework di test nativo XCUITest.
Prima di allora, avevo già provato Firebase Test Lab per Android e mi piaceva davvero tutto, quindi ho deciso di provare a mettere l'infrastruttura di test iOS del progetto sugli stessi binari. Ho dovuto cercare molto su Google e non tutto ha funzionato la prima volta, quindi ho deciso di scrivere un articolo tutorial per coloro che devono ancora farlo.
Quindi, se hai test dell'interfaccia utente su un progetto iOS, puoi già provare a eseguirli su dispositivi reali oggi, gentilmente forniti dalla Good Corporation. Interessato - benvenuto sotto cat.
Nella storia, ho deciso di basarmi su alcuni dati di origine: un repository privato su GitHub e il sistema di compilazione CircleCI. Il nome dell'applicazione è AmazingApp, bundleID è com.company.amazingapp. Cito subito questi dati, per ridurre la confusione successiva.
Se hai implementato alcune soluzioni nel tuo progetto in modo diverso, condividi la tua esperienza nei commenti.
1. I test stessi
Crea un nuovo ramo del progetto per i test dell'interfaccia utente:
$ git checkout develop
$ git pull
$ git checkout -b “feature/add-ui-tests”
Apriamo il progetto in XCode e creiamo un nuovo Target con UI test [XCode -> File -> New -> Target -> iOS Testing Bundle], assegnagli il nome eloquente AmazingAppUITests.
Vai alla sezione Fasi di compilazione della destinazione creata e controlla Dependencies destinazione - AmazingApp, in Compile Sources - AmazingAppUITests.swift.
È buona norma separare le varie opzioni di compilazione in schemi separati. Creiamo uno schema per i nostri test dell'interfaccia utente [XCode -> Prodotto -> Schema -> Nuovo schema] e gli diamo lo stesso nome: AmazingAppUITests.
La build dello schema creato dovrebbe includere il Target dell'applicazione principale - Test AmazingApp e Target UI - AmazingAppUITests - vedi screenshot
Successivamente, creiamo una nuova configurazione di build per i test dell'interfaccia utente. In Xcode, fai clic sul file di progetto, vai alla sezione Informazioni. Fare clic sul "+" e creare una nuova configurazione, ad esempio XCtest. Ne avremo bisogno in futuro per evitare di ballare con un tamburello quando si tratta di firmare il codice.
Ci sono almeno tre obiettivi nel tuo progetto: l'applicazione principale, gli unit test (ce ne sono alcuni, giusto?) e l'interfaccia utente di destinazione dei test che abbiamo creato.
Vai a Target AmazingApp, scheda Build Settings, sezione Code Signing Identity. Per la configurazione XCtest, seleziona Sviluppatore iOS. Nella sezione Stile firma codice selezionare Manuale. Non abbiamo ancora generato un profilo di provisioning, ma ci torneremo sicuramente un po' più tardi.
Per Target AmazingAppUITests, facciamo lo stesso, ma inseriamo com.company.amazingappuitests nella colonna Product Bundle Identifier.
2. Impostazione di un progetto nell'Apple Developer Program
Andiamo nella pagina dell'Apple Developer Program, andiamo nella sezione Certificates, Identifiers & Profiles e poi nella colonna App IDs della voce Identifiers. Crea un nuovo ID app denominato AmazingAppUITests e bundleID com.company.amazingappuitests.
Ora abbiamo l'opportunità di firmare i nostri test con un certificato separato, ma ... La procedura di compilazione per i test prevede la creazione dell'applicazione stessa e la creazione del test runner. Di conseguenza, ci troviamo di fronte al problema di firmare due ID bundle con un profilo di provisioning. Fortunatamente, esiste una soluzione semplice ed elegante: l'ID app jolly. Ripetiamo la procedura per la creazione di un nuovo App ID, ma invece di Explicit App ID, selezioniamo Wildcard App ID come nello screenshot.
A questo punto, abbiamo finito con developer.apple.com, ma non ridurremo a icona la finestra del browser. Andiamo a e leggi l'utilità Match da copertina a copertina.
Un lettore attento ha notato che per utilizzare questa utility, abbiamo bisogno di un repository privato e di un account che abbia accesso sia all'Apple Developer Program che a Github. Creiamo (se all'improvviso non esiste una cosa del genere) un resoconto della forma [email protected], crea una password complessa, registrala su developer.apple.com e nominala come amministratore del progetto. Quindi, dai al tuo account l'accesso al repository github della tua azienda e crea un nuovo repository privato con un nome come AmazingAppMatch.
3. Configurazione di Fastlane e dell'utilità di corrispondenza
Apri il terminale, vai nella cartella con il progetto e inizializza fastlane come indicato in . Dopo aver inserito il comando
$ fastlane initverrà richiesto di selezionare le configurazioni di utilizzo disponibili. Selezioniamo il quarto elemento: configurazione manuale del progetto.
Nel progetto è apparsa una nuova directory fastlane, in cui sono presenti due file: Appfile e Fastfile. In poche parole: in Appfile memorizziamo i dati di servizio e in Fastfile scriviamo lavori, nella terminologia Fastlane chiamati corsie. Consiglio di leggere la documentazione ufficiale: , .
Apri l'Appfile nel tuo editor di testo preferito e portalo nel seguente modulo:
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
Torniamo al terminale e, secondo il manuale ufficiale, iniziamo a configurare la partita.
$ fastlane match init
$ fastlane match development
Quindi, inserisci i dati richiesti: repository, account, password, ecc.
Importante: la prima volta che esegui l'utility match, ti chiederà di inserire una password per decrittografare il repository. È molto importante salvare questa password, ne avremo bisogno nella fase di configurazione del server CI!
Nella cartella fastlane è apparso un nuovo file: Matchfile. Aprilo nel tuo editor di testo preferito e portalo nel modulo:
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
Lo compiliamo in questo modo se vogliamo utilizzare match in futuro per firmare build da caricare su Crashlytics e/o AppStore, ovvero per firmare l'ID bundle della tua applicazione.
Ma, come ricordiamo, abbiamo creato uno speciale ID jolly per firmare la build di test. Pertanto, apri Fastfile e inserisci una nuova corsia:
lane :testing_build_for_firebase do
match(
type: "development",
readonly: true,
app_identifier: "com.company.*",
git_branch: "uitests" # создаем отдельный бранч для development сертификата для подписи тестовой сборки.
)
end
Salva, entra nel terminale
fastlane testing_build_for_firebasee guarda come fastlane ha creato un nuovo certificato e lo ha inserito nel repository. Grande!
Apri Xcode. Ora abbiamo il profilo di provisioning richiesto del tipo Match Development com.company.*, che deve essere specificato nella sezione Provisioning profile per i target AmazingApp e AmazingAppUITests.
Resta da aggiungere la corsia per costruire i test. Andiamo a progetto plug-in fastlane che semplifica l'impostazione dell'esportazione in Firebase Test Lab e il rispetto delle istruzioni.
Copia e incolla dall'esempio originale in modo che la nostra corsia testing_build_for_firebase finisca per avere questo aspetto:
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 informazioni complete sulla configurazione di fastlane in CircleCI, consiglio di leggere la documentazione ufficiale .
Non dimenticare di aggiungere una nuova attività al nostro 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. E il nostro banco prova? Configurazione di Firebase.
Procediamo, infatti, a ciò per cui è stato scritto l'articolo.
La tua app potrebbe utilizzare Firebase con un piano gratuito o potrebbe non utilizzare affatto Firebase. Non c'è assolutamente alcuna differenza fondamentale, perché per esigenze di test possiamo creare un progetto separato con un anno di utilizzo gratuito (bello, eh?)
Accediamo al nostro account infrastruttura (o qualsiasi altro, non importa) e andiamo a . Crea un nuovo progetto denominato AmazingAppUITests.
Importante: Nel passaggio precedente, nel Fastfile nella corsia firebase_test_lab_ios_xctest, il parametro gcp_project deve corrispondere al nome del progetto.
Le impostazioni predefinite ci stanno bene.
Non chiudiamo la scheda, ci registriamo con lo stesso account in è una misura necessaria, poiché la comunicazione con Firebase avviene tramite l'interfaccia della console gcloud.
Google sta regalando $ 300 per un anno, che nel contesto dell'esecuzione di test automatici equivale a un anno di utilizzo gratuito del servizio. Inseriamo i dati di pagamento, aspettiamo lo storno di prova di $ 1 e riceviamo $ 300 sul conto. Dopo un anno, il progetto verrà automaticamente trasferito a un piano tariffario gratuito, quindi non dovresti preoccuparti della possibile perdita di denaro.
Torniamo alla scheda con il progetto Firebase e trasferiamolo nel piano tariffario Blaze: ora abbiamo qualcosa da pagare se il limite viene superato.
Nell'interfaccia gcloud, seleziona il nostro progetto Firebase, seleziona la voce di menu principale "Catalogo" e aggiungi l'API Cloud Testing e l'API Cloud Tools Result.
Quindi vai alla voce di menu "IAM e amministrazione" -> Account di servizio -> Crea un account di servizio. Concedere l'autorizzazione per modificare il progetto.
Crea una chiave API in formato JSON
Avremo bisogno del JSON scaricato un po' più tardi, ma per ora considereremo completa la configurazione del Test Lab.
5. Impostazione di CircleCI
Si sta preparando una domanda ragionevole: cosa fare con le password? Per mantenere le nostre password e altri dati sensibili al sicuro, il meccanismo delle variabili d'ambiente della nostra macchina di compilazione ci aiuterà. Nelle impostazioni del progetto CircleCI, seleziona Variabili d'ambiente
E imposta le seguenti variabili:
- chiave: GOOGLE_APPLICATION_CREDENTIALS
valore: contenuto del file json della chiave dell'account di servizio gcloud - chiave: MATCH_PASSWORD
valore: password per decrittografare il repository github con i certificati - chiave: FASTLANE_PASSWORD
valore: password dell'account dell'infrastruttura dell'Apple Developer Portal
Salviamo le modifiche, creiamo un PR e lo inviamo al nostro responsabile del team per la revisione.
Risultati di
Come risultato di queste semplici manipolazioni, abbiamo ottenuto un supporto di lavoro buono e stabile con la possibilità di registrare video sullo schermo del dispositivo al momento del test. Nel caso di test, ho specificato il modello del dispositivo iPhone X, ma la farm offre una ricca selezione da una combinazione di diversi modelli e versioni iOS.
La seconda parte sarà dedicata alla configurazione passo dopo passo di Firebase Test Lab per un progetto Android.
Fonte: habr.com