Testes Automatizados de Software Na Visão De Um Desenvolvedor Android

Tudo bem?

Eu já inicio o artigo com algumas chamadas de software que você certamente já ouviu por aí:

• “Teste seu software é…”;
• “Sem teste unitário não é…”;
• “Você não testa porque…”.

Não sei se você pensa assim, mas no mundo ideal os testes de software, além de serem importantes, são de grande necessidade em qualquer projeto de aplicativo.

Mesmo eu sendo o autor do parágrafo anterior, eu confesso que se você é desenvolvedor solo, que no máximo trabalha sozinho em seu freela ou projetos pessoais…

neste cenário é provável que você tenha coisas mais importantes para estudar do que testes automatizados de software. E é assim mesmo como acabou de ler, independente do tipo de teste automatizado.

Isso pois no mundo real, quando em um roteiro onde você sempre é desenvolvedor solo, você certamente não passará pelos processos de Code Review e de Quality Assurance (QA) antes de ter o projeto “mergiado” no master branch.

Ok, Thiengo. Mas somente por causa do Code Review e do QA eu, um desenvolvedor solo, não vou me importar com o uso de testes em meus códigos Android?

Não somente por isso, mas principalmente devido a isso.

Basicamente (uma opinião minha), muitos dos desenvolvedores que começam a trabalhar também com códigos de teste é porque não têm outra saída.

Pois ao menos o developer responsável pelo Code Review, quando não é uma correção de bug. Esse responsável vai aguardar também os códigos de teste da funcionalidade que está para ser adicionada no projeto.

Eu confesso que não quero me prolongar muito nesse assunto. Sendo assim, mesmo que eu ache uma escolha nada inteligente, eu preciso dizer isso aqui:

Se você é desenvolvedor solo de aplicativos, provavelmente o assunto “testes de software” não lhe interessa.

Volto a dizer, em outras palavras: se a carapuça acima lhe serviu, então saiba que é uma carapuça infantil em termos de profissionalismo.

Pois não somente este artigo, mas muitos outros por aí… se for sobre testes de software, provavelmente vale o investimento de tempo e atenção.

Não sei se vai soar como reforço positivo, espero que sim. Mas saber testar, mesmo que seja somente teste unitário (que já é muito do caminho andado), vai, no mínimo:

• (Tentar) Ajudar a evitar que o projeto entre em estado “legado”;
• Fazer você evoluir como coder, principalmente em como trabalhar de maneira simples e eficiente a separação de conceitos. E em minha opinião o assunto SEPARAÇÃO DE CONCEITOS É MAIS IMPORTANTE DO QUE TESTES.

Dito isso…

estou feliz em anunciar que finalmente eu fui até o fim (incluindo a reprodução dos exemplos) de um livro da Casa do Código.

Não sei você, mas quando o assunto é “testes automatizados de software” eu faço parte do grupo de desenvolvedores que aprendeu a testar software “na rua”, “no mundão lá fora”.

Ou seja, eu aprendi a testar algoritmos por meio de artigos e vídeos online. Na martelada.

Mesmo tendo graduação e pós-graduação. Em sala de aula eu me lembro de ter ouvido alguém somente ter comentado sobre testes de software. Nunca foi matéria e nem mesmo tópico de estudo.

É, eu sei. Soa bem herege, mas é verdade.

Neste caso eu não vou generalizar. Pode ser que tenha sido um “bug” somente na minha turma.

Ok, Thiengo. Mas sem rodeios, por favor. Por que agora essa necessidade de também ler livros sobre testes de software? Principalmente sabendo que a documentação oficial do Android já tem o “bê-a-bá” sobre testes de aplicativos.

Antes de responder, tome muito cuidado com isso:

“… a documentação oficial do Android já tem o 'bê-a-bá' sobre testes de aplicativos.”

Não. Isso não é verdade. A documentação oficial tem bastante conteúdo sobre testes. Mas ela é bem prática, abordando quase que nada de teoria sobre testes.

E… a doc oficial, pela abordagem adotada, já assume que o leitor tem uma mínima expertise em testes automatizados de software.

Aquela documentação de testes do Android, na minha opinião: não é nunca para um desenvolvedor que está apenas iniciando no assunto.

Voltando à pergunta principal…

