🥇Začnemo z izvajanjem instrumentalnih testov v Firebase Test Lab. Del 1: iOS projekt

Moje ime je Dmitrij, delam kot tester v podjetju MEL Science. Ravno nedavno sem zaključil raziskovanje dokaj sveže funkcionalnosti od Firebase Test Lab — natančneje, s instrumentalnim testiranjem iOS aplikacij z uporabo nativnega testnega okvira XCUITest.

Pred tem sem že preizkusil Firebase Test Lab za Android in mi je bilo vse zelo všeč, zato sem se odločil, da poskusim postaviti testno infrastrukturo za iOS projekt na iste tirnice. Veliko sem iskal po spletu in ne vse je šlo od prvega poskusa, zato sem se odločil napisati učni članek za tiste, ki se še pripravljajo na to.

Torej, če imate UI teste za iOS projekt, lahko že danes poskusite zagnati te teste na pravih napravah, ki jih prijazno zagotavlja Korporacija Dobro. Zainteresirani — dobrodošli pod kat.

V pripovedi sem se odločil izhajati iz nekaterih izvornih podatkov — zasebna repozitorij na GitHubu in sistem gradnje CircleCI. Ime aplikacije je AmazingApp, bundleID — com.company.amazingapp. Te podatke navajam takoj, da zmanjšam kasnejše zmedo.

Če ste kakšne rešitve v svojem projektu uresničili drugače — delite izkušnje v komentarjih.

1. Testi

Ustvarimo novo vejo projekta za UI teste:

$ git checkout develop
$ git pull
$ git checkout -b “feature/add-ui-tests”

Odprimo projekt v XCode in ustvarimo nov cilj (Target) z UI testi [XCode -> File -> New -> Target -> iOS Testing Bundle], in mu damo jasen naslov AmazingAppUITests.

Preverimo oddelek Build Phases ustvarjenega Target in zagotovimo, da so prisotni Target Dependencies — AmazingApp, v Compile Sources — AmazingAppUITests.swift.

Dobra praksa je, da različne variante gradnje razdelimo v ločene sheme (Schemes). Ustvarimo shemo za naše UI teste [XCode -> Product -> Scheme -> New Scheme] in ji damo enako ime: AmazingAppUITests.

Gradnja ustvarjene sheme mora vsebovati Target glavne aplikacije — AmazingApp in Target UI testov — AmazingAppUITests — glej posnetek zaslona.

Nato ustvarimo novo konfiguracijo gradnje za UI teste. V XCode kliknemo na datoteko projekta, preidemo v oddelek Info. Kliknemo na “+” in ustvarimo novo konfiguracijo, na primer XCtest. To nam bo potrebna kasneje, da se izognemo težavam pri podpisovanju kode.

V vašem projektu so vsaj tri Target: glavna aplikacija, enotni testi (saj jih imate, kajne?) in Target UI testov, ki smo ga ustvarili.

Odprli smo Target AmazingApp, zavihek Build Settings, razdelek Code Signing Identity. Za konfiguracijo XCtest izberemo iOS Developer. V razdelku Code Signing Style izberemo Manual. Provisioning profile še nismo ustvarili, vendar se bomo do njega vrnili nekoliko kasneje.

Za Target AmazingAppUITests naredimo enako, vendar v polje Product Bundle Identifier vpišemo com.company.amazingappuitests.

2. Nastavitev projekta v Apple Developer Program

Odprli bomo stran Apple Developer Program, se premaknili v razdelek Certificates, Identifiers & Profiles in nato v polje App IDs razdelka Identifiers. Ustvarimo nov App ID z imenom AmazingAppUITests in bundleID com.company.amazingappuitests.

Zdaj imamo možnost podpisovati naše teste z ločeno potrdilom, vendar ... Postopek sestavljanja bilta za testiranje vključuje sestavljanje same aplikacije in podajalnika testov. Posledično se soočamo s težavo podpiranja dveh bundle ID z enim provisioning profile. Na srečo obstaja preprosta in elegantna rešitev — Wildcard App ID. Ponovimo postopek ustvarjanja novega App ID, vendar namesto Explicit App ID izberemo Wildcard App ID, kot je prikazano na posnetku zaslona.

