Devo criar testes automatizados?
Sim, testes automatizados são a única forma realmente segura de provarmos que nosso código funciona. É fantástico para manutenção, refatoração e especialmente para a experiência de trabalho do programador.
Devo testar 100% do código?
É algo que se deve ser perseguido sim, não como utopia, pois é possível sim alcançar 100% de cobertura de testes em diversos contextos. Mas em termos de processo, especialmente de capacidade técnica e maturidade profissional, pode demorar, então, o importante é testar e avançar.
Estou começando agora com programação. Devo já começar com testes automatizados?
Não. Pelo seguinte, no início, nós estamos aprendendo a nos comunicar com o computador, aprendendo a usar os recursos da linguagem, é muito exigente querer que alguém em início de carreira consiga já iniciar com testes.
Isso é possível somente em um contexto, quando o iniciante tem um profissional maduro lhe fazendo mentoria e este profissional mais experiente prepara o ambiente de testes e ensina o iniciante a usar. Nesse contexto é muito útil já iniciar com testes.
Fazer testes torna a programação mais difícil?
No início sim, no longo prazo, facilita. Acontece que a maior dificuldade ao trabalhar com testes automatizados é que a melhor forma de testar é realizando testes unitários e realizar testes unitários exige código desacoplado. E criar código desacoplado é difícil para um iniciante.
Somente após algumas interações com programação um iniciante começa a ter o discernimento adequado para construir boas unidades de código para serem testadas.
Isso sem considerar conceitos abstratos como mocks e a capacidade de lidar com questões comuns em testes como geração de números aleatórios, trabalho com datas, uso de sistemas de arquivos, etc.
Mas os testes com Selenium? Não resolvem isso?
Se um iniciante aprende a programar criando testes de alto nível, como testes funcionais completos com ferramentas que simulam um navegador ele está aprendendo pelo topo e não pela base da pirâmide de testes.
O problema dessa abordagem (além de ser difícil para um iniciante programar estes recursos) é que ela pode viciar muito cedo o programador em um estilo de teste de software que embora muito valioso, provoca muitos falsos negativos, pode provocar falsos positivos, é extremamente lenta e muito inadequada para depurar um bug, embora funcione bem para localizar grandes problemas.
Mas então um iniciante não deve testar seus softwares?
Claro que deve, mas manualmente, de preferência aprendendo a criar no papel ou em documentos de texto ou planilhas casos e cenários de teste.
O primeiro aprendizado deve ser a clareza mental do iniciante sobre o que precisa ser testado e aprender a fazer isso manualmente.
Isso é importante para treinar a mente em duas etapas fundamentais em qualquer processo de testagem. O setup e a checagem. O setup é aquele trabalho imenso em algumas features de preparar todo o ambiente de dados para o teste de uma feature. A checagem é a execução do processo em busca de um sucesso ou fracasso.
Com essa experiência o programador passa a compreender melhor o tamanho de uma feature, a imensa quantidade de casos de teste que podem surgir de algo que parece simples, e como confirmar o sucesso ou fracasso de uma feature.
Mas o que acontece se um iniciante tenta testar desde o início?
Frustração. O nível de abstração é mais alto no teste automatizado, as dificuldades de preparação de ambiente também. Reforço que se houverem mentores por perto, pode iniciar com testes automatizados que vai ser bom. Mas sem mentores o processo gera um volume tão grande de dor e frustração que podem levar a perda da diversão e alegria de programar.
E quando o iniciante deve começar a automatizar seus testes?
Imediatamente após começar a se sentir confiante com os códigos que precisa escrever.
Quando, ao receber uma tarefa o dev já consegue imaginar de forma geral o código que precisa construir e os cenários de teste principais, ele está pronto para o desafio de iniciar com testes automatizados, seja usando TDD ou fazendo os testes após o código. Não importa tanto no início, embora cada vez mais eu goste de TDD.
Eu sugiro assim porque, ao já saber se comunicar com o computador, será mais fácil, diante da dificuldade em automatizar algo, encontrar caminhos alternativos de depuração do problema, será mais fácil abstrair ideias e conceitos mais elaborados comuns em ferramentas de testes e mais fácil também quebrar um código em partes menores para ter um resultado melhor.
Deve-se pedir ao chefe ou para a chefe tempo para criar testes automatizados?
Não. Se o chefe ou a chefe for não-programador, será muito difícil para eles avaliar a relevância desse pedido. Se a liderança é tem competência em programação e tiver hábito de testar, isso já vai ser pedido de primeira, se não tiver, ele ou ela podem ser resistentes.
Você deve testar, quando se sentir já mais preparado, como parte integrante da tarefa desde o início.
Por exemplo, é bom controlar a ansiedade de dizer que a tarefa está pronta assim que o recurso funciona e sempre dedicar uns 10% ou 20% de tempo ao final para refatorar e caso não tenha feito TDD, adicionar mais alguns testes.
Esse processo vai adicionando qualidade nas suas entregas, menos erros, mais assertividade e naturalmente você passa a ser visto ou vista como um profissional que faz um bom trabalho. E ninguém precisa saber o segredo do seu sucesso.
Mas aí deve-se automatizar 100% nesse momento?
Não. Você pode, preferencialmente, criar um incremento gradual na sua cobertura de testes, iniciando com uma ou duas funções isoladas com um algoritmo bem definido. Aumentando para as classes mais importantes. Assim que possível adicionando também testes de integração com o banco de dados além dos unitários e um ou outro teste funcional com Selenium. É aos poucos. Sempre com maior ênfase em crescer testes unitários primeiro e aí ir adicionando mais.
Testes são a ferramenta mais importante de um programador
Com o tempo, você notará que programar sem testes se torna uma operação muito custosa e cansativa. Você sente falta do rápido feedback que você tem quando utiliza testes automatizados.
Existem muitas justificativas pelas quais uma empresa deve adotar testes automatizados.
Mas eu quero trazer que no meu ponto de vista, isso não deveria ser relevante para você e para mim como profissionais.
Como profissionais, testes devem ser algo que nos traga alegria, prazer e confiança no trabalho, e independente do que a empresa valoriza ou não, nós devemos adotar (progressivamente) a capacidade de criar testes automatizados como uma ferramenta individual primeiro.
Mas fecho insistindo que você, programador ou programadora iniciante, não se cobre tanto. Criar e especialmente manter bons testes dentro de um sistema é uma tarefa tão difícil quanto criar o código principal de produção e como tal exige experiência, paciência e disciplina.
Sucesso pra gente.!