Por mais que muitos devs conhecam a importância dos testes automatizados e principalmente os testes unitários, ainda é raro encontrar empresas que abraçaram a cultura de testes, onde entregar uma feature com testes unitários é algo imprescindível.

Esse é um cenário ainda muito comum onde temos duas hipóteses: ou os devs não escrevem testes unitários na sua empresa ou não prosperou essa cultura. Isso ocorre frequentemente pela falta de referências na empresa, ou simplesmente porque os lideres etc., acreditam que a entrega contendo testes possam afetar o prazo de entrega de uma tarefa.

Se esse for o caso da segunda hipotese, então temos um grande problema. Convencer o seu líder que entregar tarefas com testes unitários pode trazer grandes benefícios para o time e para a entrega pode ser uma tarefa árdua, e é algo que esse artigo não vai englobar. Até porque eu não passei por isso 😆.

Bem, no meu caso foi um cenário um pouco diferente, ao tomar a iniciativa de trazer a cultura de entrega de tarefas contendo testes unitários. Pudi perceber que anteriormente já tinha-se tentado implementar essa cultura, no entanto, não vingou. Talvez pelos seguintes motivos:

• Os testes unitários anteriormente implementados, não testavam de fato as funcionalidades. Pude perceber que escreviam os testes apenas por escrever.
• Isso se deu provavelmente pelo fato de não se ter uma referência de boas práticas para escrita de testes no time, assim ocasionando em testes sem sentido.
• Por fim, abriram mão da escrita dos testes unitários e começaram a entregar as tarefas sem cobertura de testes. Talvez por não se ter uma boa orientação para escrita de testes, ou por decisão da liderança. Acredito que tenha sido pelo primeiro motivo.

Então como trazemos essa cultura de testes unitários para nossa equipe? Irei falar um pouco sobre o passo a passo que seguimos para retomar com essa cultura de testes unitários.

1. Primeiramente, porque se perdeu essa cultura de escrita de testes? Como podemos nos planejar para retomar essa cultura.
2. Sua equipe possui o conhecimento necessário para escrever testes unitários que realmente façam sentido?
3. Agora que todos os devs da equipe possuem um certo conhecimento sobre testes, como podemos manter essa cultura?

Primeiramente, porque se perdeu essa cultura de escrita de testes? Como podemos nos planejar para retomar essa cultura.

A primeira coisa que devemos fazer é se perguntar porque hoje o time não escreve mais testes unitários. Bem, como já mencionado, no meu caso o motivo é incerto, pude perceber que os testes unitários que continham no projeto não testavam de fato as funcionalidades, e ao conversar com a equipe percebi que a grande maioria não tinha conhecimento sobre testes automatizados. Então obviamente devemos começar por aí.

Antes de começarmos a escrever os testes unitários de fato, devemos pensar como podemos engajar o time para que todos tenham capacidade de começar a escrever testes.

Então ai de fato demos o primeiro passo para trazer essa cultura para o time. Conversando com alguns membros do time, decidimos que a melhor maneira seria implementar os testes unitários em alguma feature que já estava pronta e prestes a ser entregue. O objetivo seria cobrir essa feature de testes unitários e trazer para o time as dores sentidas e a experiência ao testá-la.

O resultado não podia ser diferente, a experiência ao cobrir essa feature de testes unitários trouxe para o time uma boa referência de como deve ser testado um componente, uma classe, função etc. Além disso, nos possibilitou construir uma padrão para que o time pudesse seguir, conseguimos corrigir os testes que antes estavam quebrando e por fim, conseguimos gerar uma documentação bem detalhada contendo uma boa base teórica, exemplos, conceitos e claro o código em si onde foi feito o experimento na feature 🥳🎉.

Sua equipe possui o conhecimento necessário para escrever testes unitários que realmente façam sentido?

Após termos uma boa base e referência para que o time possa começar a escrever testes unitários, ainda tinhamos uma questão, será que o time está realmente preparado para escrever testes?

Após fazer essa reflexão, percebemos que não. Então o próximo passo foi realizar um Workshop sobre testes automatizados focado principalmente na escrita de testes unitários. Esse workshop foi desde a base teórica até a mão na massa, escrevendo testes em conjunto, e o melhor de tudo que a apresentação foi totalmente baseada na documentação que tínhamos escrito anteriormente. Bem, o resultado foi incrível, foram separados dois dias para realizar o workshop durante o nosso horário de trabalho. Ocorreram muitas trocas de ideias, opiniões, debates etc.

Com todo esse processo, acredito que agora realmente o time estava pronto para entregar suas tarefas contendo os testes unitários.

Agora que todos os devs da equipe possuem um certo conhecimento sobre testes, como podemos manter essa cultura?

Foi um processo longo de desenvolvimento, preparação do time para que possamos englobar os testes unitários em nossas entregas. Mas como podemos manter essa cultura para que ela possa se manter e enraizar-se na equipe?

Para essa pergunta eu não tenho a resposta certa, talvez estejamos ainda nessa etapa. O que posso compartilhar com vocês é:

Para os que abraçaram a ideia de entregar as tarefas com testes unitários, tem-se observado os benefícios que os testes trazem. Por mais que tenha-se aumentado o tempo de entrega das tarefas, aos poucos o time tem se acostumado a escrever testes unitários.

Isso é muito bom. Mas para isso, precisamos que alguém carregue essa responsabilidade de manter o time engajado e trazendo os resultados das entregas contendo testes unitários. De inicio você precisa carregar essa responsabilidade e continuar incentivando os demais membros do time. Esse é um processo lento, mas aos poucos o time vai se acostumando a realizar essas entregas. Por fim, aos poucos vamos melhorando essa cultura até que ela se estabilize de fato e todas as entregas só sejam feitas com cobertura de testes.

Essa foi a forma que encontramos de trazer essa cultura para o time, com certeza será um processo longo, mas que pode trazer grandes frutos para o desenvolvimento pessoal do dev e mais confiança na entrega da equipe.

Valeu galera, até a próxima.