My naam is Dmitri, ek werk as 'n toetser in die maatskappy
Voor dit het ek reeds Firebase Test Lab vir Android probeer en het regtig van alles gehou, so ek het besluit om die iOS-toetsinfrastruktuur van die projek op dieselfde voet te probeer plaas. Ek moes baie Google en nie alles het die eerste keer uitgewerk nie, toe besluit ek om 'n tutoriaalartikel te skryf vir diegene wat nog sukkel.
Dus, as u UI-toetse op 'n iOS-projek het, kan u dit vandag reeds op regte toestelle probeer uitvoer, vriendelik verskaf deur Good Corporation. Vir belangstellendes, welkom om te kat.
In die storie het ek besluit om op 'n paar aanvanklike data te bou - 'n private bewaarplek op GitHub en die CircleCI-boustelsel. Die toepassing se naam is AmazingApp, bundleID is com.company.amazingapp. Ek bied hierdie data onmiddellik aan om daaropvolgende verwarring te verminder.
As jy sekere oplossings in jou projek anders geïmplementeer het, deel jou ervaring in die kommentaar.
1. Die toetse self
Skep 'n nuwe projektak vir UI-toetse:
$ git checkout develop
$ git pull
$ git checkout -b “feature/add-ui-tests”
Kom ons maak die projek in XCode oop en skep 'n nuwe teiken met UI-toetse [XCode -> Lêer -> Nuwe -> Teiken -> iOS-toetsbundel], gee dit die selfverduidelikende naam AmazingAppUITests.
Gaan na die Boufases-afdeling van die geskepte teiken en kyk vir die teenwoordigheid van teikenafhanklikhede - AmazingApp, in Compile Sources - AmazingAppUITests.swift.
'n Goeie praktyk is om verskillende bou-opsies in aparte Skemas te skei. Ons skep 'n skema vir ons UI-toetse [XCode -> Produk -> Skema -> Nuwe Skema] en gee dit dieselfde naam: AmazingAppUITests.
Bou van die geskepte skema moet die teiken van die hooftoepassing insluit - AmazingApp en Target UI-toetse - AmazingAppUITests - sien skermkiekie
Vervolgens skep ons 'n nuwe boukonfigurasie vir UI-toetse. Klik in XCode op die projeklêer en gaan na die Info-afdeling. Klik op "+" en skep 'n nuwe konfigurasie, byvoorbeeld XCtest. Ons sal dit in die toekoms nodig hê om te vermy om met 'n tamboeryn te dans wanneer dit by kodeondertekening kom.
Daar is ten minste drie teikens in jou projek: die hooftoepassing, eenheidstoetse (dit bestaan immers, reg?) en die teiken-UI-toetse wat ons geskep het.
Gaan na Target AmazingApp, Bou-instellings-oortjie, Code Signing Identity-afdeling. Kies iOS-ontwikkelaar vir die XCtest-konfigurasie. In die Code Signing Style-afdeling, kies Manual. Ons het nog nie 'n voorsieningsprofiel gegenereer nie, maar ons sal beslis 'n bietjie later daarna terugkeer.
Vir Target AmazingAppUITests doen ons dieselfde, maar in die Product Bundle Identifier-kolom voer ons com.company.amazingappuitests in.
2. Die opstel van 'n projek in die Apple Developer Program
Gaan na die Apple-ontwikkelaarprogrambladsy, gaan na die Sertifikate, Identifiseerders en Profiele-afdeling en dan na die Toepassing-ID's-kolom van die Identifiseerders-item. Skep 'n nuwe toepassing-ID genaamd AmazingAppUITests en bundleID com.company.amazingappuitests.
Nou het ons die geleentheid om ons toetse met 'n aparte sertifikaat te teken, maar... Die prosedure vir die samestelling van 'n bou vir toetsing behels die samestelling van die toepassing self en die samestelling van die toetsloper. Gevolglik word ons gekonfronteer met die probleem om twee bondel-ID's met een voorsieningsprofiel te onderteken. Gelukkig is daar 'n eenvoudige en elegante oplossing - Wildcard App ID. Ons herhaal die prosedure om 'n nuwe toepassing-ID te skep, maar in plaas van eksplisiete toepassing-ID, kies Wildkaart-toepassings-ID soos in die skermkiekie.
Op hierdie stadium is ons klaar met developer.apple.com, maar ons sal nie die blaaiervenster verklein nie. Kom ons gaan na
'n Oplettende leser het opgemerk dat ons 'n privaat bewaarplek en 'n rekening met toegang tot beide die Apple-ontwikkelaarprogram en Github benodig om hierdie hulpprogram te gebruik. Ons skep (as daar skielik nie so iets is nie) 'n rekening van die vorm [e-pos beskerm], kom met 'n sterk wagwoord, registreer dit by developer.apple.com, en stel dit as 'n projekadministrateur aan. Vervolgens gee ons die rekening toegang tot u maatskappy se github-bewaarplek en skep 'n nuwe private bewaarplek met 'n naam soos AmazingAppMatch.
3. Die opstel van Fastlane en die wedstrydprogram
Maak 'n terminaal oop, gaan na die gids met die projek en inisialiseer fastlane soos aangedui in
$ fastlane init
Jy sal gevra word om beskikbare gebruikkonfigurasies te kies. Kies die vierde opsie - handmatige projekopstelling.
Die projek het 'n nuwe gids fastlane, wat twee lêers bevat - Appfile en Fastfile. In 'n neutedop, ons stoor diensdata in Appfile, en skryf take in Fastfile, genoem lane in Fastlane-terminologie. Ek beveel aan om die amptelike dokumentasie te lees:
Maak die App-lêer oop in jou gunsteling teksredigeerder en bring dit na die volgende vorm:
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
Ons keer terug na die terminale en volgens die amptelike handleiding begin ons wedstryd opstel.
$ fastlane match init
$ fastlane match development
Voer dan die gevraagde data in - bewaarplek, rekening, wagwoord, ens.
Belangrik: Wanneer jy die wedstrydprogram die eerste keer begin, sal jy gevra word om 'n wagwoord in te voer om die bewaarplek te dekripteer. Dit is baie belangrik om hierdie wagwoord te stoor; ons sal dit nodig hê wanneer die CI-bediener opgestel word!
'n Nuwe lêer het in die fastlane-lêergids verskyn - Matchfile. Maak dit oop in jou gunsteling teksredigeerder en vertoon dit so:
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
Ons vul dit presies so in as ons passing in die toekoms wil gebruik om bouwerk te teken vir vertoon in Crashlytics en/of AppStore, dit wil sê om die bondel-ID van jou aansoek te onderteken.
Maar, soos ons onthou, het ons 'n spesiale Wildcard-ID geskep om die toetsbou te onderteken. Maak dus Fastfile oop en voer 'n nuwe baan in:
lane :testing_build_for_firebase do
match(
type: "development",
readonly: true,
app_identifier: "com.company.*",
git_branch: "uitests" # создаем отдельный бранч для development сертификата для подписи тестовой сборки.
)
end
Stoor en gaan in die terminale in
fastlane testing_build_for_firebase
en ons sien hoe fastlane 'n nuwe sertifikaat geskep het en dit in die bewaarplek geplaas het. Puik!
Maak XCode oop. Nou het ons die nodige voorsieningsprofiel van die vorm Match Development com.company.*, wat in die Voorsieningsprofiel-afdeling vir die AmazingApp- en AmazingAppUITests-teikens gespesifiseer moet word.
Dit bly om baan by te voeg vir die samestelling van toetse. Kom ons gaan na
Kom ons kopieer-plak vanaf die oorspronklike voorbeeld sodat ons baantoetsing_build_for_firebase uiteindelik so lyk:
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
Vir volledige inligting oor die opstel van fastlane in CircleCI, beveel ek aan om die amptelike dokumentasie te lees
Moenie vergeet om 'n nuwe taak by ons config.yml te voeg nie:
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. Wat van ons toetsbank? Stel tans Firebase op.
Kom ons gaan na waarvoor die artikel geskryf is.
Miskien gebruik jou program Firebase op 'n gratis plan, of dalk glad nie. Daar is absoluut geen fundamentele verskil nie, want vir toetsbehoeftes kan ons 'n aparte projek skep met 'n jaar se gratis gebruik (cool, reg?)
Ons meld aan by ons infrastruktuurrekening (of enige ander, dit maak nie saak nie), en gaan na
Belangrik: In die vorige stap in die Fastfile in lane firebase_test_lab_ios_xctest moet die gcp_project parameter ooreenstem met die projek naam.
Die verstekinstellings pas ons redelik goed.
Moenie die oortjie toemaak nie, registreer onder dieselfde rekening in
Google gee $300 vir 'n jaar, wat in die konteks van die uitvoering van outotoetse gelykstaande is aan 'n jaar van gratis gebruik van die diens. Ons voer jou betalingsinligting in, wag vir die toetsdebiet van $1 en ontvang $300 op jou rekening. Na 'n jaar sal die projek outomaties na 'n gratis tariefplan oorgedra word, dus hoef u nie bekommerd te wees oor moontlike verlies aan geld nie.
Kom ons keer terug na die oortjie met die Firebase-projek en dra dit oor na die Blaze-tariefplan – nou het ons iets om te betaal as die limiet oorskry word.
In die gcloud-koppelvlak, kies ons Firebase-projek, kies die "Directory"-hoofkieslys-item en voeg die Cloud Testing API en Cloud Tools Result API by.
Gaan dan na die kieslys-item “IAM en administrasie” -> Diensrekeninge -> Skep diensrekening. Ons verleen regte om die projek te redigeer.
Skep 'n API-sleutel in JSON-formaat
Ons sal die afgelaaide JSON 'n bietjie later nodig hê, maar vir nou sal ons die toetslaboratorium-opstelling as voltooi beskou.
5. Die opstel van CircleCI
'N Redelike vraag ontstaan - wat om te doen met wagwoorde? Die omgewingsveranderlike meganisme van ons boumasjien sal ons help om ons wagwoorde en ander sensitiewe data veilig te stoor. In die CircleCI-projekinstellings, kies Omgewingsveranderlikes
En stel die volgende veranderlikes op:
- sleutel: GOOGLE_APPLICATION_CREDENTIALS
waarde: inhoud van die json-lêer van die gcloud-diensrekeningsleutel - sleutel: MATCH_PASSWORD
waarde: wagwoord vir die dekripteer van die github-bewaarplek met sertifikate - sleutel: FASTLANE_PASSWORD
waarde: Apple Developer Portal infrastruktuur rekening wagwoord
Ons stoor die veranderinge, skep 'n PR en stuur dit na ons spanleier vir hersiening.
Resultate van
As gevolg van hierdie eenvoudige manipulasies het ons 'n goeie, stabiele werkstaander ontvang met die vermoë om video op die toestelskerm op te neem ten tyde van die toets. In die toetsvoorbeeld het ek die iPhone X-toestelmodel gespesifiseer, maar die plaas bied 'n ryk keuse uit 'n kombinasie van verskillende modelle en iOS-weergawes.
Die tweede deel sal gewy word aan stap-vir-stap opstelling van Firebase Test Lab vir 'n Android-projek.
Bron: will.com