🥇Pagpapatakbo ng mga instrumental na pagsubok sa Firebase Test Lab. Bahagi 1: Proyekto sa iOS

Ang pangalan ko ay Dmitry, nagtatrabaho ako bilang isang tester sa kumpanya MEL Agham. Kamakailan lamang ay natapos ko ang pagharap sa isang medyo kamakailang tampok mula sa Firebase Test Lab — ibig sabihin, may instrumental na pagsubok ng mga iOS application gamit ang native testing framework na XCUITest.

Bago ito, sinubukan ko na ang Firebase Test Lab para sa Android at talagang nagustuhan ko ang lahat, kaya nagpasya akong subukang ilagay ang imprastraktura ng pagsubok sa iOS ng proyekto sa parehong katayuan. Marami akong kinailangan sa Google at hindi naging maayos ang lahat sa unang pagkakataon, kaya nagpasya akong magsulat ng tutorial na artikulo para sa mga nahihirapan pa rin.

Kaya, kung mayroon kang mga pagsubok sa UI sa isang proyekto sa iOS, maaari mo nang subukang patakbuhin ang mga ito sa mga totoong device ngayon, na ibinigay ng Good Corporation. Para sa mga interesado, maligayang pagdating sa pusa.

Sa kuwento, nagpasya akong bumuo sa ilang paunang data - isang pribadong repositoryo sa GitHub at ang CircleCI build system. Ang pangalan ng application ay AmazingApp, ang bundleID ay com.company.amazingapp. Ipinakita ko kaagad ang data na ito upang mabawasan ang kasunod na pagkalito.

Kung iba ang iyong ipinatupad na ilang solusyon sa iyong proyekto, ibahagi ang iyong karanasan sa mga komento.

1. Ang mga pagsubok mismo

Gumawa ng bagong sangay ng proyekto para sa mga pagsubok sa UI:

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

Buksan natin ang proyekto sa XCode at gumawa ng bagong Target na may mga pagsubok sa UI [XCode -> File -> New -> Target -> iOS Testing Bundle], na binibigyan ito ng self-explanatory name na AmazingAppUITests.

Pumunta sa Build Phases na seksyon ng ginawang Target at tingnan kung may Target na Dependencies - AmazingApp, sa Compile Sources - AmazingAppUITests.swift.

Ang isang magandang kasanayan ay ang paghiwalayin ang iba't ibang mga opsyon sa pagbuo sa magkakahiwalay na Mga Scheme. Gumagawa kami ng scheme para sa aming mga pagsubok sa UI [XCode -> Product -> Scheme -> New Scheme] at binibigyan ito ng parehong pangalan: AmazingAppUITests.

Dapat na kasama sa pagbuo ng ginawang scheme ang Target ng pangunahing application - Mga pagsubok sa AmazingApp at Target UI - AmazingAppUITests - tingnan ang screenshot

Susunod, gumawa kami ng bagong configuration ng build para sa mga pagsubok sa UI. Sa XCode, mag-click sa file ng proyekto at pumunta sa seksyong Impormasyon. Mag-click sa “+” at lumikha ng bagong configuration, halimbawa XCtest. Kakailanganin namin ito sa hinaharap upang maiwasan ang pagsasayaw gamit ang tamburin pagdating sa code signing.

Mayroong hindi bababa sa tatlong Target sa iyong proyekto: ang pangunahing aplikasyon, mga pagsubok sa yunit (pagkatapos ng lahat, mayroon sila, tama ba?) at ang mga pagsubok sa Target na UI na aming ginawa.

Pumunta sa Target AmazingApp, Build Settings tab, Code Signing Identity section. Para sa XCtest configuration, piliin ang iOS Developer. Sa seksyong Code Signing Style, piliin ang Manwal. Hindi pa kami nakakabuo ng provisioning profile, ngunit tiyak na babalikan namin ito mamaya.

Para sa Target AmazingAppUITests ginagawa namin ang parehong, ngunit sa column na Product Bundle Identifier ay ipinapasok namin ang com.company.amazingappuitests.

2. Pagse-set up ng isang proyekto sa Apple Developer Program

Pumunta sa page ng Apple Developer Program, pumunta sa seksyong Mga Certificate, Identifier, at Profile at pagkatapos ay sa column na Mga App ID ng item na Mga Identifier. Gumawa ng bagong App ID na tinatawag na AmazingAppUITests at bundleID com.company.amazingappuitests.

