Dificilmente passa uma semana sem que alguém diga isso. Em uma palestra, em um post de blog, no LinkedIn, onde quer que seja.
E eu concordo. Você deve tratar seu código de teste como seu código de produção. O problema é que apenas dizer que você deveria não faz isso acontecer magicamente, da noite para o dia. Infelizmente, os momentos em que vejo a pessoa proferindo essa declaração realmente seguindo-a com dicas acionáveis sobre como tratar seu código de teste como código de produção são muito, muito menos e mais distantes.
Portanto, nesta postagem do blog, gostaria de compartilhar algumas medidas que acho que toda equipe que realmente deseja tratar seu código de teste como um cidadão de primeira classe deve tomar. Alguns deles são mais ‘técnicos’ por natureza, alguns deles se concentram mais na maneira como o código é escrito e mantido, mas todos eles são importantes, se você me perguntar.
Controle de versão
Isso, para mim, é um acéfalo. Se seus testes não estiverem sob controle de versão, eles não existem. A menos que você armazene seus testes no Git ou em qualquer outro sistema de controle de versão que queira usar, não há como trabalhar efetivamente neles junto com seus colegas de equipe e não há como tornar o próximo ponto possível no primeiro Lugar, colocar.
Além disso, a menos que você ‘goste de viver perigosamente’ e esteja bem com o risco de perder todo o seu precioso trabalho quando seu laptop, ou qualquer máquina que você use para escrever e executar seus testes, morrer em você, não há desculpa por não usar o controle de versão.
Execute seus testes como parte de um pipeline de compilação
Além de qualquer exploração de seu sistema que você faz ao escrever seus testes, eles são inúteis até que sejam executados. E você provavelmente deseja executar seus testes com frequência, idealmente em todas as alterações substanciais feitas por seus desenvolvedores. Então, por que não automatizar o processo de execução de seus testes sempre que um desenvolvedor submeter um novo trecho de código ao controle de versão? Ou sempre que quiser criar uma compilação pronta para ser implantada na produção?
A menos que você automatize o processo de execução de seus testes, é provável que você se esqueça disso. Portanto, torne esses testes parte de seu pipeline e use-os para garantir que o código que sua equipe escreveu ainda se comporte de acordo com as expectativas que você codificou em seus testes. Cada. E. Todo. Tempo.
Use análise de código estático e linters
Para garantir que o código de teste que sua equipe escreve seja estilizado de maneira consistente, não posso recomendar o uso suficiente de ferramentas de análise de código estático e linting. Não há nada tão frustrante quanto Johnny usar a nomenclatura camel case para variáveis e Anna usar snake casing no mesmo projeto. A única coisa ainda menos divertida é ouvi-los discutir sobre isso o tempo todo. Para garantir que todos sigam as mesmas diretrizes de estilo, as ferramentas de linting são essenciais.
Além disso, não seria ótimo se você tivesse uma ferramenta que pudesse ajudá-lo a evitar todos os tipos de exceções desagradáveis (ponteiros nulos, alguém?) e outros comportamentos errôneos enquanto você escreve seu código ? É aí que entra a análise de código estático.
Embora o uso de ferramentas de análise de código estático e linting possa parecer doloroso no início, devido a todos os erros e avisos que você provavelmente obterá ao executá-los pela primeira vez em uma base de código (teste) existente, recomendo que você continue com eles. Você não precisa corrigi-los todos, mas se aplicar diligentemente a regra do ‘escoteiro’, com o tempo, seu código ficará mais limpo, tornando-o mais fácil de ler e manter.
Há uma infinidade de ferramentas que podem fazer análise estática de código e linting para você, e algumas ferramentas fazem as duas coisas. Eu mesmo gosto bastante do StyleCop e uso isso para manter o código RestAssured.Net o mais limpo, claro e consistente possível.
Teste seu código de teste
Como testadores, nos preocupamos com a qualidade. Embora não sejamos os mantenedores da qualidade, fazemos o possível para garantir que o produto que criamos em equipe atenda às expectativas de qualidade de nossos usuários e outras partes interessadas. Infelizmente, nem sempre estendemos isso aos testes que escrevemos. Ao longo da minha carreira, eu vi e escrevi muitos testes que foram claramente projetados usando o ‘ele compila e mostra uma marca de seleção verde, o que mais você quer?’ filosofia.
No entanto, os testes também podem sofrer com a falta de qualidade. Eles podem produzir falsos positivos, que são irritantes, mas pelo menos se tornam conhecidos, mas, pior ainda, podem produzir falsos negativos, deixando que efeitos colaterais não intencionais e até mesmo bugs flagrantes passem despercebidos.
É por isso que você deve testar seus testes e certificar-se de que as informações que eles produzem são valiosas e confiáveis, tanto quando seu teste passa quanto quando falha. Existem até ferramentas que podem ajudá-lo a fazer isso, então por que você ainda não está testando seus testes?
Aplicar princípios de programação orientada a objetos
Nos últimos 16 anos, tornei-me bastante hábil em identificar qual automação foi escrita por pessoas que sabem programar, em oposição a pessoas que simplesmente aprenderam a API de uma ferramenta ou biblioteca. A diferença: estrutura. Enquanto o primeiro produz um código bem estruturado e, portanto, fácil de ler e fácil de manter, o último geralmente não vai além de escrever testes que listam processualmente todas as centenas de pequenos passos diferentes que compõem o teste. Clique aqui. Digite lá. Marque esta caixa. Desmarque essa caixa.
Demora um pouco para muitas pessoas crescerem do último para o primeiro. E isso é compreensível. Ninguém pode aprender a escrever um código bem estruturado em um ou dois dias. Mas se você me perguntar por onde começar, sempre volto para aprender os princípios da programação orientada a objetos. Na minha opinião, nada melhora seu código tão rapidamente quanto entender esses princípios e saber onde e como aplicá-los. Seu futuro eu e seus colegas de trabalho que lidam com o código que você deixou para trás ao seguir em frente serão eternamente gratos.
Escrever testes juntos
Você provavelmente já ouviu falar sobre programação pair / mob / ensemble. Adivinha? Você também pode fazer isso quando estiver escrevendo testes. Na verdade, você também deve fazer isso ao escrever testes. Não há melhor maneira de escrever testes melhores do que ter outro par (ou alguns outros pares) de olhos neles. Além disso, você obtém transferência de conhecimento gratuitamente. O que há para não amar?
Veja e trate a si mesmo como um desenvolvedor, e seu código como um desenvolvedor
Minha recomendação final é talvez a mais importante, na minha opinião, e todas as recomendações que fiz até agora podem (mais ou menos) ser resumidas neste único conselho.
Se você está escrevendo trechos de código que verificam outros trechos de código, isso faz de você um desenvolvedor
Aí já falei.
Com essa nova maneira de olhar para si mesmo e para o seu trabalho, no entanto, vem uma grande responsabilidade. Se você é um desenvolvedor (novamente, o que você é), deve se comportar como um, de preferência um bom desenvolvedor. Isso significa que você deve começar a tratar seus testes como eles merecem ser tratados: como código. E sim, isso é verdade mesmo quando você está trabalhando com ferramentas de baixo código.
Tenho certeza de que as dicas acima irão ajudá-lo a dar alguns passos decentes na direção certa.
Agora vá e trate seu código de teste como seu código de produção!