Behavior-driven Development no Windows 10 Mobile

Neste artigo vamos mostrar como realizar testes automatizados no desenvolvimento do seu aplicativo Windows Phone com o Behavior-driven Development.

Fique por dentro
Neste artigo vamos mostrar como realizar testes automatizados no desenvolvimento do seu aplicativo Windows 10 Mobile. Usaremos ferramentas open source que, combinadas, formam uma poderosa arma para entregar um software confiável e sem os famosos bugs de última hora que tanto impactam os prazos de produção. A discussão desse tema é útil no ciclo de desenvolvimento de um software para aplicar testes automatizados no processo de validação das funcionalidades do seu app, garantindo mais qualidade e confiabilidade nas entregas. Para implementar um teste automatizado foi criada uma aplicação utilizando o Visual Studio Community 2015 com Winium, SpecFlow e o pattern Page Object.

Implementar TDD (Test-Driven Development) em aplicações é uma prática recorrente, e automatizar testes para observar o comportamento das funcionalidades tornou-se uma etapa obrigatória no clico de vida de desenvolvimento de uma aplicação quando se quer entregar a mesma com o máximo de qualidade, principalmente quando é possível observar, inclusive, a experiência que o usuário irá ter ao navegar pelo aplicativo.

Como uma extensão natural do TDD, o BDD (Behavior-Driven Development — desenvolvimento guiado por comportamento) utiliza scripts com uma linguagem natural que são convertidos em testes executáveis. Seu foco principal é tornar a interação entre a área de negócio e a equipe técnica uma realidade. O resultado é uma relação mais aproximada dos critérios de aceitação de uma determinada funcionalidade, assim como dos testes utilizados para validá-la.

Como utiliza uma linguagem natural, inclusive considerando termos em português, torna-se fácil entender como implementar um script de testes no BDD. Alguns critérios são obrigatórios, mas no geral quem determina a sequência dos acontecimentos é o tester ou o desenvolvedor. No caso de metodologias ágeis, o PO (Product Owner — BOX 1) também pode ajudar a definir o que os testes devem cobrir.

BOX 1. Product Owner

Em desenvolvimento utilizando metodologias ágeis, o PO é o responsável pela lista de requisitos a serem desenvolvidos (backlog) e define para o time as prioridades durante os ritos de planejamento (planning) e retrospectiva (retro) e como isso será distribuído para os desenvolvedores nas sprints (interações). O time tem como guia esse backlog e suas prioridades para definir as entregas ao final de cada sprint.

O BDD segue um fluxo natural para um teste funcional e algumas etapas devem ser consideradas, como: onde começar, o que testar e o que não testar, o que testar de uma vez só, quais itens de tela devem ser considerados no teste e, quando esse falhar, entender o porquê dessa falha. Essas são regras básicas, mas não engessadas. Você pode e deve determinar aquilo que o seu teste vai executar. Teoricamente não existem limites para implementação de um BDD.

Ao rodar um teste específico, seu emulador será iniciado, instalará o app, irá executá-lo e chamará a funcionalidade que você pediu para ser testada. Tudo isso sem a sua interferência. Uma vez que o teste é concluído, o app é fechado e o foco volta naturalmente para a IDE. O resultado das operações é mostrado na janela Output do Visual Studio ou em um arquivo de log previamente configurado.

Parece ótimo, mas como fazer tudo isso acontecer? É o que vamos descobrir nos próximos parágrafos.

Durante as primeiras conversas de uma equipe de desenvolvimento para a elaboração da arquitetura de um aplicativo Windows Phone 8.1 (WinRT) de um banco multinacional aqui do Brasil, um dos assuntos que começou a incomodar o time, principalmente os arquitetos, foi: como vamos implementar testes automatizados no Windows Phone uma vez que não conseguíamos fazer o CodedUI conversar com o SpecFlow (ver BOX 2) para aplicações na plataforma WinRT? No .Net é possível realizar testes automatizados através do CodedUI, que está disponível no Visual Studio desde a versão 2010 (na versão Premium ou Ultimate). Porém, se você entrar no mundo mobile, mais especificamente no mundo Windows Phone, o cenário começa a complicar um pouco: o CodedUI simplesmente não consegue usar o SpecFlow, o que torna inviável a contextualização dos roteiros de testes. "

[...] continue lendo...

Artigos relacionados