Kasutame instrumentaalteste Firebase Test Labis. Osa 1: iOS projekt

Minu nimi on Dmitri, töötan testijana ettevõttes MEL Science. Alles hiljuti lõpetasin ma tutvumise suhteliselt uue funktsiooniga Firebase Test Lab — nimelt, iOS-rakenduste instrumentaalsete testide läbiviimine natiivse testimisraamistiku XCUITest abil.

Enne seda proovisin Firebase Test Labi Androidi jaoks ja mulle meeldis see väga, nii et otsustasin proovida iOS projekti testimisstruktuuri sarnastele radadele seada. Olin sunnitud palju Google'isse minema ja mitte kõik ei õnnestunud esimesel katsel, seetõttu otsustasin kirjutada artikli-tutvustuse neile, kellel see veel ees.

Nii et kui teil on iOS projektis UI testid, saate juba täna proovida neid käivitada reaalsetel seadmetel, mille on lahkelt pakkunud Heategevuskorporatsioon. Huvi korral - tulge edasi.

Otsustasin jutustamise aluseks võtta mõned algandmed - privaatne hoidla GitHubis ja CircleCI ehitussüsteem. Rakenduse nimi on AmazingApp, bundleID — com.company.amazingapp. Too andmed välja kohe, et vähendada hilisemaid segadusi.

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

1. Testid ise

Loome projekti uue haru UI testide jaoks:

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

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

Liigume loodud Eesmärgi Build Phase'i sektsiooni ja kontrollime, kas olemas on Target Dependencies — AmazingApp, Compile Sources — AmazingAppUITests.swift.

Hea praktika on erinevate kogumiste eraldamine eraldi Skeemidesse (Schemes). Loome skeemi meie UI testide jaoks [XCode -> Product -> Scheme -> New Scheme] ja anname sellele sama nime: AmazingAppUITests.

Loodud skeemi kogumine peaks sisaldama põhiraamatulu Targetit — AmazingApp ja Targetit UI testide — AmazingAppUITests — vt. ekraanipilt.

Edasi, loome UI testide jaoks uue kogumise konfiguratsiooni. XCode'is klõpsame projekti failil, liigume sektsiooni Info. Klõpsame “+” ja loome uue konfiguratsiooni, näiteks XCtest. See tuleb meil hiljem kasuks, et vältida keerulisi olukordi, kui jõuame koodiallkirjastamiseni.

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

Sisenege Target AmazingApp, vahekaart Build Settings, jaotises Code Signing Identity. XCtest konfiguratsiooni jaoks valige iOS Developer. Jaotises Code Signing Style valige Manual. Provisioning profile'i me veel ei ole genereerinud, kuid natuke hiljem tagasime sellele kindlasti.

Target AmazingAppUITests jaoks teeme sama, kuid toote paketitunnuse väljale kirjutame com.company.amazingappuitests.

2. Projekti seadistamine Apple Developer Program'is

Siseneme Apple Developer Program'i lehele, liigume jaotisse Certificates, Identifiers & Profiles ja seejärel punktis Identifiers väljale App IDs. Loome uue App ID nimega AmazingAppUITests ja bundleID-ga com.company.amazingappuitests.

Nüüd on meil võimalus allkirjastada meie testid eraldi sertifikaadiga, kuid... Testimise jaoks mõeldud build-protsess eeldab rakenduse enda ja testide käivitaja build'i loomist. Seega seisame silmitsi probleemiga allkirjastada kahte bundle ID-d ühe provisioning profile'iga. Õnneks on olemas lihtne ja elegantne lahendus — Wildcard App ID. Kordame uue App ID loomise protsessi, kuid Explicit App ID asemel valime Wildcard App ID nagu ekraanipildil.

Selle etapi jooksul on töö developer.apple.com-is lõpetatud, kuid sulgege brauseri aken me ei kavatse. Liigume Fastlane dokumentatsiooni lehele ja loeme Match utiliidist alates lõpuni.

Hoolsad lugejad on märganud, et selle utiliidi kasutamiseks on vaja privaatset repot ning kontot, mis omab juurdepääsu nii Apple Developer Program'ile kui ka Github'ile. Loome (kui seda veel ei ole) konto vormis InfrastructureAccount@your.company.domain, mõtleme välja tugeva parooli, registreerime selle developer.apple.com-is ning määrame projekti halduriks. Seejärel anname kontole juurdepääsu teie ettevõtte github repole ja loome uue privaatse repoga nimega AmazingAppMatch.

3. Fastlane'i ja match utiliidi seadistamine

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

$ fastlane init

pakutakse valida saadavalolevaid kasutuskonfiguratsioone. Valime neljanda punkti — projekti käsitsi seadistamine.

Projektis on tekkinud uus kaust fastlane, milles asuvad kaks faili — Appfile ja Fastfile. Lühidalt öeldes — Appfile'is hoiame teenuseandmeid ja Fastfile'is kirjutame ülesandeid, Fastlane'i terminoloogias lanes. Soovitan lugeda ametlikku dokumentatsiooni: üks, kaks.