Na tej točki je delo z developer.apple.com končano, vendar okna brskalnika ne zapiramo. Gremo na spletno stran z dokumentacijo za Fastlane in preberemo o orodju Match od začetka do konca.

Bodite pozorni, da za uporabo tega orodja potrebujemo zasebni repozitorij in račun, ki ima dostop tako do Apple Developer Program kot do Github. Ustvarimo (če ga slučajno še nimamo) račun v obliki InfrastructureAccount@your.company.domain, izberemo močno geslo, ga registriramo v developer.apple.com in ga določimo za administratorja projekta. Nato omogočimo računu dostop do github repozitorija vaše družbe ter ustvarimo nov zasebni repozitorij z imenom, kot je AmazingAppMatch.

3. Nastavitev Fastlane in orodja match

Odprimo terminal, preidemo v mapo s projektom in inicializiramo fastlane, kot je navedeno v uradnem priročniku. Po vnosu ukaza

$ fastlane init

bomo pozvani, da izberemo razpoložljive konfiguracije uporabe. Izberemo četrto točko — ročno nastavitev projekta.

V projektu se je pojavila nova mapa fastlane, v kateri sta dva datoteka — Appfile in Fastfile. Na kratko — v Appfile shranjujemo službene podatke, v Fastfile pa opredeljujemo delovna mesta, v terminologiji Fastlane imenovana lanes. Priporočam, da preberete uradno dokumentacijo: jedan, dva.

Odprimo Appfile v najljubšem urejevalniku besedila in ga uredimo na naslednji način:

app_identifier "com.company.amazingapp"       # Bundle ID
apple_dev_portal_id "infrastructureaccount@your.company.domain"  # Ustvarjeni infrastrukturni račun, ki ima pravico do urejanja iOS projekta v Apple Developer Program.
team_id "LSDY3IFJAY9" # Vaš ID ekipe v Developer Portalu

Vrnimo se v terminal in po uradnem priročniku pričnemo nastavljati match.

$ fastlane match init
$ fastlane match development

Nato vnesemo zahtevane podatke — repozitorij, račun, geslo itd.

Pomembno: ob prvem zagonu orodje match zahteva vnos gesla za dešifriranje repozitorija. Zelo pomembno je shraniti to geslo, v fazi nastavitve CI strežnika nam bo prišlo prav!

V mapi fastlane se je pojavil nova datoteka — Matchfile. Odprimo jo v svojem najljubšem urejevalniku besedila in jo prilagodimo:

git_url("https://github.com/YourCompany/AmazingAppMatch") #Ustvarjeni zasebni repozitorij za shranjevanje potrdil in profilov.
type("development") # Privzeta vrsta, lahko je: appstore, adhoc, enterprise ali development
app_identifier("com.company.amazingapp")
username("infrastructureaccount@your.company.domain") # Vaš uporabniški račun infrastrukture Apple Developer Portala

Izpolnjujemo natančno na ta način, če želimo kasneje uporabljati match za podpis gradiv za objavo v Crashlytics in/ali AppStore, tj. za podpis bundle ID vašega aplikacije.

Toda, kot se spomnimo, smo za podpis testne različice ustvarili poseben Wildcard ID. Zato odpremo Fastfile in dodamo novo lane:

lane :testing_build_for_firebase do

    match(
      type: "development",
      readonly: true,
      app_identifier: "com.company.*",
      git_branch: "uitests"  # ustvarimo poseben bralnik za razvojni certifikat za podpis testne gradnje.
    )

end

Shránimo, vnesemo v terminal

fastlane testing_build_for_firebase

in vidimo, kako je fastlane ustvaril nov certifikat in ga shranil v repozitorij. Odlično!

Odprimo XCode. Zdaj imamo potrebni provisioning profile vrste Match Development com.company.*, ki ga je treba navesti v sekciji Provisioning profile za tarče AmazingApp in AmazingAppUITests.

Ostalo je, da dopišemo lane za zbiranje testov. Gremo v repozitorij projekta vtičnika za fastlane, ki poenostavi nastavitev izvoza v Firebase Test Lab in sledimo navodilom.

