Diversas estruturas de automação de teste para aplicativos nativos de reação

A fasquia está alta para os aplicativos móveis de hoje. Primeiro, os aplicativos devem atender ao padrão de qualidade que os mercados de aplicativos esperam. Em segundo lugar, os usuários de aplicativos móveis são muito exigentes. Muitas alternativas estão disponíveis para download, portanto, os usuários não tolerarão um aplicativo com bugs. Como os aplicativos móveis se tornaram uma parte tão crucial da vida das pessoas, os usuários não terão vergonha de compartilhar seu amor ou ódio por um aplicativo — e esse feedback chega a milhões de usuários em segundos.

Leitura adicional sobre Smashing:

• Construindo seu primeiro aplicativo iOS com JavaScript
• Por que você deve considerar o React Native para seu aplicativo móvel
• Automação de teste para aplicativos, jogos e a Web para dispositivos móveis
• Renderização do lado do servidor com React, Node e Express
• Observações sobre acessibilidade renderizada pelo cliente

O celular é mais importante do que nunca. Mas obter um aplicativo da maneira certa, fazê-lo funcionar em todos os dispositivos possíveis, com diferentes versões de SO, resoluções de tela, chipsets e outras características de hardware, e tornar a experiência do usuário suave em todas as configurações possíveis, é uma tarefa desafiadora.

Uma tonelada de ótimas tecnologias, ferramentas, estruturas e componentes de código aberto estão disponíveis para criar aplicativos móveis nativos. Que valor o React Native traz para a cena e como podemos garantir que os aplicativos criados com ele sejam bem recebidos por seu público-alvo?

Neste artigo, veremos o que está disponível para testar aplicativos React Native. Primeiro, explicarei alguns recursos-chave do React Native, antes de ver como implementar esses testes. Em segundo lugar, categorizarei os métodos e frameworks de teste em três níveis (unidade, integração, funcional), fornecendo exemplos para cada um. Por fim, fornecerei exemplos simples de como implementar testes usando as estruturas de automação de teste de código aberto mais populares para testes de aplicativos funcionais.

A arquitetura básica dos aplicativos nativos do React

Tudo começou com o React há mais de três anos, quando o Facebook apresentou seu framework para desenvolvedores web. Ele estava destinado a ser popular, não apenas porque foi criado e desenvolvido pelo Facebook, mas por causa dos recursos que forneceu aos desenvolvedores da Web – e especialmente como mudou a maneira como criamos aplicativos.

O conceito desse tipo de estrutura “aprenda uma vez, escreva em qualquer lugar” não era novo; já havíamos visto bibliotecas JavaScript fazerem coisas semelhantes (Sencha, PhoneGap e Appcelerator, entre outras), mas havia algo melhor no React que impactava os hábitos dos desenvolvedores e como eles dividem a UI de um aplicativo em componentes discretos.

O React Native não usa o DOM para renderização. Em vez disso, ele é renderizado com visualizações de interface do usuário nativas, o que significa que você está usando os componentes nativos fornecidos pelo sistema operacional. Esse tipo de fluxo de criação de produtos, em que você substitui a API DOM por uma API mais declarativa, oferece aos desenvolvedores um nível de abstração mais coeso e simplificado.

A principal coisa sobre o React Native é que ele traz o modelo de programação React para aplicativos móveis, desenvolvimento e teste. Na verdade, ele não funciona diretamente como uma ferramenta ou estrutura de plataforma cruzada, mas acelera a tendência de criar aplicativos móveis nessa nova plataforma. E esse é um dos pilares do que torna o React Native tão poderoso, fácil de aprender e fácil de escrever nesta nova plataforma.

A principal diferença, bem como a vantagem, do mobile nativo versus a web é que, em vez de executar uma implementação baseada em JavaScript em um navegador e expor elementos HTML, agora estamos confiando no JavaScriptCore incorporado em aplicativos, que são específicos da plataforma Elementos da interface do usuário.

Automação de Testes em Diferentes Níveis: Unitário, Integração, Componente e Funcional

