Meu nome é Dmitry, trabalho como testador na empresa . Recentemente terminei de lidar com um recurso relativamente recente do — nomeadamente, com testes instrumentais de aplicações iOS utilizando o framework de testes nativo XCUITest.
Antes disso, eu já havia experimentado o Firebase Test Lab para Android e gostei muito de tudo, então resolvi tentar colocar a infraestrutura de testes iOS do projeto em pé de igualdade. Tive que pesquisar muito no Google e nem tudo deu certo na primeira vez, então resolvi escrever um artigo tutorial para quem ainda está com dificuldades.
Portanto, se você tiver testes de UI em um projeto iOS, já pode tentar executá-los em dispositivos reais hoje, gentilmente cedidos pela Good Corporation. Para os interessados, sejam bem-vindos ao gato.
Na história, decidi desenvolver alguns dados iniciais - um repositório privado no GitHub e o sistema de construção CircleCI. O nome do aplicativo é AmazingApp, bundleID é com.company.amazingapp. Apresento esses dados imediatamente para reduzir confusão subsequente.
Se você implementou determinadas soluções em seu projeto de forma diferente, compartilhe sua experiência nos comentários.
1. Os próprios testes
Crie uma nova ramificação do projeto para testes de IU:
$ git checkout develop
$ git pull
$ git checkout -b “feature/add-ui-tests”
Vamos abrir o projeto no XCode e criar um novo Target com testes de UI [XCode -> File -> New -> Target -> iOS Testing Bundle], dando a ele o nome autoexplicativo AmazingAppUITests.
Vá para a seção Build Phases do Target criado e verifique a presença de Target Dependencies - AmazingApp, em Compile Sources - AmazingAppUITests.swift.
Uma boa prática é separar diferentes opções de construção em esquemas separados. Criamos um esquema para nossos testes de UI [XCode -> Produto -> Esquema -> Novo Esquema] e damos a ele o mesmo nome: AmazingAppUITests.
A compilação do esquema criado deve incluir o Target da aplicação principal - testes AmazingApp e Target UI - AmazingAppUITests - veja a captura de tela
A seguir, criamos uma nova configuração de compilação para testes de UI. No XCode, clique no arquivo do projeto e vá para a seção Informações. Clique em “+” e crie uma nova configuração, por exemplo XCtest. Precisaremos disso no futuro para evitar dançar com pandeiro quando se trata de assinatura de código.
Existem pelo menos três Targets no seu projeto: a aplicação principal, os testes unitários (afinal eles existem, certo?) e os testes Target UI que criamos.
Vá para Target AmazingApp, guia Build Settings, seção Code Signing Identity. Para a configuração do XCtest, selecione Desenvolvedor iOS. Na seção Estilo de assinatura de código, selecione Manual. Ainda não geramos um perfil de provisionamento, mas com certeza voltaremos a ele um pouco mais tarde.
Para Target AmazingAppUITests fazemos o mesmo, mas na coluna Product Bundle Identifier inserimos com.company.amazingappuitests.
2. Configurando um projeto no Apple Developer Program
Vá para a página do Apple Developer Program, vá para a seção Certificados, Identificadores e Perfis e depois para a coluna App IDs do item Identificadores. Crie um novo ID de aplicativo chamado AmazingAppUITests e bundleID com.company.amazingappuitests.
Agora temos a oportunidade de assinar nossos testes com um certificado separado, mas... O procedimento para montar uma compilação para teste envolve a montagem do próprio aplicativo e a montagem do executor de testes. Conseqüentemente, nos deparamos com o problema de assinar dois IDs de pacote com um perfil de provisionamento. Felizmente, existe uma solução simples e elegante - Wildcard App ID. Repetimos o procedimento para criar um novo App ID, mas em vez do App ID explícito, selecione Wildcard App ID como na captura de tela.
Neste ponto, terminamos de trabalhar com developer.apple.com, mas não minimizaremos a janela do navegador. Vamos para e leia sobre o utilitário Match de capa a capa.
Um leitor atento notou que para usar este utilitário precisaremos de um repositório privado e de uma conta com acesso ao Apple Developer Program e ao Github. Criamos (se de repente não existir tal coisa) uma conta no formato [email protegido], crie uma senha forte, registre-a em developer.apple.com e nomeie-a como administrador do projeto. A seguir, damos à conta acesso ao repositório github da sua empresa e criamos um novo repositório privado com um nome como AmazingAppMatch.
3. Configurando o Fastlane e o utilitário de partida
Abra um terminal, vá até a pasta com o projeto e inicialize o fastlane conforme indicado em . Depois de inserir o comando
$ fastlane initVocê será solicitado a selecionar as configurações de uso disponíveis. Selecione a quarta opção - configuração manual do projeto.
O projeto possui um novo diretório fastlane, que contém dois arquivos - Appfile e Fastfile. Resumindo, armazenamos dados de serviço no Appfile e escrevemos jobs no Fastfile, chamados de pistas na terminologia Fastlane. Recomendo a leitura da documentação oficial: , .
Abra o Appfile em seu editor de texto favorito e coloque-o no seguinte formato:
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
Voltamos ao terminal e de acordo com o manual oficial começamos a configurar o match.
$ fastlane match init
$ fastlane match development
A seguir, insira os dados solicitados - repositório, conta, senha, etc.
Importante: Ao iniciar o utilitário de correspondência pela primeira vez, você será solicitado a inserir uma senha para descriptografar o repositório. É muito importante salvar esta senha, precisaremos dela na hora de configurar o servidor CI!
Um novo arquivo apareceu na pasta fastlane - Matchfile. Abra-o em seu editor de texto favorito e exiba-o assim:
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
Preenchemos exatamente desta forma se quisermos usar match no futuro para assinar builds para exibição no Crashlytics e/ou AppStore, ou seja, para assinar o ID do pacote da sua aplicação.
Mas, como lembramos, criamos um Wildcard ID especial para assinar a versão de teste. Portanto, abra o Fastfile e insira uma nova pista:
lane :testing_build_for_firebase do
match(
type: "development",
readonly: true,
app_identifier: "com.company.*",
git_branch: "uitests" # создаем отдельный бранч для development сертификата для подписи тестовой сборки.
)
end
Salve e entre no terminal
fastlane testing_build_for_firebasee vemos como o fastlane criou um novo certificado e o colocou no repositório. Ótimo!
Abra o XCode. Agora temos o perfil de provisionamento necessário no formato Match Development com.company.*, que deve ser especificado na seção Perfil de provisionamento para os destinos AmazingApp e AmazingAppUITests.
Resta adicionar pista para montagem de testes. Vamos para um projeto de plugin para fastlane que facilita configurar a exportação para o Firebase Test Lab e seguir as instruções.
Vamos copiar e colar do exemplo original para que nossa pista testing_build_for_firebase fique assim:
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 obter informações completas sobre como configurar o fastlane no CircleCI, recomendo a leitura da documentação oficial .
Não se esqueça de adicionar uma nova tarefa ao nosso 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. E quanto à nossa bancada de testes? Configurando o Firebase.
Vamos ver para que o artigo foi escrito.
Talvez seu aplicativo use o Firebase em um plano gratuito ou talvez nem use. Não há absolutamente nenhuma diferença fundamental, porque para necessidades de teste podemos criar um projeto separado com um ano de uso gratuito (legal, certo?)
Fazemos login em nossa conta de infraestrutura (ou qualquer outra, não importa) e vamos para . Crie um novo projeto chamado AmazingAppUITests.
Importante: Na etapa anterior do Fastfile na pista firebase_test_lab_ios_xctest o parâmetro gcp_project deve corresponder ao nome do projeto.
As configurações padrão são muito adequadas para nós.
Não feche a aba, cadastre-se com a mesma conta em - esta é uma medida necessária, pois a comunicação com o Firebase ocorre através da interface do console gcloud.
O Google está doando US$ 300 por ano, o que no contexto da realização de autotestes equivale a um ano de uso gratuito do serviço. Inserimos suas informações de pagamento, aguardamos o débito de teste de US$ 1 e recebemos US$ 300 em sua conta. Após um ano, o projeto será automaticamente transferido para um plano tarifário gratuito, não havendo necessidade de se preocupar com possíveis perdas de dinheiro.
Vamos voltar à aba do projeto Firebase e transferi-lo para o plano tarifário Blaze - agora temos algo a pagar se o limite for ultrapassado.
Na interface gcloud, selecione nosso projeto Firebase, selecione o item “Diretório” do menu principal e adicione a API Cloud Testing e a API Cloud Tools Result.
Em seguida, vá ao item de menu “IAM e administração” -> Contas de serviço -> Criar conta de serviço. Concedemos direitos para editar o projeto.
Crie uma chave de API no formato JSON
Precisaremos do JSON baixado um pouco mais tarde, mas por enquanto consideraremos a configuração do Test Lab concluída.
5. Configurando o CircleCI
Surge uma pergunta razoável - o que fazer com as senhas? O mecanismo de variável de ambiente de nossa máquina de construção nos ajudará a armazenar com segurança nossas senhas e outros dados confidenciais. Nas configurações do projeto CircleCI, selecione Variáveis de ambiente
E configure as seguintes variáveis:
- chave: GOOGLE_APPLICATION_CREDENTIALS
valor: conteúdo do arquivo json da chave da conta de serviço gcloud - chave: MATCH_PASSWORD
valor: senha para descriptografar o repositório github com certificados - chave: FASTLANE_PASSWORD
valor: senha da conta de infraestrutura do Apple Developer Portal
Salvamos as alterações, criamos um PR e o enviamos ao líder da equipe para revisão.
Resultados de
Como resultado dessas manipulações simples, obtivemos um suporte de trabalho bom e estável, com capacidade de gravar vídeo na tela do dispositivo no momento do teste. No exemplo de teste, especifiquei o modelo do dispositivo iPhone X, mas o farm oferece uma seleção rica de uma combinação de diferentes modelos e versões do iOS.
A segunda parte será dedicada à configuração passo a passo do Firebase Test Lab para um projeto Android.
Fonte: habr.com