Nimeni on Dmitry, työskentelen testaajana yrityksessä . Aivan äskettäin lopetin käsittelemään suhteellisen tuoretta ominaisuutta — nimittäin iOS-sovellusten instrumentaalista testausta käyttämällä alkuperäistä XCUITest-testauskehystä.
Ennen tätä olin jo kokeillut Firebase Test Lab for Android ja pidin todella kaikesta, joten päätin yrittää laittaa projektin iOS-testiinfrastruktuurin samalle tasolle. Jouduin googlettamaan paljon, eikä kaikki toiminut ensimmäisellä kerralla, joten päätin kirjoittaa opetusartikkelin niille, jotka kamppailevat edelleen.
Joten jos sinulla on käyttöliittymätestejä iOS-projektissa, voit jo tänään kokeilla niitä oikeilla laitteilla Good Corporationin ystävällisesti tarjoamana. Kiinnostuneet tervetuloa kissoihin.
Tarinassa päätin rakentaa alkutietoihin - GitHubin yksityiseen tietovarastoon ja CircleCI-rakennusjärjestelmään. Sovelluksen nimi on AmazingApp, bundleID on com.company.amazingapp. Esitän nämä tiedot välittömästi myöhemmän hämmennyksen vähentämiseksi.
Jos toteutit tiettyjä ratkaisuja projektissasi eri tavalla, jaa kokemuksesi kommenteissa.
1. Itse testit
Luo uusi projektihaara käyttöliittymätestejä varten:
$ git checkout develop
$ git pull
$ git checkout -b “feature/add-ui-tests”
Avataan projekti XCodessa ja luodaan uusi kohde käyttöliittymätesteillä [XCode -> File -> New -> Target -> iOS Testing Bundle] ja annetaan sille itsestään selvä nimi AmazingAppUITests.
Siirry luodun kohteen Build Phases -osioon ja tarkista Target Dependencies - AmazingApp -kohteen olemassaolo kohdassa Compile Sources - AmazingAppUITests.swift.
Hyvä käytäntö on erottaa eri rakennusvaihtoehdot erillisiksi skeemoiksi. Luomme käyttöliittymätesteillemme järjestelmän [XCode -> Tuote -> Scheme -> New Scheme] ja annamme sille saman nimen: AmazingAppUITests.
Luodun järjestelmän koontiversion tulee sisältää pääsovelluksen kohde - AmazingApp ja Target UI -testit - AmazingAppUITests - katso kuvakaappaus
Seuraavaksi luomme uuden koontikokoonpanon käyttöliittymätestejä varten. Napsauta XCodessa projektitiedostoa ja siirry Info-osioon. Napsauta “+” ja luo uusi konfiguraatio, esimerkiksi XCtest. Tarvitsemme tätä tulevaisuudessa välttääksemme tamburiinin kanssa tanssimista koodin allekirjoittamisen yhteydessä.
Projektissasi on vähintään kolme kohdetta: pääsovellus, yksikkötestit (niitähän on olemassa, eikö?) ja luomamme Target UI -testit.
Siirry Target AmazingApp, Build Settings -välilehteen, Code Signing Identity -osioon. Valitse XCtest-kokoonpanoa varten iOS Developer. Valitse Code Signing Style -osiossa Manuaalinen. Emme ole vielä luoneet provisiointiprofiilia, mutta palaamme siihen varmasti hieman myöhemmin.
Target AmazingAppUITestsille teemme samoin, mutta Product Bundle Identifier -sarakkeeseen kirjoitamme com.company.amazingappuitests.
2. Projektin määrittäminen Apple Developer Programissa
Siirry Apple Developer Program -sivulle, siirry Certificates, Identifiers & Profiles -osioon ja sitten Tunnisteet-kohdan App IDs -sarakkeeseen. Luo uusi sovellustunnus nimeltä AmazingAppUITests ja bundleID com.company.amazingappuitests.
Nyt meillä on mahdollisuus allekirjoittaa testimme erillisellä sertifikaatilla, mutta... Rakenteen kokoamiseen testausta varten kuuluu itse sovelluksen kokoaminen ja testiajolaitteen kokoaminen. Vastaavasti kohtaamme ongelman allekirjoittaa kaksi nipputunnusta yhdellä provisiointiprofiililla. Onneksi on olemassa yksinkertainen ja tyylikäs ratkaisu - Wildcard App ID. Toistamme menettelyn uuden sovellustunnuksen luomiseksi, mutta valitse nimenomaisen sovellustunnuksen sijaan jokerimerkki, kuten kuvakaappauksessa.
Tässä vaiheessa olemme lopettaneet työskentelyn developer.apple.com-sivuston kanssa, mutta emme pienennä selainikkunaa. Mennään ja lue Match-apuohjelmasta kannesta kanteen.
Huomaavainen lukija huomasi, että tämän apuohjelman käyttämiseksi tarvitsemme yksityisen arkiston ja tilin, jolla on pääsy sekä Applen kehittäjäohjelmaan että Githubiin. Luomme (jos yhtäkkiä sellaista ei ole) lomakkeesta tilin [sähköposti suojattu], keksi vahva salasana, rekisteröi se osoitteessa developer.apple.com ja nimeä se projektin järjestelmänvalvojaksi. Seuraavaksi annamme tilille pääsyn yrityksesi github-tietovarastoon ja luomme uuden yksityisen arkiston nimellä AmazingAppMatch.
3. Fastlanen ja match-apuohjelman määrittäminen
Avaa pääte, siirry kansioon, jossa projekti on ja alusta fastlane kuvan mukaisesti . Komennon syöttämisen jälkeen
$ fastlane initSinua pyydetään valitsemaan käytettävissä olevat käyttöasetukset. Valitse neljäs vaihtoehto - manuaalinen projektin määritys.
Projektissa on uusi hakemisto fastlane, joka sisältää kaksi tiedostoa - Appfile ja Fastfile. Lyhyesti sanottuna tallennamme palvelutiedot Appfileen ja kirjoitamme työt Fastfileen, joita kutsutaan Fastlane-terminologiassa kaistaksi. Suosittelen lukemaan viralliset asiakirjat: , .
Avaa Appfile suosikkitekstieditorissasi ja tuo se seuraavaan muotoon:
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
Palaamme terminaaliin ja virallisen käsikirjan mukaisesti alamme määrittää matchin.
$ fastlane match init
$ fastlane match development
Syötä seuraavaksi pyydetyt tiedot - arkisto, tili, salasana jne.
Tärkeää: Kun käynnistät match-apuohjelman ensimmäisen kerran, sinua pyydetään antamaan salasana arkiston salauksen purkamiseksi. Tämän salasanan tallentaminen on erittäin tärkeää, tarvitsemme sitä CI-palvelinta määritettäessä!
Fastlane-kansioon on ilmestynyt uusi tiedosto - Matchfile. Avaa se suosikkitekstieditorissasi ja näytä se seuraavasti:
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
Täytämme sen juuri tällä tavalla, jos haluamme käyttää matchiä jatkossa koontiversioiden allekirjoittamiseen Crashlyticsissa ja/tai AppStoressa näytettäväksi, eli sovelluksesi pakettitunnuksen allekirjoittamiseen.
Mutta kuten muistamme, loimme erityisen jokerimerkkitunnuksen allekirjoittamaan testikoon. Siksi avaa Fastfile ja siirry uudelle kaistalle:
lane :testing_build_for_firebase do
match(
type: "development",
readonly: true,
app_identifier: "com.company.*",
git_branch: "uitests" # создаем отдельный бранч для development сертификата для подписи тестовой сборки.
)
end
Tallenna ja syötä terminaaliin
fastlane testing_build_for_firebaseja näemme kuinka fastlane loi uuden varmenteen ja laittoi sen arkistoon. Loistava!
Avaa XCode. Nyt meillä on tarvittava hallintaprofiili muodossa Match Development com.company.*, joka on määritettävä AmazingApp- ja AmazingAppUITests-kohteiden Provisioning profile -osiossa.
On vielä lisättävä kaista kokoonpanotestejä varten. Mennään fastlane-laajennusprojekti, joka helpottaa Firebase Test Labiin viennin määrittämistä ja ohjeiden noudattamista.
Kopioi-liitä alkuperäisestä esimerkistä niin, että kaistan testaus_build_for_firebase näyttää tältä:
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
Täydelliset tiedot fastlanen määrittämisestä CircleCI:ssä suosittelen lukemaan viralliset asiakirjat .
Älä unohda lisätä uutta tehtävää config.yml-tiedostoomme:
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. Entä testipenkkimme? Firebasen käyttöönotto.
Mennään siihen, mitä varten artikkeli on kirjoitettu.
Ehkä sovelluksesi käyttää Firebasea ilmaiseksi tai ei ollenkaan. Perusteellista eroa ei ole, sillä testaustarpeita varten voimme luoda erillisen projektin vuoden ilmaisella käytöllä (hienoa, eikö?)
Kirjaudumme sisään infrastruktuuritiliimme (tai mihin tahansa muuhun, sillä ei ole väliä) ja menemme osoitteeseen . Luo uusi projekti nimeltä AmazingAppUITests.
Tärkeää: Edellisessä vaiheessa Fastfile in lane firebase_test_lab_ios_xctest gcp_project-parametrin tulee vastata projektin nimeä.
Oletusasetukset sopivat meille varsin hyvin.
Älä sulje välilehteä, vaan rekisteröidy samalle tilille - Tämä on välttämätön toimenpide, koska viestintä Firebasen kanssa tapahtuu gcloud-konsolin käyttöliittymän avulla.
Google antaa 300 dollaria vuodeksi, mikä vastaa automaattisten testien suorittamisen yhteydessä vuoden ilmaista palvelun käyttöä. Annamme maksutietosi, odotamme 1 dollarin testiveloitusta ja saamme 300 dollaria tilillesi. Vuoden kuluttua projekti siirtyy automaattisesti ilmaiseen tariffisuunnitelmaan, joten mahdollisista rahan menetyksistä ei tarvitse huolehtia.
Palataan Firebase-projektin välilehdelle ja siirretään se Blaze-tariffisuunnitelmaan - nyt meillä on jotain maksettavaa, jos raja ylittyy.
Valitse gcloud-käyttöliittymässä Firebase-projektimme, valitse "Hakemisto"-päävalikkokohta ja lisää Cloud Testing API ja Cloud Tools Result API.
Siirry sitten valikkokohtaan "IAM ja hallinto" -> Palvelutilit -> Luo palvelutili. Myönnämme projektin editointioikeudet.
Luo API-avain JSON-muodossa
Tarvitsemme ladatun JSONin hieman myöhemmin, mutta toistaiseksi katsomme, että Test Lab -asennus on valmis.
5. CircleCI:n määrittäminen
Herää järkevä kysymys - mitä tehdä salasanoilla? Rakennuskoneemme ympäristömuuttujamekanismi auttaa meitä tallentamaan salasanamme ja muut arkaluontoiset tiedot turvallisesti. Valitse CircleCI-projektin asetuksista Ympäristömuuttujat
Ja määritä seuraavat muuttujat:
- avain: GOOGLE_APPLICATION_CREDENTIALS
arvo: gcloud-palvelutilin avaimen json-tiedoston sisältö - avain: MATCH_PASSWORD
arvo: salasana github-varaston salauksen purkamiseen varmenteilla - avain: FASTLANE_PASSWORD
arvo: Apple Developer Portal -infrastruktuuritilin salasana
Tallennamme muutokset, luomme PR:n ja lähetämme sen tiimimme johtajalle tarkistettavaksi.
Tulokset
Näiden yksinkertaisten manipulaatioiden tuloksena saimme hyvän, vakaan työtelineen, jolla on mahdollisuus tallentaa videota laitteen näytölle testaushetkellä. Testiesimerkissä määritin iPhone X -laitemallin, mutta maatila tarjoaa runsaan valikoiman eri mallien ja iOS-versioiden yhdistelmästä.
Toinen osa on omistettu Firebase Test Labin vaiheittaiselle asennukselle Android-projektia varten.
Lähde: will.com