“Por que agora essa necessidade de também ler livros sobre testes de software?”

Principalmente devido ao projeto Android mais recente que faço parte. Eu vi a necessidade de formalizar as coisas.

Ou seja, buscar por conteúdos mais apurados sobre testes de software. Conteúdos de profissionais que são especialistas na área.

E o autor Maurício Aniche fez sim um excelente trabalho no livro “Testes Automatizados de Software - Um guia prático”.

O livro é curto, 166 páginas. Contém muito conteúdo prático (bem direto ao ponto). E com uma abordagem suficiente para aqueles que estão buscando um conteúdo um pouco mais explicativo sobre testes de software.

E quando eu digo “para aqueles que estão buscando um conteúdo um pouco mais explicativo…” eu estou dizendo: para desenvolvedores Android que são no mínimo developers júnior já com um pé no desenvolvimento pleno.

Ou seja, desenvolvedores que já são bem astutos em termos de desenvolvimento de aplicativos Android com o Android Studio IDE.

Por que isso, Thiengo? Eu ouvi dizer que este livro é também para iniciantes em Java (Kotlin).

Sim, é possível que você tenha ouvido isso. E, com total segurança, eu informo que: NÃO.

Este não é um livro para iniciantes em desenvolvimento de apps.

Primeiro porque o assunto “teste de software” já é por si só um assunto considerado avançado no desenvolvimento Android.

Basta você se inscrever no curso Kotlin Android oficial do Google que você vai ter a parte de testes de software como um dos tópicos finais no trecho “Avançado” desse curso.

Segundo porque quando você está estudando testes, os autores tendem a ter abordagens do conteúdo já assumindo que você tenha ao menos o domínio da orientação a objetos e da configuração de plugins, bibliotecas e outros artefatos em projeto. Além da facilidade de trabalho com o IDE.

Por exemplo, no livro “Testes Automatizados de Software” não há nenhuma parte onde o autor mostra como configurar as bibliotecas de testes sendo utilizadas.

E eu não vejo isso como algo negativo no livro.

Pois o assunto “testes automatizados” é para desenvolvedores que não terão problemas em correr atrás e configurar por eles mesmos as ferramentas apresentadas em livro.

O Maurício, mesmo que de maneira implícita, somente fala da biblioteca de teste sendo utilizada no código de exemplo e, em algumas poucas vezes, também fornece a URL de acesso à biblioteca.

Não posso omitir isso aqui… no livro tem também o endereço do repositório do projeto principal utilizado no título.

Mas eu confesso que prefiro seguir codando do zero, a partir do que tem nas páginas do livro. Sendo assim, eu nem mesmo acessei o repositório.

De qualquer forma, seguramente eu indico este livro para você que quer saber testar software com um pouco mais de formalidade, teoria. Mesmo que seja ao menos para entender melhor os jargões do mundo dos testes de software.

Não vejo problemas em lhe informar que os principais testes abordados no livro são os seguintes:

• Testes unitários;
• Testes de sistema;
• Testes de integração (com banco de dados).

O ponto alto do título é sem sombra de dúvidas a cobertura do Mockito (ainda na parte de testes unitários).

Eu confesso que eu não conhecia o ArgumentCaptor (na “rua” que eu aprendi a utilizar o Mockito não falaram sobre o captor).

E já lhe aconselho a tomar certo cuidado se você for reproduzir os testes com o Mockito utilizando o Kotlin.

Pois diferente do Java, no Kotlin as classes não abstratas são final e têm suas propriedades e métodos também com a assinatura final.

Sendo assim, utilizando o Kotlin, passe a reproduzir os testes com o Mockito-Kotlin ao invés do Mockito apenas. Caso contrário você literalmente vai ter que alterar o design do seu código.

Outro ponto de destaque do livro é o uso do Selenium para testes de sistema.

Eu já conhecia o Selenium, mas lá na época em que eu pouco me importava com testes.

O Maurício foi muito bem na apresentação desta ferramenta, no passo a passo de uso dela. Incluindo testes com formulários de processamento Ajax, processamento assíncrono.

Agora a parte chata, os pontos negativos…

os que eu encontrei no livro pouco têm relação com o conteúdo em si.

Vamos lá.

