Concrete Logo
Hamburger button

Porque usar Lint no seu projeto de testes

  • Blog
  • 11 de Janeiro de 2018
Share

Fala galera! Esse é um assunto que não vejo sendo muito discutido entre os QAs que eu converso, mas vocês acham que devem passar Lint no seu projeto de teste? Espero que a resposta tenha sido sim. 😛

OBS: Lembrando que isso vale para todos que escrevem pelo menos uma linha de código, até porque QAs que automatizam também são desenvolvedores.

Antes de eu começar seria interessante saber o que seria o tal do Lint ou, melhor dizendo, análise estática de código, esse vai ser o nome que vamos utilizare daqui em diante.

A análise estática do código nada mais é do que uma depuração do seu código fonte, ou seja, ela faz a busca por possíveis bugs, verifica erros de sintaxe, complexidade ciclomática de código, também é possível perceber a verificação de style code e boas práticas. Existem outras características de análise, mas acredito que essas já te façam olhar o Lint com outros olhos.

E o que eu ganho fazendo uma análise estática do meu código? Um dos principais ganhos é automatizar um processo que é demorado, que requer muita atenção a cada linha que vai ser analisada. Veja o exemplo abaixo:

Legal! Temos um pedaço de código que só vai retornar os números pares, mas… e aí? Conseguem olhar e já saber quais são os problemas desse código?

Para realizar a análise estática de código em Ruby, vou utilizar o RuboCop, que é baseado no Ruby style guide. Nesse link ensina como instalar, então vou focar aqui somente em como utilizar e configurar.

Com o Rubocop instalado, vamos rodar para saber o que esse código nos apresenta.

Vocês vão olhar e falar: “Nossa! Como um código tão pequeno pode ter tantos “problemas”?

Sim! É por isso que quando abrimos, por exemplo, o Android Studio ele nos dá, pelo menos, 30k de warnings e possíveis problemas.

Vamos refatorar esse pequeno código problemático, seguindo as boas práticas?

Agora vamos rodar novamente o Rubocop:

Podemos ver que agora estamos seguindo as boas práticas e nosso Lint não acusa nenhum problema. Um fator importante é que é possível configurar o que vai ser verificado através de um arquivo rubocop.yml, que deve ficar na raiz do seu projeto. Abaixo, segue um exemplo que criei e que venho usando durante um tempo nos projetos que participo:

Temos também um ganho em legibilidade do código. Não é um “Hadouken”, mas mesmo que o código seja pequeno já iniciamos o processo de “hadoukenização”.

Código Hadouken:

Fonte

É de extrema importância ressaltar que o Lint não substitui o bom e velho code review, ele apenas automatiza parte do processo e faz isso muito mais rápido do que se você tivesse que olhar linha por linha. 🙂

FAÇAM CODE REVIEW!

Então, da mesma maneira que o Lint é passado nos projetos de back ou front-end, ele deve ser passado no seu teste.

Mas… por que?

Seu teste automatizado também é código e por ser código deve seguir as boas práticas da programação e seguir o style de cada linguagem. Fazendo isso, você garante que a pessoa que for pegar o seu código para ler, não dê de cara com um mini monstro, mas sim com um código bonito e fácil de ler.

Nesse exemplo, citei apenas um trecho de código feito em Ruby, mas existem Lints para diversas linguagens. Logo, dá para rodar naquela classe que você acabou de escrever e não se preocupou com a granularidade de seus métodos, nem com a sua complexidade ciclomática e tal.

Espero que este texto sirva de inspiração para que vocês comecem a passar um Lint no código e que isso faça com que evolua para um Lint que rode em uma integração contínua.

Trabalha com QA e quer fazer parte de um time fantástico? Envie seu currículo para trabalheconosco@concrete.com.br.