Avame Appfile oma lemmikteksti redigeerijas ja viime selle järgmisse vormingusse:

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

Tagasi terminali ja hakkame ametliku juhendi järgi seadistama match.

$ fastlane match init
$ fastlane match development

Sisestame küsitud andmed — repositoorium, konto, parool jne.

Oluline: esmakordsel käivitamisel küsib utiliit match parooli repositooriumi dekrüpteerimiseks. On väga oluline see parool salvestada, see on vajalik CI serveri seadistamisetapis!

Fastlane kaustas on tekkinud uus fail — Matchfile. Avame selle oma lemmik tekstiredaktoris ja viime selle järgmisesse vormi:

git_url("https://github.com/YourCompany/AmazingAppMatch") # Loodud privaatne repositoorium, et salvestada sertifikaate ja profiile.
type("development") # Vaikimisi tüüp, võib olla: appstore, adhoc, enterprise või development
app_identifier("com.company.amazingapp")
username("infrastructureaccount@your.company.domain") # Teie infrastruktuuri konto Apple Developer Portaali kasutajanimi

Täidame selle just nii, kui soovime hiljem kasutada match'i rakenduste allkirjastamiseks Crashlytics'isse ja/või AppStore'i, st teie rakenduse bundli ID allkirjastamiseks.

Kuid, nagu me mäletame, lõime testversiooni allkirjastamiseks spetsiaalse Wildcard ID. Seega avame Fastfile'i ja kirjutame uue lane'i:

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 repositooriumisse. Suurepärane!

Avame XCode'i. Nüüd on meil vajalik provisions profiil Match Development com.company.*, mida tuleb määrata AmazingApp ja AmazingAppUITests sihtkohtades Provisions profiili sektsioonis.

Jääb veel kirjutada lane testide koostamiseks. Liigume hoidla fastlane'i pistikprogrammi projekti, mis lihtsustab eksporti seadistamist Firebase Test Lab'isse ja järgime instruktsioonide.

Kopeerime algses näites, et meie lane testing_build_for_firebase välja näeks selline:

 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

Kogu teabe saamiseks fastlane'i seadistamise kohta CircleCI-s soovitan tutvuda ametliku dokumentatsiooniga. üks, kaks.

Ärge unustage täiendada meie config.yml uut ülesande:

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õltuvusi
     - run:
         name: install gcloud-sdk   # mac masin vajab gcloudi installimist
         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 ehitamise ja saatmise firebase'i

4. Aga mis meie testimisstandiga? Seadistame Firebase'i.

Asume tegelikult selle juurde, miks artikkel kirjutati.

Võimalik, et teie rakendus kasutab Firebase'i tasuta plaanil, või võib-olla ei kasuta see üldse. Põhimõtteliselt ei ole seal suurt vahet, sest testimise vajadustele saame luua eraldi projekti aasta tasuta kasutamiseks (äge, 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.

Vaikeseaded sobivad meile ideaalselt.

Ärge sulgege vahekaart, samade kontoandmetega registreeruge Gcloud — see on hädavajalik, kuna suhtleme Firebase'iga gcloudi konsooli liidese kaudu.

Google kingib 300$ aastas, mis on autotehnika testimise kontekstis võrreldav aasta tasuta teenuse kasutamisega. Sisestame makseandmed, ootame 1$ testimist ja saame kontole 300$. Aasta möödudes kantakse projekt automaatselt tasuta plaanile, seega ei pea raha kaotamise pärast muretsema.

Naaseme Firebase projekti vahelehele ja vahetame selle Blaze plaani peale — nüüd on meil, millega tasuda, juhul kui piirangud ületatakse.

gcloud liideses valime oma Firebase projekti, menüüs valime punkti "Kataloog" ja lisame Cloud Testing API ning Cloud Tools Result API.

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

Loome API võtme JSON formaadis

Laaditud JSON-i vajame hiljem, kuid hetkel loeme Test Labi seadistuse lõpetatuks.

5. CircleCI seadistamine

Küsimus tekib — mis teha paroolidega? Meie paroolide ja teiste tundlike andmete usaldusväärseks salvestamiseks aitab ehitusmasina keskkonnamuutujad. CircleCI projekti seadetes valime Keskkonnamuutujad.

Ja loome järgmised muutujad:

• key: GOOGLE_APPLICATION_CREDENTIALS
  value: gcloud teenusekonto võtme JSON faili sisu
• key: MATCH_PASSWORD
  value: parool githubi sertifikaatide hoidmise dešifreerimiseks
• key: FASTLANE_PASSWORD
  value: Apple Developer Portali infrastruktuuri konto parool

Salvestame muudatused, loome PR ja saadame review'le oma tiimijuhile.

Summary

Tulemuseks on see, et nende lihtsate toimingute kaudu saime head, stabiilselt töötavat seadet, millega on võimalik ekraanil olevat videovõtet salvestada testimise ajal. Testnäites määrasin seadme mudeliks iPhone X, kuid farm pakub rikkalikku valikut erinevate mudelite ja iOS versioonide kombinatsioone.

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

Allikas: habr.com