Käivitame instrumentaalsed testid Firebase Test Lab'is. Osa 1: iOS projekt

Minu nimi on Dmitri, töötan testijana ettevõttes MEL Science. Hiljuti lõpetasin suhteliselt uue funktsiooni uurimise, mille kohta Firebase Test Lab — nimelt, iOS rakenduste instrumentaalsest testimisest kasutades natiivset testimisraamistiku XCUITest.

Enne seda olin juba proovinud Firebase Test Lab'i Androidi jaoks ja mulle meeldis see väga, seega otsustasin proovida iOS projekti testimisstruktuuri samadele rööbastele seadistada. Pidin palju guugeldama ja mitte kõik ei õnnestunud esimesel korral, seetõttu otsustasin kirjutada õpetusartikli neile, kes seisavad selle ees.

Seega, kui teil on UI testid iOS projektis, siis saate juba täna proovida neid käivitada reaalsetel seadmetel, mida lahkelt pakub Heategevuskorporatsioon. Huvi tundnud — olete teretulnud allolevasse osa.

Jutustuses otsustasin lähtuda teatud algandmetest — privaatne reposteetory GitHub'is ja ehitussüsteem CircleCI. Rakenduse nimi on AmazingApp, bundleID — com.company.amazingapp. Toon need andmed kohe välja, et vähendada hilisemaid segadusi.

Kui olete oma projektis teatud lahendusi teisiti rakendanud, jagage oma kogemusi kommentaarides.

1. Testid

Loome uue projekti haru UI testide jaoks:

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

Avame projekti XCode'is ja loome uue sihtmärgi (Target) UI testide jaoks [XCode -> File -> New -> Target -> iOS Testing Bundle], anname sellele kõlava nime AmazingAppUITests.

Mineme loodud sihtmärgi Build Phases sektsiooni ja kontrollime, kas Target Dependencies - AmazingApp, Compile Sources - AmazingAppUITests.swift on olemas.

Heaks tavaks on erinevate ehituste variantide eraldamine eraldi skeemidesse (Schemes). Loome skeemi meie UI testide jaoks [XCode -> Product -> Scheme -> New Scheme] ja anname sellele sama nime: AmazingAppUITests.

Loodud skeemi build peab sisaldama põhirakenduse Targetit - AmazingApp ja UI testide Targetit - AmazingAppUITests - vt ekraanipilte.

Seejärel loome UI testide jaoks uue ehituse konfiguratsiooni. XCode'is klõpsame projekti failil, läheme Info sektsiooni. Klõpsame " + " ja loome uue konfiguratsiooni, näiteks XCtest. See on vajalik edaspidi, et vältida segadust, kui jõuame code signing'uni.

Teie projektis on vähemalt kolm Targetit: põhirakendus, üksuse testid (need on ju olemas, eks?) ja meie poolt loodud Target UI testide jaoks.

Siseneme Target AmazingApp, vahekaart Build Settings, jaotis Code Signing Identity. Konfiguratsiooni jaoks XCtest valime iOS Developer. Jaotises Code Signing Style valime Manual. Provisioning profile'i me veel ei genereerinud, kuid naaseme sellele hiljem kindlasti.

Target AmazingAppUITests jaoks teeme sama, kuid väljale Product Bundle Identifier kirjutame com.company.amazingappuitests.

2. Projekti seadistamine Apple Developer Programis

Siseneme Apple Developer Programi lehele, läheme jaotisse Certificates, Identifiers & Profiles ja seejärel Identifiers punkti all App IDs. Loome uue App ID nimega AmazingAppUITests ja bundleID com.company.amazingappuitests.

Nüüd on meil võimalus allkirjastada meie testid eraldi sertifikaadiga, kuid… Testimise build'i koostamise protseduur tähendab rakenduse enda ja testide käitaja build'i koostamist. Seetõttu seisame silmitsi kahe bundle ID allkirjastamise probleemiga ühe provisioning profile'iga. Õnneks on olemas lihtne ja elegantne lahendus — Wildcard App ID. Korrake uue App ID loomise protseduuri, kuid valige Explicit App ID asemel Wildcard App ID nagu ekraanipildil.

Selles etapis on töö developer.apple.com lõpetatud, kuid me ei sulge brauseri akent. Liigume Fastlane'i dokumentatsiooni lehele ja loeme utiliidist Match kõik sügavale sisse.