Ngayon ay mayroon kaming pagkakataon na lagdaan ang aming mga pagsusulit gamit ang isang hiwalay na sertipiko, ngunit... Ang pamamaraan para sa pag-assemble ng isang build para sa pagsubok ay nagsasangkot ng pag-assemble ng application mismo at pag-assemble ng test runner. Alinsunod dito, nahaharap kami sa problema sa pagpirma ng dalawang bundle ID na may isang provisioning profile. Sa kabutihang palad, mayroong isang simple at eleganteng solusyon - Wildcard App ID. Uulitin namin ang pamamaraan para sa paggawa ng bagong App ID, ngunit sa halip na tahasang App ID, piliin ang Wildcard App ID tulad ng sa screenshot.

Sa puntong ito, tapos na kaming magtrabaho kasama ang developer.apple.com, ngunit hindi namin babawasan ang window ng browser. Pumunta tayo sa Site ng dokumentasyon ng Fastlane at basahin ang tungkol sa Match utility mula pabalat hanggang pabalat.

Napansin ng isang matulungin na mambabasa na upang magamit ang utility na ito kakailanganin namin ang isang pribadong repositoryo at isang account na may access sa parehong Apple Developer Program at Github. Lumilikha kami (kung biglang walang ganoong bagay) ng isang account ng form [protektado ng email], makabuo ng malakas na password, irehistro ito sa developer.apple.com, at italaga ito bilang administrator ng proyekto. Susunod, binibigyan namin ang account ng access sa github repository ng iyong kumpanya at gumawa ng bagong pribadong repository na may pangalan tulad ng AmazingAppMatch.

3. Pagse-set up ng Fastlane at ang match utility

Magbukas ng terminal, pumunta sa folder na may proyekto at simulan ang fastlane gaya ng ipinahiwatig sa opisyal na manwal. Matapos ipasok ang utos

$ fastlane init

Ipo-prompt kang pumili ng mga magagamit na configuration ng paggamit. Piliin ang ikaapat na opsyon - manu-manong pag-setup ng proyekto.

Ang proyekto ay may bagong direktoryo na fastlane, na naglalaman ng dalawang file - Appfile at Fastfile. Sa madaling sabi, nag-iimbak kami ng data ng serbisyo sa Appfile, at nagsusulat ng mga trabaho sa Fastfile, na tinatawag na mga lane sa terminolohiya ng Fastlane. Inirerekomenda kong basahin ang opisyal na dokumentasyon: oras, два.

Buksan ang Appfile sa iyong paboritong text editor at dalhin ito sa sumusunod na form:

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

Bumalik kami sa terminal at ayon sa opisyal na manwal nagsisimula kaming i-configure ang tugma.

$ fastlane match init
$ fastlane match development

Susunod, ipasok ang hiniling na data - imbakan, account, password, atbp.

Mahalaga: Kapag una mong inilunsad ang match utility, hihilingin sa iyong maglagay ng password para i-decrypt ang repositoryo. Napakahalaga na i-save ang password na ito; kakailanganin namin ito kapag nagse-set up ng CI server!

May lumabas na bagong file sa fastlane folder - Matchfile. Buksan ito sa iyong paboritong text editor at ipakita ito tulad nito:

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

Punan namin ito nang eksakto sa ganitong paraan kung gusto naming gumamit ng tugma sa hinaharap upang mag-sign ng mga build para ipakita sa Crashlytics at/o AppStore, iyon ay, upang lagdaan ang bundle ID ng iyong application.

Ngunit, gaya ng natatandaan namin, gumawa kami ng espesyal na Wildcard ID para lagdaan ang test build. Samakatuwid, buksan ang Fastfile at magpasok ng bagong lane:

lane :testing_build_for_firebase do

    match(
      type: "development",
      readonly: true,
      app_identifier: "com.company.*",
      git_branch: "uitests"  # создаем отдельный бранч для development сертификата для подписи тестовой сборки.
    )

end

I-save at pumasok sa terminal

fastlane testing_build_for_firebase

at nakita natin kung paano gumawa ng bagong certificate ang fastlane at inilagay ito sa repository. Malaki!

Buksan ang XCode. Ngayon ay mayroon na kaming kinakailangang provisioning profile ng form na Match Development com.company.*, na dapat na tukuyin sa seksyon ng Provisioning profile para sa mga target ng AmazingApp at AmazingAppUITests.

Ito ay nananatiling magdagdag ng lane para sa pag-assemble ng mga pagsubok. Pumunta tayo sa imbakan isang proyekto ng plugin para sa fastlane na nagpapadali sa pag-set up ng pag-export sa Firebase Test Lab at sundin ang mga tagubilin.

