>
>
>
>
>
>
>
>
>
>
Automação de testes de IU no iOS tornou-se tão fácil como escrever testes unitários desde que a Apple introduziu a estrutura XCUI. Neste post, vou falar sobre como o XCUI, juntamente com o design em camadas, pode ajudar a automatizar facilmente as aplicações, especialmente aquelas com múltiplos elementos de IU personalizados. Um desses aplicativos em que usamos isso amplamente é o VMware Boxer, um aplicativo empresarial da VMware que agrega três funções importantes – Email, Calendário e Contatos. O VMware Boxer usa vários tipos de elementos de IU desde o UITableView nativo até elementos visuais altamente personalizados.
Presume-se que os leitores tenham um entendimento básico de Xcode, Objective C, Swift, XCUI framework e do ecossistema de desenvolvimento da Apple em geral. Se você é novo no XCUI, você deve começar aqui.
Como qualquer outro projeto de automação UI, nossa equipe começou com uma pergunta sobre qual framework de automação usar. Nós tínhamos usado o SeeTest. No entanto, vimos isso como uma oportunidade de rever nossa estratégia de automação, dada a nova e complexa funcionalidade adicionada no VMware Boxer, o número de produtos no ecossistema VMware e os testes de integração entre esses produtos. Abaixo estavam as escolhas que consideramos –
1. Continue com SeeTest
2. Earl Grey
3. XCUI
Embora SeeTest tivesse a capacidade de lidar com nossas necessidades imediatas para automatizar, havia um desafio independente a ser enfrentado. Isso exigia a adoção de uma nova pilha de tecnologia. Isso exigia treinamento adicional para desenvolvedores iOS e especialistas dedicados para manter o sistema de automação.
E quanto ao Appium? Nós não consideramos o Appium pelas mesmas razões mencionadas acima para o SeeTest. Appium é uma boa escolha se tivéssemos aplicativos híbridos ou código compartilhado significativo entre Android e iOS.
Earl Grey 1 foi uma escolha possível, dado que nos permitiu ficar em ferramentas de desenvolvimento Xcode e Apple e foi baseado no XCTest. A automação do Earl Grey 1, no entanto, funciona no mesmo processo que a aplicação em teste. Por outro lado, a automação baseada no framework XCUI da Apple roda em um processo separado do que a aplicação em teste. Isto é preferível já que a aplicação em teste não deve ser nada mais que uma caixa preta para a entidade (um processo de automação ou um usuário final) que está testando sua UI.
Deixe o processo de automação (um que está testando) isolado da aplicação em teste. A aplicação em teste não deve ser nada mais que uma caixa preta para o processo de automação.
Uma nova ferramenta no ecossistema Apple que não esteja alinhada com a abordagem da Apple (por exemplo, Earl Grey 1) pode falhar sem aviso prévio. Tal abordagem pode exigir muito esforço para manter para continuar a trabalhar com ofertas mais recentes ou futuras da Apple.
Early Grey 2 adicionou a capacidade de interagir com o XCUI. Foi uma tentativa de alinhamento com XCUI mas tinha estes problemas conhecidos.
Eventualmente, XCUI era a escolha preferida. Com isso, um desenvolvedor terá mais controle sobre a automação e será o beneficiário imediato de qualquer inovação no ecossistema da Apple.
Aplicação em teste e módulo de automação XCUI
Antes de entrarmos nos detalhes, é importante reiterar que o módulo de automação usando XCUI roda como um processo independente da aplicação que está em teste. Para começar, adicionamos um novo módulo que passaremos a referir como o Módulo de Automação (AM). AM é um espaço de trabalho contendo uma coleção de classes e estruturas de dados usados para automação VMware Boxer usando XCUI.
Identificadores de Acessibilidade
É importante que a aplicação seja desenvolvida mantendo sua testabilidade em mente. Uma das responsabilidades do desenvolvedor é garantir que cada elemento da interface do usuário que é exposto ao usuário final tenha o identificador de acessibilidade definido durante o desenvolvimento. O identificador de acessibilidade é o link entre a aplicação em teste e o processo de automação do XCUI.
O identificador de acessibilidade é o link entre a aplicação em teste e o processo de automação do XCUI.
Padrão de desenho
Como mencionado anteriormente, o VMware Boxer é uma enorme aplicação. A escolha do padrão de design a ser utilizado foi feita tendo em mente que os testes devem ser fáceis de implementar, fáceis de manter, reutilizáveis, robustos e escaláveis. O conteúdo abaixo explica as camadas da arquitetura do módulo XCUI Automation para VMware Boxer:
A figura a seguir mostra os blocos básicos de construção:
>
As classes de teste
Esta é a camada que tem as classes com os métodos de teste. A intenção desta camada é ter testes compostos de código mínimo que diz apenas o que está sendo testado. Além disso, o desenvolvedor implementando os testes precisa apenas pensar no fluxo de aplicações de alto nível necessário para testar o que está sendo testado. O resto da complexidade (por exemplo, como navegar para a IU onde o teste desejado pode ser realizado) deve ser abstraído para camadas reutilizáveis. Consulte a imagem abaixo que mostra um exemplo de método de teste que explica a intenção acima – o código testa se uma IU de configurações pode ajudar a habilitar/desabilitar um recurso ou se ela tem controles de switch necessários.
>
Então, o desenvolvedor que está escrevendo os testes poderia escrever código que é tão simples quanto pseudo código. Entretanto, é claro que alguma lógica deve ser invocada a partir da próxima camada (Flows : explicado na próxima seção).
Flows Classes
Flows representam uma coleção de classes que fornece funcionalidades necessárias para várias classes de Testes. As funcionalidades podem incluir a configuração da aplicação antes de executar o caso de teste real ou a navegação para uma determinada parte da aplicação em teste. A maioria destas funcionalidades são reutilizáveis e requeridas em múltiplos testes. por exemplo, o caso de teste de amostra acima requer que 1. o aplicativo seja lançado. e 2. Navegamos para uma tela de configurações do Controlador de Funções.
Então, as classes de Fluxo seriam invocadas a partir de Testes e implementariam fluxos como “Navegar para Configurações” ou “Navegar para Configurações do Controlador de Funções”.
Classes de Telas
Telas são classes que têm um mapeamento um-para-um para os respectivos Controladores de Visualização. Um View Controller pode ser, no alto nível, visto como uma classe tendo (na vista de fundo) UIControls e métodos que respondem à interação do usuário com esses UIControls. Uma classe Screen é simplesmente um mapeamento proxy do View Controller. A figura abaixo mostra esse mapeamento. Há uma célula View Inicial na UI e quando o usuário bate nesta célula, o usuário pode selecionar o que deve ser marcado como a view inicial para o aplicativo. A figura abaixo mostra como uma classe Screen é implementada para mapear o requerimento acima.
O pseudo código para esta classe Screen se pareceria com –
// The class models the SettingFormViewController for XCUI tests.public class SettingsFormScreen {
private static let navBarId = "Boxer.Settings.NavigationBar"
private lazy var featureControllerCell = boxerApp.application.tables.cells public func navigateToFeatureController() -> Bool {
return // tap on Cell with featureControllerCellId
}
}class AccessibilityIdentifiers: NSObject {// MARK: Settings Screenstatic let featureControllerCellId = "Boxer.Settings.FeatureControllerCell"
}
>
O que é boxerApp no código acima? No código acima boxerApp representa uma unidade que é uma instância da classe BoxerApp que encapsula a aplicação em teste e suas telas. Isto é explicado na próxima seção.
O código acima modela o SettingFormViewController do VMware Boxer. A convenção usada para nomear a classe é que o nome é derivado do nome do view controller, substituindo o sufixo ViewController por Screen. Note também a classe de conveniência que possui identificadores de acessibilidade.
O identificador de acessibilidade é o elo comum entre a aplicação em teste e o processo de automação XCUI.
Conjuntando: VMware Boxer XCUI Automation Module
O módulo UITest testa a aplicação em execução. É importante que o modelo da aplicação seja projetado de forma que uma instância da aplicação em teste seja uma única unidade. Isto significa que a aplicação em teste deve ser vista como uma coleção de classes de telas que participam dos fluxos de negócio (coleção de classes de fluxo) que são invocadas a partir dos testes (coleção de classes) com base no requerimento do teste. Cada unidade de aplicação deve ter exatamente uma instância de cada classe Screen que corresponda a um controlador de visualização.
Como conseguir isto?
Uma suíte XCUITest pode conseguir isto encapsulando a aplicação sob instância de teste(XCUIApplication) em uma unidade, por exemplo, a classe BoxerApp que tem uma aplicação membro e tem todas as telas para aquela aplicação. A figura abaixo explica este encapsulamento
>
Por isso, antes do início da suíte XCUITest, a primeira coisa que faria seria criar uma instância do módulo BoxerApp usando o identificador do pacote da aplicação em teste. A figura abaixo explica isto
>
Esta instância do BoxerApp (a unidade que encapsula a aplicação XCUIA e as telas) é então passada pelo Tests::testMethod to Flows::flowMethod como primeiro parâmetro.
>
The Flows::flowMethod, por sua vez, chama Screen::screenMethod e passa por BoxerApp, se necessário.
>
Finalmente a interação com a UI da aplicação acontece através de Screen::screenMethod.
>
A figura abaixo mostra o desenho acima.
Conclusão
Os testes XCUI podem ser complicados e incontroláveis se não forem feitos com um plano. Espero que este post forneça dicas úteis sobre como pensar em estruturar seu projeto de automação de forma modular, limpa e em camadas.
O que vem a seguir?
I am going to cover these topics in the series of stories I am planning:
XCUI : Parte 2 -Interacting with Native applications in a clean way
XCUI : Parte 3 -How XCUI runtime can interact with the application under test in a clean way.
XCUI : Parte 4 -Localização de alertas do sistema.
XCUI : Parte 5 -Observando o progresso do teste e acessando relatórios e capturando capturas de tela.