Hoolikas lugeja on märganud, et selle utiliidi kasutamiseks on meil vaja privaatset hoidlat ja kontot, mis on ligipääsudega nii Apple Developer Programile kui ka Githubile. Loome (kui sellist pole) konto vormis InfrastructureAccount@your.company.domain, mõtleme välja tugeva parooli, registreerime selle developer.apple.com-is ja määrame projekti administraatoriks. Edasi, anname kontole ligipääsu teie ettevõtte githubi hoidlasse ja loome uue privaatse hoidla nimega AmazingAppMatch.

3. Fastlane'i ja utiliidi match seadistamine

Avame terminali, liigume projekti kausta ja initsialiseerime fastlane'i nagu on toodud ametlikus juhendis. Pärast käsu sisestamist

$ fastlane init

pakutakse valida olemasolevaid konfiguratsioone. Valime neljanda punkti — projekti käsitsi seadistamine.

Projektis on ilmunud uus kaust fastlane, kus asuvad kaks faili — Appfile ja Fastfile. Ühesõnaga — Appfile's hoiame teenuste andmeid ja Fastfile's määratleme töid, mida Fastlane'i terminoloogias nimetatakse lanes. Soovitan lugeda ametlikku dokumentatsiooni: kord, kaks.

Avame Appfile oma lemmik tekstiredaktoriga ja viime selle järgmisse vormingusse:

app_identifier "com.company.amazingapp"       # Paketi ID
apple_dev_portal_id "infrastructureaccount@your.company.domain"  # Loodud infrastruktuuri konto, millel on õigus redigeerida iOS projekti Apple'i arendaja programmis.
team_id "LSDY3IFJAY9" # Teie arendaja portaali meeskonna ID

Naaseme terminali ja vastavalt ametlikule juhendile alustame match'i seadistamist.

$ fastlane match init
$ fastlane match development

Seejärel sisestame nõutud andmed — reposiit, konto, parool jne.

Oluline: esimese käivitamise ajal palub utiliit match sisestada parooli reposiidi dekrüpteerimiseks. On väga oluline see parool säilitada, see tuleb meil kasuks CI serveri seadistamise etapis!

Kaas fastlane'is ilmus uus fail — Matchfile. Avame oma lemmik tekstiredaktoriga ja viime selle järgmisse vormingusse:

git_url("https://github.com/YourCompany/AmazingAppMatch") #Privaatne repo, mille eesmärk on hoida sertifikaate ja profiile.
type("development") # Vaikimisi tüüp: appstore, adhoc, enterprise või development
app_identifier("com.company.amazingapp")
username("infrastructureaccount@your.company.domain") # Teie infrastruktuuri konto Apple Developer Portali kasutajanimi

Täidame selle just niimoodi, kui tahame hiljem kasutada match'i versioonide allkirjastamiseks, mis on mõeldud Crashlytics ja/või AppStore'i jaoks, st teie rakenduse bundle ID allkirjastamiseks.

Aga nagu me teame, oleme testversiooni allkirjastamiseks loonud spetsiaalse Wildcard ID. Seega avame Fastfile'i ja lisame uue lane:

lane :testing_build_for_firebase do

    match(
      type: "development",
      readonly: true,
      app_identifier: "com.company.*",
      git_branch: "uitests"  # loome eraldi haru development sertifikaadi jaoks testversiooni allkirjastamiseks.
    )

end

Salvestame, sisestame terminali

fastlane testing_build_for_firebase

ja näeme, kuidas fastlane lõi uue sertifikaadi ja salvestas selle repo. Suurepärane!

Avame XCode'i. Nüüd on meil vajalik provisioning profile, Match Development com.company.*, mille peame määrama AmazingApp ja AmazingAppUITests sihtmärkide Provisioning profile sektsioonis.

Peab nüüd lisama lane testide koostamiseks. Liigume repo fastlane'i plugina projekt, mis hõlbustab Firebase Test Labi eksportimise seadistamist ja järgib juhiseid.