Kopiramo iz izvirnega primera, da bo naš lane testing_build_for_firebase na koncu izgledal tako:


 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

Za celovite informacije o nastavitvi fastlane v CircleCI priporočam, da preberete uradno dokumentacijo en, dva.

Ne pozabimo dodati nove naloge v naš 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     # posodobimo odvisnosti
     - run:
         name: install gcloud-sdk   # na mac računalnik je potrebno namestiti gcloud
         command: |
           ruby -e "$(curl -fsSL https:\/\/raw.githubusercontent.com\/Homebrew\/install\/master\/install)" \/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  # zaženemo lane za sestavljanje in pošiljanje v firebase

4. Kaj pa naš testni okolje? Nastavljamo Firebase.

Pristopimo k tistemu, zaradi česar je bil članek napisan.

Mogoče vaše aplikacije uporabljajo Firebase na brezplačnem načrtu, mogoče ga sploh ne uporabljajo. Temeljne razlike ni, ker lahko za potrebe testiranja ustvarimo poseben projekt z letom brezplačne uporabe (super, da?)

Prijavimo se v naš infrastrukturni račun (ali kateri koli drug, brez razlike) in gremo na stran Firebase konzole. Ustvarimo nov projekt z imenom AmazingAppUITests.

Pomembno: V prejšnjem koraku v Fastfile v lane firebase_test_lab_ios_xctest parameter gcp_project mora ustrezati imenu projekta.

Privzete nastavitve nas povsem zadovoljijo.

Ne zapiramo zavihka, pod istim računom se registriramo v Gcloud — to je prisilna ukrep, saj komunikacija z Firebase poteka preko vmesnika konzole gcloud.

Google ponuja 300 $ za leto, kar je v kontekstu izvajanja avtomatiziranih testov ekvivalentno letu brezplačne uporabe storitve. Vnesemo plačilne podatke, počakamo na testno zaračunavanje 1 $ in dobimo 300 $ na račun. Po preteku leta bo projekt samodejno prešel na brezplačni tarifni načrt, zato ni treba skrbeti za morebitno izgubo denarja.

Vrni se na zavihek s projektom Firebase in ga preklopi na tarifni načrt Blaze — zdaj imamo s čimer plačati v primeru prekoračitve limita.

V vmesniku gcloud izberemo naš projekt Firebase, izberemo točko glavnega menija „Katalog“ in dodamo Cloud Testing API ter Cloud Tools Result API.

Nato se premaknemo na točko menija „IAM in upravljanje“ -> Storitveni računi -> Ustvari storitveni račun. Dodelimo pravice za urejanje projekta.

Ustvarimo API ključ v formatu JSON.

Preneseni JSON bomo potrebovali nekoliko kasneje, zaenkrat pa bomo nastavitev Test Lab šteli za končano.

5. Nastavitev CircleCI

Postavlja se upravičeno vprašanje — kaj storiti z gesli? Zanesljivo shranjevanje naših gesel in drugih občutljivih podatkov nam bo omogočil mehanizem okolijskih spremenljivk naše gradbene naprave. V nastavitvah projekta CircleCI izberemo Spremenljivke okolja.

In uvedemo naslednje spremenljivke:

key: GOOGLE_APPLICATION_CREDENTIALS
value: vsebina json datoteke ključa storitvenega računa gcloud
key: MATCH_PASSWORD
value: geslo za dešifriranje github repozitorija s certifikati
key: FASTLANE_PASSWORD
value: geslo infrastrukturnega računa Apple Developer Portal

Shrani spremembe, ustvari PR in ga pošlji na pregled svojemu vodji ekipe.

Zaključki

Kot rezultat teh preprostih postopkov smo pridobili dober, stabilno delujoč sistem z možnostjo snemanja videa na zaslonu naprave v trenutku izvajanja testiranja. V testnem primeru sem navedel model naprave iPhone X, vendar kmetija ponuja bogat izbor kombinacij različnih modelov in različic iOS.

Drugi del bo namenjen korak za korakom nastavitvi Firebase Test Lab za Android projekt.

Izvor: habr.com