I-copy-paste natin mula sa orihinal na halimbawa upang ang ating lane testing_build_for_firebase ay magmumula sa ganito:


 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

Para sa kumpletong impormasyon tungkol sa pag-set up ng fastlane sa CircleCI, inirerekomenda kong basahin ang opisyal na dokumentasyon beses, два.

Huwag kalimutang magdagdag ng bagong gawain sa aming 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. Paano ang aming test bench? Pagse-set up ng Firebase.

Bumaba tayo sa kung para saan isinulat ang artikulo.

Marahil ay gumagamit ang iyong app ng Firebase sa isang libreng plano, o marahil ay hindi talaga. Walang ganap na pagkakaiba, dahil para sa mga pangangailangan sa pagsubok maaari tayong lumikha ng isang hiwalay na proyekto na may isang taon ng libreng paggamit (astig, tama?)

Nag-log in kami sa aming account sa imprastraktura (o anumang iba pa, hindi mahalaga), at pumunta sa page ng Firebase console. Gumawa ng bagong proyekto na pinangalanang AmazingAppUITests.

Mahalaga: Sa nakaraang hakbang sa Fastfile sa lane firebase_test_lab_ios_xctest dapat tumugma ang parameter ng gcp_project sa pangalan ng proyekto.

Ang mga default na setting ay angkop sa amin.

Huwag isara ang tab, magparehistro sa ilalim ng parehong account sa Gcloud - ito ay isang kinakailangang panukala, dahil ang pakikipag-ugnayan sa Firebase ay nangyayari gamit ang interface ng gcloud console.

Nagbibigay ang Google ng $300 para sa isang taon, na sa konteksto ng pagsasagawa ng mga autotest ay katumbas ng isang taon ng libreng paggamit ng serbisyo. Ilalagay namin ang iyong impormasyon sa pagbabayad, hintayin ang test debit na $1 at tumanggap ng $300 sa iyong account. Pagkatapos ng isang taon, ang proyekto ay awtomatikong ililipat sa isang libreng plano ng taripa, kaya hindi na kailangang mag-alala tungkol sa posibleng pagkawala ng pera.

Bumalik tayo sa tab kasama ang proyekto ng Firebase at ilipat ito sa plano ng taripa ng Blaze - mayroon na tayong babayaran kung lumampas sa limitasyon.

Sa interface ng gcloud, piliin ang aming proyekto sa Firebase, piliin ang pangunahing menu item na “Directory” at idagdag ang Cloud Testing API at Cloud Tools Result API.

Pagkatapos ay pumunta sa menu item na "IAM at pangangasiwa" -> Mga account ng serbisyo -> Lumikha ng account ng serbisyo. Nagbibigay kami ng mga karapatang i-edit ang proyekto.

Gumawa ng API key sa JSON format

Kakailanganin namin ang na-download na JSON sa ibang pagkakataon, ngunit sa ngayon ay isasaalang-alang namin ang pag-setup ng Test Lab na kumpleto.

5. Pagse-set up ng CircleCI

Ang isang makatwirang tanong ay lumitaw - ano ang gagawin sa mga password? Ang mekanismo ng variable ng kapaligiran ng aming build machine ay makakatulong sa aming ligtas na iimbak ang aming mga password at iba pang sensitibong data. Sa mga setting ng proyekto ng CircleCI, piliin ang Environment Variables

At i-set up ang mga sumusunod na variable:

key: GOOGLE_APPLICATION_CREDENTIALS
value: mga nilalaman ng json file ng gcloud service account key
susi: MATCH_PASSWORD
value: password para sa pag-decrypting ng github repository na may mga certificate
key: FASTLANE_PASSWORD
halaga: password ng account sa imprastraktura ng Apple Developer Portal

Ise-save namin ang mga pagbabago, gumawa ng PR at ipadala ito sa aming team lead para sa pagsusuri.

Mga resulta ng

Bilang resulta ng mga simpleng manipulasyong ito, nakatanggap kami ng isang mahusay, matatag na stand na may kakayahang mag-record ng video sa screen ng device sa oras ng pagsubok. Sa halimbawa ng pagsubok, tinukoy ko ang modelo ng iPhone X device, ngunit nagbibigay ang farm ng maraming seleksyon mula sa kumbinasyon ng iba't ibang modelo at bersyon ng iOS.

Ang ikalawang bahagi ay ilalaan sa sunud-sunod na pag-setup ng Firebase Test Lab para sa isang proyekto sa Android.

Pinagmulan: www.habr.com

Nagpapatakbo kami ng mga instrumental na pagsubok sa Firebase Test Lab. Bahagi 1: Proyekto sa iOS