Primeiro, acredito que o autor poderia ter abordado algo sobre o uso de separação de conceitos, projeto bem dividido em camadas, para facilitar também os mais diversos tipos de testes.

Até porque são principalmente os testes que mantém o bom funcionamento do software e o livra de se tornar um software legado (ao menos tenta fazer isso).

O autor simplesmente não comenta nada sobre a importância da separação de conceitos.

Nem mesmo como essa abordagem em desenvolvimento afeta positivamente os testes e como os testes também, mesmo que de maneira implícita, ajudam a manter uma boa separação de conceitos.

Segundo ponto que acredito ter faltado no conteúdo, principalmente sabendo que os códigos de exemplo são todos em Java, foi…

o uso da API de reflexão da linguagem. Muito por causa dos testes unitários de entidades (métodos e propriedades) não públicas.

Eu sei que o autor aborda bem o uso do Mockito. Mas em alguns cenários a API nativa de reflexão lhe fornece um meio mais simples e rápido para testes unitários.

Depois que você aprende a utilizar a API de reflexão em códigos de testes automatizados, você passa a perceber que o uso de Mockito (ou Robolectric) em alguns cenários de testes é o equivalente a “caçar formigas com fuzil”. E é literalmente caçar formigas faraó (aquela formiga bem pequena de açúcar).

De qualquer forma, a falta desses dois assuntos não atrapalha em absolutamente nada no custo benefício do livro. E estou falando da versão mais cara, a versão física.

O que realmente deixou muito a desejar… e essa crítica é construtiva e diretamente aos editores da Casa do Código… foi a qualidade da formatação do conteúdo.

Aparentemente o livro teve todo o conteúdo retirado de um curso de testes de software da Caelum.

Em inúmeros pontos o livro tem algo similar a “como já informado aqui no curso”.

E aparentemente foi somente isso: retirado de um curso. Pois a princípio não houve curadoria do conteúdo, da gramática. Há muitos erros de português.

Os códigos basicamente têm a mesma formatação do texto corrido, dificultando consideravelmente o estudo de cada um deles:

Eu tenho alguns livros publicados, todos digitais. De qualquer forma, eu me sinto com certa autoridade em informar que, formatar o conteúdo é a parte mais simples.

Isso, pois é a parte mecânica da construção de um livro, não é preciso pensar. É trabalho braçal.

A seguir a formatação de um de meus livros (e eu tenho certeza que tem muito a melhorar):

Então, novamente “puxando a orelha” da Casa do Código:

Unicamente devido à formatação do livro, o título passa então ao estado “não vale o que está sendo cobrado”.

Para finalizar…

mesmo devido às críticas que fiz em relação à formatação do livro, mesmo assim, se você é desenvolvedor Android e estiver buscando por algo mais explicativo sobre o assunto “testes automatizados de software”.

E assumindo que você não é um completo iniciante no Kotlin Android. Então vale o investimento.

E não deixe de reproduzir ao menos os testes unitários apresentados no livro. Eu utilizei o IntelliJ IDEA CE para a reprodução dos códigos e não o Android Studio. E foi tudo bem tranquilo.

E agora… só por questão de curiosidade:

Eu estava aguardando o término da leitura de “Testes Automatizados de Software” para saber se eu deveria ou não investir em um outro título de testes do mesmo autor, desta vez um título sobre Test Driven Development (TDD).

E neste momento eu estou aguardando a entrega do livro sobre TDD do Maurício Aniche.

Bom, é isso.

Se você já leu o livro “Testes Automatizados de Software” e tem uma opinião diferente. Ou se você tem dicas de outros bons livros de testes… então não deixe de comentar logo abaixo.

E não se esqueça de se inscrever na lista de e-mails do Blog 📩  (que é gratuita) e assim passar a receber também os conteúdos exclusivos que eu disponibilizo somente por lá.

Abraço.

Relacionado

Construa Um Aplicativo Android Completo Para YouTubers - Parte 1Android

As Leis Fundamentais Do Projeto De Software Na Visão De Um Desenvolvedor AndroidAndroid

5 Coisas Que Eu Aprendi Com Desenvolvedores Autores EstrangeirosAndroid

Como Ser Um Programador Melhor Na Visão De Um Desenvolvedor AndroidAndroid