Calabash descontinuado… E agora?

Postado 5 de maio de 2017

No final de 2016, aqui na Youse, passamos por um processo onde substituímos o framework de testes Calabash por XCUITest nos testes iOS e, no Android, o trocamos por Espresso. Após avaliarmos os prós e os contras, chegamos à conclusão que os benefícios de utilizar soluções nativas no lugar de terceiros justificaria a mudança.

Nossas primeiras versões da solução de automação da equipe mobile utilizavam o Calabash. O uso de BDD como mecanismo de escrita dos testes e a linguagem Ruby o tornavam atrativos pela sua facilidade em aprender e estender. Outro ponto era que o mesmo conjunto de testes podiam ser executados no iOS e Android, caracterizando um ótimo exemplo de DRY (Don’t Repeat Yourself).  

Frameworks como o Calabash ou o Appium foram de extrema importância para alavancar o desenvolvimento da área, a ponto de estimular os grandes nomes de sistemas mobile a alcançarem o amadurecimento de suas próprias soluções nativas. Isso nos fez rever a necessidade da dependência ou suporte de um sistema terceiro (em recente anúncio em sua lista e-mail, a Xamarin informou que o Calabash não receberá mais atualizações).

O primeiro grande desafio que precisava ser entendido era a necessidade de manutenção de duas pilhas de código (uma para cada sistema mobile) em vez da pilha única do Calabash. Porém, concluímos que a aparente vantagem do sistema terceiro neste quesito se perdia à medida em que as aplicações-alvo desenvolvidas se distanciavam devido às funcionalidades específicas para cada plataforma, como navegações e recursos visuais modificados para ficar de acordo com os guias de design e usabilidade da Apple e do Google. Isso causava um excesso de condições específicas para cada uma, com fluxos próprios para Android e iOS, diminuindo a legibilidade e, consequentemente, a manutenabilidade do código.

Um fator que contribuiu para a evolução das bases de código usando frameworks nativos foi a adoção do mesmo ambiente de desenvolvimento (como a IDE e linguagem de programação) entre desenvolvedores e QAs, permitindo que todo o time pudesse colaborar com a manutenção dos mesmos. Esta integração é muito importante não só no sentido quantitativo, o que traz mais “mãos e olhos”, como também para aumentar a percepção de que os testes são parte integrante do produto final. Agora é comum desenvolvedores participarem das revisões e da escrita dos testes automatizados, pois não há mais a necessidade de conhecimento de frameworks e linguagens além daqueles usados no dia a dia.

O lançamento de novas versões dos sistemas mobile já não trazem a ansiedade de ter que esperar os sistemas terceiros se adaptarem, pois envolvem também atualizações e retrocompatibilidade para os frameworks de teste nativos.

Além disso, houve um grande ganho no tempo de execução. Hoje temos uma suite de testes no Android que leva 8 minutos para gerar seus resultados, enquanto uma suite equivalente, no sistema terceiro, levava cerca de uma hora.

Os testes foram escritos em ambas as plataformas e o padrão de projeto PageObjects, que aumenta a abstração na escrita dos casos de testes e o reaproveitamento de código, foi mantido. Hoje temos suites de testes automatizadas com uma maior estabilidade, desempenho e longevidade. #GoYousers <3

Em posts futuros, compartilharemos mais detalhes de como esse processo foi ocorrendo e as dificuldades que encontramos.

                                                                                           Augusta Marques