Nazywam się Dmitry, pracuję jako tester w firmie . Ostatnio skończyłem zajmować się relatywnie świeżą funkcją z - mianowicie z testowaniem instrumentalnym aplikacji iOS przy użyciu natywnego środowiska testowego XCUITest.
Wcześniej wypróbowałem już Firebase Test Lab dla Androida i wszystko bardzo mi się podobało, więc postanowiłem spróbować umieścić infrastrukturę testową projektu iOS na tych samych szynach. Musiałem dużo googlować i nie wszystko wyszło za pierwszym razem, więc postanowiłem napisać artykuł instruktażowy dla tych, którzy jeszcze muszą to zrobić.
Jeśli więc masz testy interfejsu użytkownika w projekcie na iOS, możesz już dziś spróbować uruchomić je na prawdziwych urządzeniach, dzięki uprzejmości Good Corporation. Zainteresowani - zapraszamy pod kat.
W historii zdecydowałem się oprzeć na danych źródłowych - prywatnym repozytorium na GitHubie i systemie kompilacji CircleCI. Nazwa aplikacji to AmazingApp, identyfikator pakietu to com.company.amazingapp. Cytuję te dane od razu, aby uniknąć późniejszych nieporozumień.
Jeśli w swoim projekcie zaimplementowałeś pewne rozwiązania w inny sposób, podziel się swoimi doświadczeniami w komentarzach.
1. Same testy
Utwórz nową gałąź projektu do testów interfejsu użytkownika:
$ git checkout develop
$ git pull
$ git checkout -b “feature/add-ui-tests”
Otwórzmy projekt w XCode i stwórzmy nowy Target z testami UI [XCode -> File -> New -> Target -> iOS Testing Bundle], nadaj mu wymowną nazwę AmazingAppUITests.
Przejdź do sekcji fazy kompilacji utworzonego elementu docelowego i sprawdź zależności docelowe — AmazingApp, w źródłach kompilacji — AmazingAppUITests.swift.
Dobrą praktyką jest rozdzielenie różnych opcji kompilacji na osobne Schematy. Tworzymy schemat dla naszych testów interfejsu użytkownika [XCode -> Produkt -> Schemat -> Nowy schemat] i nadajemy mu tę samą nazwę: AmazingAppUITests.
Kompilacja utworzonego schematu powinna zawierać Target aplikacji głównej - testy AmazingApp i Target UI - AmazingAppUITests - patrz zrzut ekranu
Następnie tworzymy nową konfigurację kompilacji na potrzeby testów interfejsu użytkownika. W Xcode kliknij plik projektu, przejdź do sekcji Informacje. Kliknij na „+” i utwórz nową konfigurację, np. XCtest. Będziemy tego potrzebować w przyszłości, aby uniknąć tańca z tamburynem podczas podpisywania kodu.
W Twoim projekcie są co najmniej trzy Targety: główna aplikacja, testy jednostkowe (jest ich trochę, prawda?) oraz Target UI stworzonych przez nas testów.
Przejdź do Target AmazingApp, zakładki Build Settings, sekcji Code Signing Tożsamość. W przypadku konfiguracji XCtest wybierz opcję Deweloper iOS. W sekcji Styl podpisywania kodu wybierz opcję Ręcznie. Nie wygenerowaliśmy jeszcze profilu prowizyjnego, ale na pewno wrócimy do tego nieco później.
W przypadku Target AmazingAppUITests robimy to samo, ale w kolumnie Product Bundle Identifier wpisujemy com.company.amazingappuitests.
2. Zakładanie projektu w programie Apple Developer Program
Wchodzimy na stronę Apple Developer Program, przechodzimy do sekcji Certyfikaty, identyfikatory i profile, a następnie do kolumny Identyfikatory aplikacji elementu Identyfikatory. Utwórz nowy identyfikator aplikacji o nazwie AmazingAppUITests i packageID com.company.amazingappuitests.
Teraz mamy możliwość podpisywania naszych testów osobnym certyfikatem, ale... Procedura kompilacji do testów polega na zbudowaniu samej aplikacji i zbudowaniu modułu testowego. W związku z tym mamy do czynienia z problemem podpisania dwóch identyfikatorów pakietów za pomocą jednego profilu udostępniania. Na szczęście istnieje proste i eleganckie rozwiązanie - Wildcard App ID. Powtarzamy procedurę tworzenia nowego identyfikatora aplikacji, ale zamiast jawnego identyfikatora aplikacji wybierz identyfikator aplikacji Wildcard, jak na zrzucie ekranu.
W tym momencie skończyliśmy z developer.apple.com, ale nie będziemy minimalizować okna przeglądarki. Chodźmy do i przeczytaj o narzędziu Match od deski do deski.
Uważny czytelnik zauważył, że aby skorzystać z tego narzędzia, potrzebujemy prywatnego repozytorium oraz konta, które ma dostęp zarówno do Apple Developer Program, jak i Github. Tworzymy (jeśli nagle czegoś takiego nie ma) konto formularza [email chroniony], wymyśl silne hasło, zarejestruj je na stronie developer.apple.com i wyznacz jako administratora projektu. Następnie przyznaj swojemu kontu dostęp do firmowego repozytorium Github i utwórz nowe prywatne repozytorium o nazwie takiej jak AmazingAppMatch.
3. Konfigurowanie Fastlane i narzędzia dopasowującego
Otwórz terminal, przejdź do folderu z projektem i zainicjuj Fastlane, jak wskazano w . Po wprowadzeniu polecenia
$ fastlane initzostaniesz poproszony o wybranie dostępnych konfiguracji użytkowania. Wybieramy czwartą pozycję - ręczną konfigurację projektu.
W projekcie pojawił się nowy katalog Fastlane, w którym znajdują się dwa pliki - Appfile i Fastfile. W skrócie – w Appfile przechowujemy dane serwisowe, a w Fastfile piszemy zlecenia, w terminologii Fastlane zwane pasami. Polecam przeczytanie oficjalnej dokumentacji: , .
Otwórz plik aplikacji w swoim ulubionym edytorze tekstu i przywróć go do następującej postaci:
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
Wracamy do terminala i zgodnie z oficjalną instrukcją przystępujemy do ustawiania meczu.
$ fastlane match init
$ fastlane match development
Następnie wprowadź żądane dane - repozytorium, konto, hasło itp.
Ważne: przy pierwszym uruchomieniu narzędzia dopasowującego zostaniesz poproszony o podanie hasła w celu odszyfrowania repozytorium. Bardzo ważne jest, aby zapisać to hasło, będzie nam ono potrzebne na etapie konfiguracji serwera CI!
W folderze Fastlane pojawił się nowy plik - Matchfile. Otwórz go w swoim ulubionym edytorze tekstu i przenieś do formularza:
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
Wypełniamy go w ten sposób, jeśli w przyszłości chcemy używać match do podpisywania buildów do wgrania do Crashlytics i/lub AppStore, czyli do podpisania identyfikatora pakietu Twojej aplikacji.
Ale, jak pamiętamy, stworzyliśmy specjalny identyfikator Wildcard do podpisania wersji testowej. Dlatego otwórz Fastfile i wprowadź nowy pas:
lane :testing_build_for_firebase do
match(
type: "development",
readonly: true,
app_identifier: "com.company.*",
git_branch: "uitests" # создаем отдельный бранч для development сертификата для подписи тестовой сборки.
)
end
Zapisz, wejdź do terminala
fastlane testing_build_for_firebasei zobacz, jak Fastlane utworzył nowy certyfikat i umieścił go w repozytorium. Świetnie!
Otwórz XCode. Teraz mamy wymagany profil aprowizacji typu Match Development com.company.*, który należy określić w sekcji Profil aprowizacji dla obiektów docelowych AmazingApp i AmazingAppUITests.
Pozostaje dodać pas do budowania testów. Chodźmy do projekt wtyczki fastlane, który ułatwia skonfigurowanie eksportu do laboratorium testowego Firebase i postępowanie zgodnie z instrukcjami.
Skopiuj i wklej z oryginalnego przykładu, aby nasza linia testowa_build_for_firebase wyglądała tak:
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
Aby uzyskać pełne informacje na temat konfiguracji fastlane w CircleCI, polecam przeczytać oficjalną dokumentację .
Nie zapomnij dodać nowego zadania do naszego pliku 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. A co z naszym stanowiskiem testowym? Konfigurowanie Firebase.
Przejdźmy właściwie do tego, po co artykuł został napisany.
Twoja aplikacja może korzystać z Firebase w ramach bezpłatnego planu lub może w ogóle nie korzystać z Firebase. Nie ma absolutnie żadnej zasadniczej różnicy, ponieważ na potrzeby testów możemy stworzyć osobny projekt z rocznym darmowym użytkowaniem (fajne, co?)
Logujemy się na nasze konto infrastrukturalne (lub inne, nie ma to znaczenia) i przechodzimy do . Utwórz nowy projekt o nazwie AmazingAppUITests.
Ważne: W poprzednim kroku w pliku Fastfile na ścieżce firebase_test_lab_ios_xctest parametr gcp_project musi odpowiadać nazwie projektu.
Domyślne ustawienia nam odpowiadają.
Nie zamykamy zakładki, rejestrujemy się pod tym samym kontem w jest środkiem niezbędnym, gdyż komunikacja z Firebase odbywa się za pomocą interfejsu konsoli gcloud.
Google rozdaje 300 dolarów na rok, co w kontekście wykonywania autotestów równa się rocznemu bezpłatnemu korzystaniu z usługi. Wpisujemy dane do płatności, czekamy na odpis testowy 1 zł i wpływamy na konto 300 zł. Po roku projekt zostanie automatycznie przeniesiony na bezpłatny plan taryfowy, więc nie powinieneś martwić się o możliwą utratę pieniędzy.
Wróćmy do zakładki z projektem Firebase i przenieśmy go do planu taryfowego Blaze – teraz mamy za co zapłacić w przypadku przekroczenia limitu.
W interfejsie gcloud wybierz nasz projekt Firebase, wybierz element menu głównego „Catalogue” i dodaj Cloud Testing API i Cloud Tools Result API.
Następnie przejdź do pozycji menu „IAM i administracja” -> Konta serwisowe -> Utwórz konto serwisowe. Udziel uprawnień do edycji projektu.
Utwórz klucz API w formacie JSON
Pobrany plik JSON będzie nam potrzebny nieco później, ale na razie uważamy, że konfiguracja laboratorium testowego została ukończona.
5. Ustawianie CircleCI
Rodzi się rozsądne pytanie – co zrobić z hasłami? Aby bezpiecznie chronić nasze hasła i inne wrażliwe dane, pomoże nam mechanizm zmiennych środowiskowych naszej maszyny budującej. W ustawieniach projektu CircleCI wybierz Zmienne środowiskowe
I ustaw następujące zmienne:
- klucz: GOOGLE_APPLICATION_CREDENTIALS
wartość: zawartość pliku json klucza konta usługi gcloud - klucz: MATCH_PASSWORD
wartość: hasło do odszyfrowania repozytorium github z certyfikatami - klucz: FASTLANE_HASŁO
wartość: hasło do konta infrastruktury portalu deweloperów Apple
Zapisujemy zmiany, tworzymy PR i wysyłamy go do naszego lidera zespołu do przeglądu.
Wyniki
W wyniku tych prostych manipulacji otrzymaliśmy dobre, stabilne stanowisko robocze z możliwością nagrywania wideo na ekranie urządzenia w czasie testów. W przypadku testowym określiłem model urządzenia iPhone X, ale farma zapewnia bogaty wybór z kombinacji różnych modeli i wersji iOS.
Druga część poświęcona będzie krok po kroku konfigurowaniu Firebase Test Lab dla projektu na Androida.
Źródło: www.habr.com