Neste artigo abordaremos de maneira teórica e prática os benefícios do desenvolvimento baseado em testes, explorando a API de testes de unidade e de activities que o SDK do Android disponibiliza.
Em que situação o tema é útil:
O artigo é útil para o profissional que está interessado em desenvolver aplicativos para o Android e deseja se beneficiar da produtividade e qualidade que o desenvolvimento baseado em testes pode gerar.
Resumo DevMan:
O Android é um sistema operacional para dispositivos móveis que atrai usuários e desenvolvedores no mundo inteiro. Esse artigo aborda os recursos dessa plataforma referentes à criação de testes de interfaces gráficas (Activities), além de demonstrar os tradicionais testes de unidade, reforçando a ideia do quão importante essa prática é no desenvolvimento de software, independente da plataforma ou tecnologia que se utiliza.
A Engenharia de Software evoluiu bastante nos últimos anos. Há pouco tempo, siglas como TDD (Test Driven Development) e BDD (Behavior Driven Development) eram desconhecidas de toda a comunidade de desenvolvimento. Neste período, os testes não eram prioridade, e ao implementar uma funcionalidade, o desenvolvedor realizava o teste manual, direto no sistema.
Hoje em dia, um desenvolvedor profissional constrói uma coleção de testes para garantir que cada trecho do código funcione sem falhas. Desse modo, aumentamos a qualidade do software que está sendo produzido. Com essa prática, garantimos que o sistema tenha uma longa vida útil, pois o desenvolvedor que efetuar modificações (no futuro) terá como saber se as mudanças realizadas por ele refletiram negativamente em algum ponto do sistema, através dos testes.
Entretanto, os benefícios dos testes automatizados vão além do que prover segurança a novas implementações. Assim, no decorrer desse artigo, apresentaremos todas as benfeitorias que o desenvolvimento baseado em testes pode trazer para um projeto, em especial, aos voltados para o Android.
Os testes são fundamentais, pois sem eles, refatorar algum trecho de código ou implementar uma nova funcionalidade pode se tornar uma tarefa perigosa, independente do modelo de arquitetura utilizado no projeto.
Esse cenário pode piorar se um profissional novo é integrado à equipe. Neste caso, o nível de insegurança é maior, e isso acontece porque o desenvolvedor pode não conhecer totalmente as regras e a arquitetura da aplicação. Se não existirem testes de unidade, ele não poderá saber rapidamente se todas as suas implementações ou alterações impactaram somente de maneira positiva no sistema.
Em uma situação onde o sistema fique sob a responsabilidade de uma nova equipe, a falta dos testes pode prejudicar ainda mais, pois os testes bem escritos acabam se tornando mais uma fonte de informação para a equipe que acaba de assumir o projeto. É como se ela recebesse um novo documento que indica como cada método e bloco de código deve se comportar. Portanto, podemos deduzir que se os testes do projeto estão ruins, a capacidade de modificar o código fica prejudicada, resultando em uma aplicação degradada, com altos índices de falhas. Por esses motivos é importante que o engenheiro de software não trate os testes como uma tarefa trivial do processo de desenvolvimento do sistema, mas como uma ação que exige cautela, raciocínio e planejamento, assim como escrever códigos funcionais da aplicação.
Por que escrever os testes primeiro?
Nos últimos anos, muito tem se falado da prática de escrever testes antes mesmo do que o próprio código que será testado. A seguir, são expostos alguns itens que demonstram porque escrever código de teste primeiro é importante:
• Ao escrever o teste antes da codificação, o desenvolvedor tem mais uma chance de analisar o problema sob uma nova perspectiva. Com isso, ele tem a possibilidade de encontrar a solução que melhor o atenda;
• Sem escrever os testes antes da codificação, o desenvolvedor cria uma brecha para escrever um código que dificulte a escrita de um teste de unidade;
• Sem essa prática, as chances de se esquecer de implementar os testes para aquela etapa do sistema aumentam, fazendo com que a quantidade de código não testado do projeto também aumente.
Como escrever um bom teste?
Assim como um código de produção, os testes de unidade devem ser escritos de forma a serem facilmente compreendidos. Apesar disso, é comum encontrarmos códigos de teste enormes, com classes e casos de teste com inúmeras responsabilidades. O desenvolvedor deve saber que um código de teste mal escrito contribui para a degradação do sistema, assim como uma má implementação de um código de produção. Portanto, também é importante escolher bem os nomes de variáveis e métodos para favorecer a leitura.
Além de testar apenas uma funcionalidade em cada método de teste, o profissional deve sempre se lembrar de que os princípios, boas práticas e padrões devem ser usados em todos os pontos do sistema. Fazendo isso, além de contribuir com a qualidade do mesmo, o código de teste se torna um valioso documento que indica o comportamento do sistema, facilitando a familiarização de novos membros da equipe com aquele projeto.
Cinco regras essenciais para os testes automatizados
No livro “Código Limpo”, o autor Robert C. Martin define cinco leis básicas para a criação de um bom teste automatizado. Estas “normas” servem para amenizar a possibilidade dos códigos de teste serem abandonados com o desenrolar do desenvolvimento. Acredita-se que se o desenvolvedor seguir todas elas, obterá todos os benefícios que os testes podem oferecer. Abaixo, seguem as “regras”:
• Rapidez (Fast): Os testes devem ser executados com rapidez. Caso a bateria de testes demore, o desenvolvedor não vai querer executá-los frequentemente, o que pode ocasionar no abandono dos testes;
...