Kopeerime algsest näitest, et meie lane testing_build_for_firebase lõpuks välja näeks:

 lane :testing_build_for_firebase do

    match(
      type: "development",
      readonly: true,
      app_identifier: "com.company.*",
      git_branch: "uitests"
    )

    scan(
      scheme: 'AmazingAppUITests',      # UI testimise skeem
      clean: true,                        # Soovitatav: see tagab, et ehitus ei sisaldaks tarbetuid faile
      skip_detect_devices: true,          # Nõutav
      build_for_testing: true,            # Nõutav
      sdk: 'iphoneos',                    # Nõutav
      should_zip_build_products: true,     # Peab olema tõene, et seada õige formaat Firebase Test Lab'i jaoks
    )

    firebase_test_lab_ios_xctest(
      gcp_project: 'AmazingAppUITests', # Teie Google Cloud'i projekti nimi (naaseme selle rea juurde hiljem)
      devices: [                          # Seade(d), millega teste käitada
        {
          ios_model_id: 'iphonex',        # Seadmeme mudeli ID, vaata gcloud käsku ülal
          ios_version_id: '12.0',         # iOS versiooni ID, vaata gcloud käsku ülal
          locale: 'en_US',                # Valikuline: vaikimisi en_US, kui pole seadistatud
          orientation: 'portrait'         # Valikuline: vaikimisi portrait, kui pole seadistatud
        }
      ]
    )

  end

Fastlane'i seadistamise kohta CircleCI-s soovitan lugeda ametlikku dokumentatsiooni. üks, kaks.

Ärge unustage täiendama meie config.yml uut ülesannet:

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     # uuendame sõltuvused
     - run:
         name: install gcloud-sdk   # maci masinale tuleb gcloud installida
         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  # käivitame lane'i koostamiseks ja saadmiseks firebase'i

4. Aga kuidas meie testimisplatvorm? Seame üles Firebase.

Alustame tegelikult sellest, milleks artikkel kirjutati.

Võib-olla kasutab teie rakendus Firebase'i tasuta plaanil, võib-olla ei kasuta seda üldse. Olulist vahet ei ole, kuna testimise vajadusteks võime luua eraldi projekti, millel on aasta tasuta kasutust (pole paha, eks?)

Logime sisse oma infrastruktuuri kontole (või mõnele muule, pole vahet) ja suundume Firebase'i konsooli lehele. Loome uue projekti nimega AmazingAppUITests.

Oluline: Eelmises sammus Fastfile'is lane firebase_test_lab_ios_xctest parameeter gcp_project peab vastama projekti nimele.

Meie vaikeseaded sobivad meile täielikult.

Ärge sulgege vahekaart, registreerige sama konto alla Gcloud — see on sunnitud meede, kuna suhtlemine Firebase'iga toimub gcloudi konsooli liidese kaudu.

Google annab 300$ aastas, mis autotehtuste kontekstis vastab aasta tasuta teenuse kasutusele. Sisestame makseandmed, ootame testimistasu 1$ ning saame kontole 300$. Aasta möödudes projekti automaatselt tasuta paketile viimine, seega ei pea muretsema rahakaotuse pärast.

Naaseme Firebase projekti vahekaardile ja viime selle Blaze paketile — nüüd on meil raha, et ületada limiite.

Gcloudi liideses valime meie Firebase projekti, valime peamenüüst „Kataloog” ja lisame Cloud Testing API ja Cloud Tools Result API.

Seejärel liigume menüüsse „IAM ja haldamine” -> Teenusekontod -> Loo teenusekonto. Anname projekti redigeerimisõigused.

Loome JSON-formaadis API võtme

Allalaaditud JSON tuleb meil hiljem, kuid seni loeme Test Labi seadistamise lõpetatuks.

5. CircleCI seadistamine

Tuleb õigustatud küsimus — mida teha paroolidega? Meie paroolide ja teiste tundlike andmete turvaliseks hoidmiseks aitab meid meie ehitusmasina keskkonnamuutujate mehhanism. Projekti CircleCI seadetes valime Keskkonnamuutujad

Ja loome järgmised muutujad:

• võti: GOOGLE_APPLICATION_CREDENTIALS
  väärtus: gcloud teenuse konto võtme JSON faili sisu
• võti: MATCH_PASSWORD
  väärtus: parool GitHubi sertifikaatide hoidmise repositorio dekodeerimiseks
• võti: FASTLANE_PASSWORD
  väärtus: Apple Developer Portali infrastruktuurkontot parool

Salvestame muudatused, loome PR ja saadame ülevaatamiseks oma tiimijuhile.

Kokkuvõte

Tulemusena nende lihtsate manipuleerimiste täitmine saime hea, stabiilselt töötava seisu ekraanivideote salvestamise võimalusega seadme testimise käigus. Testnäites märkisin seadme mudeliks iPhone X, kuid farm pakub laia valikut erinevate mudelite ja iOS-i versioonide kombinatsioone.

Teine osa keskendub samm-sammult Firebase Test Labi seadistamisele Android projekti jaoks.

Allikas: habr.com