Todo software móvel é construído usando composição. No Android e no iOS, isso significa que pequenos componentes de software são organizados juntos para formar componentes maiores e de nível superior com maior funcionalidade, até que os objetivos e os requisitos do aplicativo sejam atendidos. Uma boa prática de teste é executar testes que cubram a funcionalidade em todos os níveis da composição.

Neste artigo, abordarei métodos de teste e estruturas de automação em três níveis. O foco principal está no teste funcional de nível mais alto, mas os aplicativos React Native podem ser testados – e os testes podem ser automatizados – em pelo menos os seguintes níveis:

• Teste de unidade
  Isso pode ser tão básico quanto testar objetos e métodos JavaScript no nível do componente.
• Teste de componentes
  Cada componente pode ser testado visualmente ou funcionalmente. ReactTestUtils fornece uma estrutura simples para testar componentes React.
• Teste de integração
  O teste de integração vem a seguir e é uma fase em que um grupo de unidades diferentes é normalmente testado como uma entidade.
• Teste funcional
  O teste funcional é um tipo de teste de caixa preta que se concentra nos requisitos e interações do usuário e abrange todos os softwares subjacentes, todas as interações do usuário e o aplicativo como uma entidade.

Além do ReactTestUtils, o React Native fornece métodos úteis de teste de unidade, mas nenhum deles cobre completamente a lógica real do aplicativo. Portanto, os aplicativos móveis criados no React Native se beneficiam mais do teste de interface do usuário funcional. Uma variedade de estruturas de automação de teste funcional está disponível, e veremos algumas das mais populares neste artigo.

Embora o teste de unidade possa ser feito no nível do componente, a automação de teste funcional fornece melhores recursos para testar as entidades maiores em um aplicativo React Native. Com o React Native, o teste de unidade de lógica de componente pode ser feito isoladamente, usando bibliotecas JavaScript tradicionais e forçando o React Native a retornar componentes regulares em vez de nativos. Com estruturas funcionais de automação de teste, os componentes de interface do usuário fazem parte do aplicativo e são fáceis de testar como um todo.

Separarei essas estruturas em estruturas de plataforma cruzada e estruturas específicas de plataforma, conforme ilustrado na imagem abaixo.

A melhor parte dos aplicativos React Native é que eles são totalmente nativos para as duas principais plataformas móveis (Android e iOS). Isso significa que temos mais frameworks, ferramentas e métodos nativos para fins de teste. Veremos as estruturas funcionais de automação de teste na seção abaixo intitulada "Usando estruturas funcionais de automação de teste com aplicativos React Native".

Vamos começar com os recursos de teste de unidade, usando um teste de JavaScript para ilustrar.

Testes unitários com Jest e Jasmine

Por padrão, o React Native fornece testes Jest para teste de unidade, e isso funciona para Android e iOS. Atualmente, a cobertura de teste não é perfeita, mas de acordo com o Facebook, mais recursos de teste de unidade serão introduzidos no React Native, e os usuários já podem criar seus próprios.

O Jest usa a estrutura orientada por comportamento Jasmine como base para testar o código JavaScript. Cada caso de teste começa a partir de uma chamada de função describe() , semelhante a como o JUnit usa a classe TestCase . A função describe() recebe dois parâmetros: a descrição e o título do caso de teste e a função a ser executada. A função it() inclui todas as etapas de teste e (semelhante ao JUnit) fornece uma série de funções expect() .

