Behavior-driven Development no Windows 10 Mobile

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.

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.