Testes em Android – Parte I: Por onde começar?

Fala, Comunidade! Este post é o primeiro de uma série sobre testes em Android. Você aprenderá conceitos essenciais sobre a arquitetura de testes, instrumentação e como configurar o seu projeto no Android Studio para começar a automatizar seus testes unitários e de UI. Nesse primeiro post, irei focar apenas em testes unitários utilizando a ferramenta JUnit. Como ele é de assunto intermediário, caso você seja iniciante em Android, sugiro este post onde falo passo a passo como começar o desenvolvimento de apps no Android Studio.

Por que devo testar?

Nos dias de hoje, onde temos vários serviços e plataformas de Integração Contínua (Continuous Integration) gerando builds a todo vapor como Jenkins, Travis CI, Circle CI, BitBucket Pipelines, testar é algo essencial e obrigatório para que consigamos montar uma cultura de desenvolvimento ágil e de Entrega Contínua (Continuous Delivery) de produtos de qualidade para nossos clientes.

Continuar lendo

Anúncios

Seu projeto não tem testes? Pior pra ele

Olá pessoal! Esse é o meu segundo post aqui no blog do Tá Safo! e desta vez vou falar sobre testes e TDD que é um tema ainda pouco discutido pela região.

Bem, eu vejo em muitos lugares, inclusive em gerências de projetos por ai que uma tarefa é dividida nos seguintes estágios: A Fazer, Fazendo, Testando, Homologação e Pronto.

A primeira é quando a funcionalidade ainda está a espera de ser implementada, a segunda é quando alguma criatura começa a produzir a tarefa (que no nosso caso, é o código). Então, após ser implementado ele será testado para depois ser aceito pelo cliente e pronto, fim de papo.

Sempre que assisto a alguma palestra ou converso com alguém sobre o que este teste realmente quer dizer, ouço que é alguém dedicado a usar o software para saber se a funcionalidade feita está de acordo com o esperado e/ou funcionando.

Cruzes! Toda vez que escuto isso me dá um frio na espinha, sério. Primeiramente, existe uma pessoa dedicada para isso. Segundo, o teste é feito manualmente. Terceiro, o teste é feito DEPOIS que o código é escrito.

Óbvio, hehe, o terceiro ponto pareceu muito esquisito. Não tem como testar a função antes dela ter sido implementada. Quebremos, então, este paradigma.

Continuar lendo

Melhorando a qualidade dos testes com refatoração e fluent interfaces

Muita gente acha que não precisa dar muita atenção à qualidade na escrita dos testes. Mas o nível de qualidade dos testes deve ser tão alto quanto o do código de produção, afinal, os testes também tem que ser mantidos por tanto tempo quanto o código de produção. No seu livro Clean Code, Uncle Bob conta a história de uma equipe que decidiu abrandar as regras de qualidade nos testes. Traduzindo livremente:

As variáveis não tinham que ser bem nomeadas, os métodos não tinham que ser pequenos e descritivos. O código de teste não tinha que ter um bom design. Contanto que o código de teste funcionasse e cobrisse o código de produção, estava tudo bem.

Quanto mais o tempo passava, mais difícil era alterar os testes e adicionar novos. Vez ou outra alguns testes falhavam quando a equipe mudava o código de produção, e corrigi-los também se tornou uma tarefa árdua e demorada. As estimativas ficaram cada vez mais altas, porque mexer nos testes era muito custoso. Depois de um tempo, eles jogaram fora toda a suite de testes. Mas sem os testes, muitos bugs começaram a aparecer, a equipe perdeu a confiança em alterar o código, e no final, clientes e desenvolvedores ficaram frustados.

Moral da história, se o código será mantido – seja de produção ou de testes – então ele tem que ser bem escrito.

Continuar lendo