Aqui está um exemplo de um script de teste Jasmine para um aplicativo de player.

 describe("Player", function() { var player; var song; beforeEach(function() { player = new Player(); song = new Song(); }); it("should be able to play a song", function() { player.play(song); expect(player.currentlyPlayingSong).toEqual(song); //demonstrates use of custom matcher expect(player).toBePlaying(song); }); describe("when song has been paused", function() { beforeEach(function() { player.play(song); player.pause(); }); it("should indicate the song is paused", function() { expect(player.isPlaying).toBeFalsy(); // demonstrates use of 'not' with a custom matcher expect(player).not.toBePlaying(song); }); it("should be possible to resume", function() { player.resume(); expect(player.isPlaying).toBeTruthy(); expect(player.currentlyPlayingSong).toEqual(song); }); }); // demonstrates use of spies to intercept and test method calls it("tells the current song whether the user has made it a favorite", function() { spyOn(song, 'persistFavoriteStatus'); player.play(song); player.makeFavorite(); expect(song.persistFavoriteStatus).toHaveBeenCalledWith(true); }); //demonstrates use of expected exceptions describe("#resume", function() { it("should throw an exception if song is already playing", function() { player.play(song); expect(function() { player.resume(); }).toThrow("song is already playing"); }); }); });

Este exemplo básico mostra como o Jasmine pode ser usado para testar a funcionalidade de um aplicativo, mas mantém o foco no teste em nível de método. Além disso, o React Native fornece alguns recursos básicos para testar componentes integrados. Isso funciona para componentes nativos e JavaScript e permite a comunicação entre eles por meio de uma ponte.

Teste de integração

No momento, os testes de integração destacados na comunidade React Native estão disponíveis apenas para iOS e são muito limitados em sua capacidade de testar componentes. A comunicação passa pela ponte e requer componentes nativos e JavaScript. Para esta funcionalidade, estão disponíveis dois componentes para implementação de testes de integração customizados, RCTestRunner e RCTestModule.

Um exemplo básico de Objective-C para construir um esqueleto de teste de um aplicativo iOS começaria assim:

 @implementation ExampleTests { RCTTestRunner *_runner; } - (void)setUp { [super setUp]; _runner = RCTInitRunnerForApp(@"IntegrationTestHarnessTest", nil); } - void()testExampleTests { [_runner runTest:_cmd module:@"ExampleTests"] } @end

No entanto, existem outras maneiras de executar o teste de integração e estendê-lo para Android e iOS. Uma boa alternativa para executar testes de unidade e integração é o Mocha, que fornece uma estrutura de teste JavaScript rica em recursos que é executada em Node.js. O Mocha também fornece desenvolvimento orientado a comportamento (BDD), desenvolvimento orientado a testes (TDD) e interfaces QUnit para testes.

Para testes funcionais de interface do usuário, abordarei as estruturas de automação de teste mais proeminentes e mais usadas, incluindo Appium, Calabash, XCTest e algumas outras.

Usando estruturas de automação de teste funcional com aplicativos React Native

Para simplificar o processo de desenvolvimento de aplicativos e maximizar a cobertura de testes, temos várias estruturas de automação de teste de código aberto para escolher.

A melhor escolha — se seu aplicativo for executado em várias plataformas de SO — é uma estrutura que dê suporte a várias plataformas e forneça uma base robusta para automação de teste. Em dispositivos móveis, o termo “plataforma cruzada” refere-se a uma estrutura que fornece a mesma API, ferramentas e recursos para Android e iOS.

Além disso, uma variedade de excelentes estruturas específicas de plataforma estão disponíveis. Naturalmente, cada framework foi construído para uma plataforma específica e, na maioria dos casos, é mais fácil de adotar para essa plataforma. Além de Appium e Calabash, abordarei quatro estruturas específicas de plataforma neste artigo: Robotium e Espresso para Android e XCTest e EarlGrey para iOS.

Quando se trata de automação de testes, lembre-se de que os aplicativos criados com React Native são totalmente nativos em iOS e Android; portanto, estruturas de automação de teste funcionais funcionarão bem com eles.

O exemplo que usarei com cada estrutura é uma implementação de uma interface de usuário de botão de opção muito básica.

 <Radio onSelect={this.onSelect.bind(this)} defaultSelect={this.state.optionSelected - 1}> <Option color="black" selectedColor="#000000"> <Item title="First option" description="First radio button"/> </Option> <Option color="black" selectedColor="#000000"> <Item title="Second option" description="Second radio button"/> </Option> <Option color="black" selectedColor="#000000"> <Item title="Third option" description="Third radio button"/> </Option> </Radio>

O snippet de teste incluído em cada seção de estrutura abaixo mostra como o script de teste lida com cada elemento da interface do usuário e como os cliques e outras entradas do usuário são tratados. O objetivo dos exemplos não é fornecer instruções passo a passo, mas sim comparar exemplos e mostrar o que está disponível para automação de teste hoje e quais linguagens de programação podem ser usadas para teste.

Estruturas de plataforma cruzada

Como afirmado, o React Native não é realmente um framework multiplataforma, mas a adoção dele em outras plataformas é fácil. Nas próximas duas seções, veremos duas estruturas populares de automação de teste multiplataforma para teste móvel e automação de teste móvel.

Appium

Appium é uma estrutura de automação de teste de código aberto, com uma ferramenta de inspeção que funciona bem para aplicativos da Web nativos, híbridos e móveis. Ele usa JSONWireProtocol internamente para interagir com aplicativos iOS e Android, usando o Selenium WebDriver. Por causa disso, o Appium também funciona muito bem para a web móvel, e os casos de uso são muito semelhantes se o Selenium for usado para testes na web.

Na verdade, o Appium tem sido uma estrela em ascensão na automação de testes móveis no ano passado. Originalmente, ele foi desenvolvido para fornecer suporte multiplataforma para as principais plataformas, Android e iOS.

Ser multiplataforma significa que o framework e seus scripts funcionam exatamente da mesma forma em ambas as plataformas. Além disso, o Appium oferece um suporte fantástico à linguagem de programação — os desenvolvedores podem escrever testes usando sua linguagem favorita (por exemplo, Java, Ruby, Python, C#), ferramentas e ambiente. Também é fácil começar, criar e manter testes reutilizáveis ​​e executar esses testes em dispositivos físicos reais.

Quando se trata de aplicativos baseados em React Native, o JavaScript não é necessariamente necessário; os testes podem ser escritos em qualquer idioma. Por exemplo, os scripts do Appium podem ter esta aparência:

 driver.findElement(By.id("com.example.app:id/radio0")).click(); driver.findElement(By.id("com.example.app:id/radio1")).click(); driver.findElement(By.id("com.example.app:id/radio2")).click(); driver.findElement(By.id("com.example.app:id/editText1")).click(); driver.findElement(By.id("com.example.app:id/editText1")).sendKeys("Simple Test"); driver.findElement(By.name("Answer")).click(); // or alternatively like this: driver.findElement(By.id("com.example.app:id/button1")).click();

Então, como essas funções do WebDriver acessam aplicativos executados em dispositivos? Basicamente, o Appium inicia um script de teste no dispositivo ou emulador, que então cria um servidor e escuta os comandos do servidor principal do Appium. É o mesmo que o servidor Selenium, que obtém solicitações HTTP das bibliotecas do cliente Selenium. A diferença entre Android e iOS é ilustrada na imagem abaixo:

Com iOS, o Selenium WebDriver obtém um comando do script Appium (por exemplo, click() ) e o envia na forma de JSON por meio de uma solicitação HTTP para o servidor Appium. O Appium conhece o contexto de automação e envia esse comando para o servidor de comando Instruments, que espera que o cliente de comando Instruments o pegue e execute com bootstrap.js no ambiente iOS Instruments. Depois que o comando é executado, o cliente de comando Instruments envia a mensagem de volta ao servidor Appium, que registra tudo relacionado ao comando em seu console. Este ciclo continua até que o script de teste seja concluído.

No Android, as coisas funcionam quase da mesma maneira, exceto que os frameworks usados ​​são Selendroid e UiAutomator. Resumindo, o Appium traduz os comandos do WebDriver para comandos UiAutomator (API de nível 17 ou superior) ou Selendroid (API de nível 16 ou inferior). Em um dispositivo físico, bootstrap.jar inicia um servidor TCP que obtém comandos de um cliente TCP. O processo é semelhante no iOS.

Se você estiver interessado em começar a usar o Appium, há muito material disponível, incluindo instruções passo a passo e tutoriais do Appium.

Cabaça

Outra excelente estrutura de teste multiplataforma é o Calabash, que permite que qualquer pessoa escreva testes para aplicativos móveis. A principal diferença é que os testes do Calabash são escritos em Cucumber. A ideia por trás de usar esse tipo de linguagem para testes é incrível: o teste em si é como uma especificação, e todos os testes são simples e fáceis de ler, mas executáveis ​​pelo sistema de automação.

Comparado ao Appium, o Calabash oferece uma maneira mais fácil de criar testes multiplataforma para Android e iOS. Isso se deve ao vocabulário direto e à linguagem orientada a especificações, o que torna os testes do Calabash idênticos em ambas as plataformas. Os testes reais são escritos em Gherkin e executados em Cucumber.

Devido a esses recursos, as diferenças entre o Calabash trabalhando em aplicativos Android e iOS são pequenas. Novamente, não há implicações para aplicativos React Native porque todos os componentes e interfaces de usuário são totalmente nativos para essas plataformas.

O fluxo básico de teste e criação de teste, no entanto, permanece o mesmo. Os testes Calabash (e Gherkin) incluem recursos, cenários e etapas. A abordagem recomendada é concluir primeiro as descrições de nível mais alto: recursos, seguidos de cenários e, em seguida, as etapas reais. Uma boa regra geral é criar os recursos do Calabash primeiro.

O exemplo abaixo mostra como nosso aplicativo e seus componentes de UI (botões de rádio, campo de texto e botão) seriam implementados no Calabash:

 Feature: Answer the question feature Scenario: As a valid user, I want to answer app question, I wait for text "What is the best way to test application on a hundred devices?" Then I press radio button 0 Then I press radio button 1 Then I press radio button 2 Then I enter text "Simple Test" into field with id "editText1" Then I press view with id "Button1"

As etapas geralmente começam com uma das palavras-chave given , then , when and or but . No entanto, eles não precisam; eles podem usar * em vez disso.

O Calabash também é amplamente utilizado por não desenvolvedores e pode ser usado para especificações e documentação de produtos devido à sua linguagem e lógica fáceis de entender. Eventualmente, os recursos e cenários são encapsulados em código Ruby.

Configurar o Calabash e começar a trabalhar com ele é fácil. Se você tiver o Bundler e o Ruby (ou rbenv) instalados, basta acessar estas poucas linhas em seu console e um ambiente Calabash será configurado em breve:

 $ gem install calabash-android $ gem install calabash-cucumber

Isso cuidará da instalação do Calabash-Android e do Calabash-iOS, e sua jornada com a automação de testes pode começar.

Estruturas específicas da plataforma

Quando se trata de automatizar testes em aplicativos Android e iOS, há certas vantagens em usar estruturas específicas de plataforma em relação às plataformas cruzadas. Por exemplo, alguns frameworks são construídos próximos a SDKs e IDEs, que estão prontamente disponíveis enquanto um aplicativo está em desenvolvimento. Vejamos alguns exemplos desses tipos de frameworks para Android e iOS.

Robotium e ExtSolo (Android)

Robotium foi uma das primeiras estruturas de teste a funcionar para aplicativos Android nativos e híbridos. Os testes de interface do usuário criados com o Robotium permitem testes funcionais, de sistema e de aceitação do usuário para aplicativos Android, abrangendo e manipulando várias atividades do Android. Na verdade, Robotium oferece suporte para versões muito antigas do Android, a partir do nível 8 da API.

Recentemente, o Robotium foi estendido com a biblioteca ExtSolo, que fornece vários recursos úteis para testes de aplicativos:

• dimensionamento automático de cliques xey para qualquer resolução de exibição;
• arrastos de vários caminhos;
• captura de tela automática no momento da falha do teste;
• locais simulados (coordenadas GPS);
• alteração do idioma do dispositivo Android;
• controle de conexão Wi-Fi;

Com o código Java, os testes são fáceis de construir usando qualquer Java SDK e IDE. A função primária usada neste exemplo é findViewById , que localiza uma exibição identificada pelo atributo id . O elemento de interface do usuário também pode ser identificado por um nome, classe ou algum outro atributo. Nosso exemplo de código com um atributo id ficaria assim:

 solo.clickOnView(solo.findViewById("com.example.app:id/radio0")); solo.clickOnView(solo.findViewById("com.example.app:id/radio1")); solo.clickOnView(solo.findViewById("com.example.app:id/radio2")); solo.enterText((EditText) solo.findViewById("com.example.app:id/editText1"), "Simple Test"); solo.clickOnView(solo.findViewById("com.example.app:id/button1"));

Robotium aqui está tentando localizar elementos de interface do usuário com base no id , description e outras características. Infelizmente, essa nem sempre é a melhor abordagem e não necessariamente funciona bem com os componentes do webview. No entanto, com a ajuda da biblioteca ExtSolo, os usuários podem definir cliques e outras interações em elementos da interface do usuário que escalam com a resolução. Além disso, as coordenadas de codificação são possíveis, e elas são dimensionadas quando a resolução da tela muda.

Se você estiver usando o Robotium, começar com o Robotium ExtSolo é fácil e sem esforço. Basta clonar o repositório para você e construir a biblioteca:

 $ git clone https://github.com/bitbar/robotium-extensions $ ant clean instrument

Depois disso, coloque o arquivo .jar recém-criado na pasta libs do seu projeto Android Studio e certifique-se de que seu projeto esteja vinculado a ele. Todos esses ótimos recursos e serviços adicionais estão agora em seu espaço de trabalho.

Expresso (Android)

A estrutura de teste do Espresso fornece APIs para escrever testes de IU para simular as interações do usuário para um aplicativo Android. A API do Espresso é leve e fornece três componentes principais: viewMatchers , viewActions e viewAssertions .

A beleza do Espresso é que ele fornece sincronização automática de métodos de teste e elementos de interface do usuário que estão sendo testados. Por exemplo, se o script de teste quiser pressionar um botão, mas o botão ainda não estiver visível na tela, ele aguardará até que esse botão possa ser pressionado (ou seja, está visível e pode ocorrer um clique). Isso torna a execução do teste muito rápida porque nenhum script de teste precisa incluir nenhum comando de suspensão ou espera. Além disso, os desenvolvedores não precisam de lógica adicional para lidar com problemas relacionados ao tempo.

 // R class ID identifier for radio buttons onView(withId(R.id.radio0)).perform(click()); onView(withId(R.id.radio1)).perform(click()); onView(withId(R.id.radio2)).perform(click()); onView(withId(R.id.EditText1)).perform(click()); // Instead of R, we use getIdentifier onView(withId(getInstrumentation().getTargetContext().getResources() .getIdentifier("com.example.app:id/EditText1", null, null))).perform((typeText("Simple Test"))); onView(withId(getInstrumentation().getTargetContext().getResources() .getIdentifier("com.example.app:id/Button1", null, null))).perform(click());

O Espresso tem seus próprios prós e contras e, devido à API leve, não há muitos serviços adicionais ou chamadas de função disponíveis para os desenvolvedores. Por exemplo, você deve usar métodos alternativos para fazer capturas de tela, gerenciar testes, gerar resultados de testes e muito mais.

No Google IO 2016, o Google apresentou o Espresso Test Recorder como parte integrante do Android Studio. Embora o recurso ainda não esteja disponível, definitivamente valerá a pena esperar.

XCTest e KIF (iOS)

O XCTest está fortemente acoplado ao Xcode, mas ainda pode ser usado com dispositivos iOS reais e simuladores. O XCTest permite que os desenvolvedores escrevam testes para componentes em qualquer nível e também fornece uma estrutura para recursos de teste de interface do usuário. Os testes XCTest são agrupados em subclasses de XCTestCase. Escrever qualquer teste com XCTest deve ser trivial para desenvolvedores iOS porque XCTest é totalmente compatível com Objective-C e Swift.

KIF (abreviação de “keep itfunctional”) é uma estrutura de teste de integração do iOS que está intimamente relacionada e que usa destinos de teste XCTest. Os testes KIF podem ser executados diretamente no XCTestCase ou em qualquer subclasse. O KIF permite a fácil automação de aplicativos iOS, aproveitando os atributos de acessibilidade que o sistema operacional disponibiliza para pessoas com deficiência visual.

Vamos ver como nossos componentes de interface do usuário ficariam com Objective-C:

 - (void)testClicksOnRadioButtons { [tester tapViewWithAccessibilityLabel:@”Radio1”]; [tester tapViewWithAccessibilityLabel:@”Radio2”]; [tester tapViewWithAccessibilityLabel:@”Radio3”]; [tester enterText:@”Simple Test” intoViewWithAccessibilityLabel:@”editText1”]; [tester tapViewWithAccessibilityLabel:@”Answer”]; }

Alternativamente, com o Swift, o teste seria tão simples quanto isto:

 testClicksOnRadioButtons() { let app = XCUIApplication() app.radiobutton[0].tap() app.radiobutton[1].tap() app.radiobutton[2].tap() app.staticTexts[“Simple Test”] app.button[0].tap() }

Observe que esse pseudocódigo de alto nível requer código adicional para funcionar totalmente. Se você está procurando mais informações sobre o XCTest e geralmente sobre como usar os recursos de teste do Xcode, a Apple tem o que você precisa.

Earl Grey (iOS)

Foi apenas no início deste ano que o Google abriu o código-fonte de sua estrutura funcional de teste de aplicativos iOS, chamada EarlGrey. Sendo usado internamente pelo Google, funcionou relativamente bem com aplicativos iOS nativos – YouTube, Google Calendar, Google Photos, Google Play Music, para citar alguns – e despertou um interesse sério. Para começar com EarlGrey, você precisará do ambiente Xcode instalado e conhecimento básico de desenvolvimento iOS.

Existem muitas semelhanças entre EarlGrey e Espresso (sim, ambos são desenvolvidos pelo Google), e suas características fazem com que ambos os frameworks funcionem e executem testes rapidamente. Semelhante ao Espresso, os testes EarlGrey esperam automaticamente por eventos (animações, solicitações de rede, etc.) antes de tentar interagir com a interface do usuário. Isso torna a escrita de testes mais fácil porque os desenvolvedores não precisam se preocupar com os comandos sleep ou wait. Além disso, o próprio código é mais fácil de manter porque fornece descrições de procedimentos das etapas de teste.

EarlGrey também contém matchers que estão disponíveis na classe GREYMatchers. A documentação recomenda o uso de elementos de interface do usuário com os parâmetros de acessibilidade. Para identificar os elementos da interface do usuário, os desenvolvedores podem usar grey_accessibilityID() ou grey_accessibilityLabel() .

 - (void)testBasicSelectionAndAction { [[EarlGrey selectElementWithMatcher::grey_accessibilityID(@"ClickHere")] performAction:grey_tap()]; // Example of long press with EarlGrey matchers - (void)testLongPress { [[EarlGrey selectElementWithMatcher::grey_accessibilityLabel(@"Box")] performAction:grey_longPressWithDuration(0.5f)]; [[EarlGrey selectElementWithMatcher::grey_accessibilityLabel(@"One Long Press")] assertWithMatcher:grey_sufficientlyVisible()]; // Example of multi-select, visible click on items - (void)testCollectionMatchers { id visibleSendButtonMatcher = grey_allOf(grey_accessibilityID(@"Box"), grey_sufficientlyVisible(), nil); [[EarlGrey selectElementWithMatcher:visibleSendButtonMatcher] performAction:grey_tap()]; }

Semelhante ao XCTest, nossa implementação de botão de opção não é tão direta e os botões para XCTest devem ser definidos como UIElements com suporte para iOS para permitir cliques e interações do usuário.

Conclusão

Cobrimos o básico dos aplicativos React Native e como eles podem ser testados usando vários métodos e estruturas. Isso ocorre com bastante frequência, mas os padrões do setor para automação de teste móvel no nível de interface do usuário funcional funcionarão em aplicativos React Native da mesma forma que com qualquer outro aplicativo nativo. As estruturas de automação de teste que abordamos aqui são amplamente usadas para aplicativos móveis nativos, aplicativos híbridos, web móvel e aplicativos React Native.

Em resumo, determinar a linguagem de programação na qual um aplicativo móvel é construído não é crítico porque não terá nenhuma influência nas estruturas de automação de teste com as quais ele pode ser testado. Conforme discutido, muitas estruturas de automação de teste poderosas estão disponíveis hoje, com as quais os aplicativos React Native funcionarão quando agrupados como APK ou IPA.

O que você está usando para testar o aplicativo React Native? Pese com um comentário abaixo!