Mia nomo estas Dmitry, mi laboras kiel testisto en la kompanio . Sufiĉe lastatempe mi finis pritrakti relative lastatempan funkcion de — nome, kun instrumenta testado de iOS-aplikoj uzante la denaskan testan kadron XCUITest.
Antaŭ tio, mi jam provis Firebase Test Lab por Android kaj vere ŝatis ĉion, do mi decidis provi meti la iOS-testinfrastrukturon de la projekto sur la sama bazo. Mi devis multe Gugli kaj ne ĉio funkciis la unuan fojon, do mi decidis verki lernilon artikolon por tiuj, kiuj ankoraŭ luktas.
Do, se vi havas UI-testojn en iOS-projekto, vi jam povas provi ruli ilin sur realaj aparatoj hodiaŭ, afable provizitaj de Good Corporation. Por interesatoj, bonvenon al kato.
En la rakonto, mi decidis konstrui sur iuj komencaj datumoj - privata deponejo sur GitHub kaj la konstrusistemo CircleCI. La aplika nomo estas AmazingApp, bundleID estas com.company.amazingapp. Mi prezentas ĉi tiujn datumojn tuj por malpliigi postan konfuzon.
Se vi efektivigis iujn solvojn en via projekto malsame, dividu vian sperton en la komentoj.
1. La provoj mem
Kreu novan projektbranĉon por UI-testoj:
$ git checkout develop
$ git pull
$ git checkout -b “feature/add-ui-tests”
Ni malfermu la projekton en XCode kaj kreu novan Celon kun UI-testoj [XCode -> Dosiero -> Nova -> Celo -> iOS Testing Bundle], donante al ĝi la mem-klarigeblan nomon AmazingAppUITests.
Iru al la sekcio de Konstruaj Fazoj de la kreita Celo kaj kontrolu la ĉeeston de Celaj Dependecoj - AmazingApp, en Kompilaj Fontoj - AmazingAppUITests.swift.
Bona praktiko estas apartigi malsamajn konstruopciojn en apartajn Skemojn. Ni kreas skemon por niaj UI-testoj [XCode -> Produkto -> Skemo -> Nova Skemo] kaj donas al ĝi la saman nomon: AmazingAppUITests.
Konstruo de la kreita skemo devas inkluzivi la Celon de la ĉefa aplikaĵo - AmazingApp kaj Target UI-testoj - AmazingAppUITests - vidu ekranfoton
Poste ni kreas novan konstruan agordon por UI-testoj. En XCode, alklaku la projektdosieron kaj iru al la sekcio Info. Alklaku "+" kaj kreu novan agordon, ekzemple XCtest. Tion ni bezonos estonte por eviti dancadon per tamburino kiam temas pri kodsubskribo.
Estas almenaŭ tri Celoj en via projekto: la ĉefa aplikaĵo, unuotestoj (post ĉio, ili ekzistas, ĉu ne?) kaj la Target UI-testoj, kiujn ni kreis.
Iru al Target AmazingApp, la langeton de Konstruaj Agordoj, la sekcion de Kodo-Signo-Identeco. Por la agordo de XCtest, elektu iOS-Ellaboranto. En la sekcio de Stilo de Subskribo de Kodo, elektu Manlibron. Ni ankoraŭ ne generis provizoran profilon, sed ni certe revenos al ĝi iom poste.
Por Target AmazingAppUITests ni faras la samon, sed en la kolumno Product Bundle Identifier ni eniras com.company.amazingappuitests.
2. Agordi projekton en la Programo por Programistoj de Apple
Iru al la paĝo de Apple Programisto Programo, iru al la sekcio Atestiloj, Identigiloj kaj Profiloj kaj poste al la kolumno App IDs de la elemento Identigiloj. Kreu novan App-ID nomatan AmazingAppUITests kaj bundleID com.company.amazingappuitests.
Nun ni havas la ŝancon subskribi niajn testojn per aparta atestilo, sed... La proceduro por kunmeti konstruaĵon por testado implikas kunmeti la aplikaĵon mem kaj kunmeti la testkurilon. Sekve, ni alfrontas la problemon subskribi du pakaĵajn identigilojn kun unu provizanta profilo. Feliĉe, ekzistas simpla kaj eleganta solvo - Wildcard App ID. Ni ripetas la proceduron por krei novan App ID, sed anstataŭ Eksplicita App ID, elektu Wildcard App ID kiel en la ekrankopio.
Je ĉi tiu punkto, ni finis labori kun developer.apple.com, sed ni ne minimumigos la retumilon fenestro. Ni iru al kaj legu pri la Match-utilo de kovrilo ĝis kovrilo.
Atenta leganto rimarkis, ke por uzi ĉi tiun ilon, ni bezonos privatan deponejon kaj konton kun aliro kaj al la Programo por Programistoj de Apple kaj al Github. Ni kreas (se subite ne ekzistas tia afero) konton pri la formo [retpoŝte protektita], elpensu fortan pasvorton, registri ĝin ĉe developer.apple.com, kaj nomumu ĝin kiel projektadministranto. Poste, ni donas al la konto aliron al la github-deponejo de via kompanio kaj kreas novan privatan deponejon kun nomo kiel AmazingAppMatch.
3. Agordi Fastlane kaj la matĉo ilo
Malfermu terminalon, iru al la dosierujo kun la projekto kaj pravigu fastlane kiel indikite en . Post enigo de la komando
$ fastlane initOni petos vin elekti disponeblajn uzajn agordojn. Elektu la kvaran opcion - mana projekto-agordo.
La projekto havas novan dosierujon fastlane, kiu enhavas du dosierojn - Appfile kaj Fastfile. En resumo, ni stokas servajn datumojn en Appfile, kaj skribas laborpostenojn en Fastfile, nomataj lenoj en Fastlane-terminologio. Mi rekomendas legi la oficialan dokumentaron: , .
Malfermu la Appfile en via plej ŝatata tekstredaktilo kaj alportu ĝin al la sekva formo:
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
Ni revenas al la fina stacio kaj laŭ la oficiala manlibro ni komencas agordi kongruon.
$ fastlane match init
$ fastlane match development
Poste, enigu la petitajn datumojn - deponejo, konto, pasvorto, ktp.
Gravas: Kiam vi unue lanĉas la kongruan ilon, oni petos vin enigi pasvorton por deĉifri la deponejon. Estas tre grave konservi ĉi tiun pasvorton; ni bezonos ĝin dum agordo de la CI-servilo!
Nova dosiero aperis en la dosierujo de fastlane - Matchfile. Malfermu ĝin en via plej ŝatata tekstredaktilo kaj montru ĝin jene:
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
Ni plenigas ĝin ĝuste tiel se ni volas uzi kongruon estonte por subskribi konstruaĵojn por montri en Crashlytics kaj/aŭ AppStore, tio estas, por subskribi la pakaĵidentigilon de via aplikaĵo.
Sed, kiel ni memoras, ni kreis specialan Wildcard ID por subskribi la testan konstruon. Tial, malfermu Fastfile kaj eniru novan lenon:
lane :testing_build_for_firebase do
match(
type: "development",
readonly: true,
app_identifier: "com.company.*",
git_branch: "uitests" # создаем отдельный бранч для development сертификата для подписи тестовой сборки.
)
end
Konservu kaj eniru la terminalon
fastlane testing_build_for_firebasekaj ni vidas kiel fastlane kreis novan atestilon kaj metis ĝin en la deponejon. Bonege!
Malfermu XCode. Nun ni havas la necesan provizoprofilon de la formo Match Development com.company.*, kiu devas esti specifita en la Provisioning profilo sekcio por la AmazingApp kaj AmazingAppUITests celoj.
Restas aldoni vojon por kunvenado de provoj. Ni iru al kromprojekto por fastlane, kiu faciligas agordi eksportadon al Firebase Test Lab kaj sekvi la instrukciojn.
Ni kopiu-algluu de la originala ekzemplo, por ke nia leno testing_build_for_firebase aspektu tiel:
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
Por kompletaj informoj pri agordo de fastlane en CircleCI, mi rekomendas legi la oficialan dokumentaron .
Ne forgesu aldoni novan taskon al nia 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. Kio pri nia provbenko? Agordo de Firebase.
Ni ekkomprenu por kio la artikolo estis skribita.
Eble via programo uzas Firebase en senpaga plano, aŭ eble tute ne. Ne ekzistas absolute fundamenta diferenco, ĉar por testado de bezonoj ni povas krei apartan projekton kun jaro da senpaga uzo (malvarmeta, ĉu ne?)
Ni ensalutas al nia infrastruktura konto (aŭ iu ajn alia, ne gravas), kaj iras al . Kreu novan projekton nomitan AmazingAppUITests.
Gravas: En la antaŭa paŝo en la Fastfile en lane firebase_test_lab_ios_xctest la gcp_project parametro devas kongrui kun la projektonomo.
La defaŭltaj agordoj konvenas al ni sufiĉe bone.
Ne fermu la langeton, registriĝu sub la sama konto en - ĉi tio estas necesa mezuro, ĉar komunikado kun Firebase okazas uzante la gcloud-konzola interfaco.
Google donas $300 por jaro, kio en la kunteksto de farado de aŭtotestoj estas ekvivalenta al jaro da senpaga uzo de la servo. Ni enigas viajn pagajn informojn, atendas la provan debeton de $1 kaj ricevas $300 al via konto. Post unu jaro, la projekto estos aŭtomate translokigita al senpaga tarifa plano, do ne necesas zorgi pri ebla perdo de mono.
Ni revenu al la langeto kun la projekto Firebase kaj transdonu ĝin al la tarifplano Blaze - nun ni havas ion por pagi se la limo estas superita.
En la gcloud-interfaco, elektu nian Firebase-projekton, elektu la ĉefan menueron "Adresaro" kaj aldonu la Cloud Testing API kaj Cloud Tools Result API.
Poste iru al la menuero "IAM kaj administrado" -> Servaj kontoj -> Krei servokonton. Ni donas rajtojn redakti la projekton.
Kreu API-ŝlosilon en JSON-formato
Ni bezonos la elŝutitan JSON iom poste, sed nuntempe ni konsideros la aranĝon de Test Lab kompleta.
5. Starigante RondoCI
Racia demando ŝprucas - kion fari kun pasvortoj? La medio-varia mekanismo de nia konstrumaŝino helpos nin sekure stoki niajn pasvortojn kaj aliajn sentemajn datumojn. En la agordoj de la projekto CircleCI, elektu Mediajn Variablojn
Kaj agordu la sekvajn variablojn:
- ŝlosilo: GOOGLE_APPLICATION_CREDENTIALS
valoro: enhavo de la json-dosiero de la ŝlosilo de konto de gcloud servo - ŝlosilo: MATCH_PASSWORD
valoro: pasvorto por malĉifri la github-deponejon kun atestiloj - ŝlosilo: FASTLANE_PASSWORD
valoro: pasvorto de konto de infrastrukturo de Apple Developer Portal
Ni konservas la ŝanĝojn, kreas PR kaj sendas ĝin al nia teamgvidanto por revizio.
Rezultoj
Rezulte de ĉi tiuj simplaj manipuladoj, ni ricevis bonan, stabilan laborstandon kun la kapablo registri filmetojn sur la ekrano de la aparato en la momento de la provo. En la prova ekzemplo, mi specifis la modelon de iPhone X-aparato, sed la bieno provizas riĉan elekton el kombinaĵo de malsamaj modeloj kaj iOS-versioj.
La dua parto estos dediĉita al paŝo-post-paŝa aranĝo de Firebase Test Lab por Android-projekto.
fonto: www.habr.com