Como de costume, de tempos em tempos gosto de lançar uma série de conteúdos aqui no blog como uma forma de me forçar a escrever mais, e nada melhor do que escrever sobre um assunto o qual me interesso, como também um assunto o qual experimento de diversas formas em meu dia-a-dia.
Uma das formas como venho experimentando qualidade de código é com a ajuda da ferramenta Better Code Hub (BCH), a qual através de benchmark analisa a qualidade de projetos de software dos mais diversos, e diferente de ferramentas como o Sonar, a qual também é uma excelente opção para melhorar a qualidade de seu código, o BCH avalia o projeto de uma forma mais abstrata, através de 10 guidelines.
Nesta série pretendo apresentar minha visão sobre cada uma dessas guidelines, uma por post.
Então aí vai a primeira.
Escreva pequenas unidades de código
Segundo o BCH:
- Pequenas unidades são mais fáceis de entender, reutilizar e testar.
- Ao escrever novas unidades, não as deixe crescer para mais do que 15 linhas de código.
- Quando uma unidade crescer para mais do que 15 linhas de código, você precisa à encurtar, separando-a em unidades menores que não possuam mais do que 15 linhas.
Pequenas unidades são mais fáceis de entender, reutilizar e testar
Pensando em termos de testes automatizados, digamos testes de interfáce gráfica de usuário (GUI), pequenas unidades podem ser representadas por:
- Pequenas suites de teste que testam específicas funcionalidades da aplicação de forma isolada, tais como login, criação de conta, criação de conteúdo, etc.
- Pequenos componentes que podem compor diferentes page objects para uma melhor reutilização e manutenabilidade;
- O mesmo vale para pequenos page objects, compostos por apenas uma URL relativa à página que ele representa e instâncias dos componentes que o compõe;
- Pequenos helpers criados para fazer uma coisa só, e fazê-la muito bem.
Neste projeto no GitHub sugiro uma proposta de arquitetura de testes automatizados utilizando o framework Protractor e a biblioteca protractor-helper, sendo esta uma arquitetura a qual viabiliza, se bem pensada e implementada, uma estrutura de testes com componentes e page objects bem pequenos, alguns com quem sabe até 15 linhas ou menos. 😉
Ao escrever novas unidades, não as deixe crescer para mais do que 15 linhas de código
Creio que tal regra não precise ser levada à risca, mas é um desafio legal de se atingir, né? Eu particularmente gosto de software modularizado, visto que facilita meu aprendizado sobre o mesmo, além de facilitar para extenções futuras.
Veja alguns arquivos do projeto do meu site pessoal e entenda o que quero dizer com pequenas unidades de código:
https://github.com/wlsf82/-walmyr-filho-react/blob/master/src/components/App/index.js
https://github.com/wlsf82/-walmyr-filho-react/blob/master/src/components/PageHeader/index.js
https://github.com/wlsf82/-walmyr-filho-react/blob/master/src/components/PageContent/index.js
https://github.com/wlsf82/-walmyr-filho-react/blob/master/src/components/PageFooter/index.js
Simples!
E alguns outros exemplo mais elaborados:
https://github.com/wlsf82/-walmyr-filho-react/blob/master/src/components/Introduction/index.js
Acho que consegui me fazer entender, né? 😛
Veja que alguns componentes são um pouco maiores, e outros menores, mas todos são pequenos o suficiente para serem fáceis de entender e são compostos por pequenas partes especializadas.
Perceba também que aqui não utilizei exemplos em teste de software, mas ainda sim imagino que o código não tenha sido difícil de entender, certo?
Para um exemplo relacionado à testes, sugiro o seguinte projeto de testes end-to-end do curso de arquitetura de testes com Protractor da Escola Talking About Testing.
Quando uma unidade crescer para mais do que 15 linhas de código, você precisa à encurtar, separando-a em unidades menores que não possuam mais do que 15 linhas
Creio que este seja o maior desafio, mas também acho legal pensar que software não é perfeito, e pode sempre ser melhorado. Se eu aprender uma nova técnica que otimiza meu tempo resolvendo problemas complexos, com menos linhas de código, não faz sentido não usar, certo? Se eu puder separar responsabilidades, tais como page objects e spec files, para tornar a reutilizaçao de código melhor, e o uso de componentes para fácil extensão, também não vejo motivo para não os fazer.
Outras alternativas podem ser, por exemplo, o uso de pequenas funções customizadas para realizar ações específicas, as quais quando combinadas podem determinar um caso de teste, ou a simples separação de constantes em um arquivo específico o qual pode ser reutilizado em todo ou parte de um projeto. E por aí vai.
A mensagem aqui é, refatore o software o qual você mentém, há sempre espaço para melhoria.
E você? Quero saber o que tens a dizer a respeito. Deixa um comentário aí, por favor!
Spoiler: o próximo post da série será: Escreva simples unidades de código.
Até breve e bons testes! 👋
Nota para meu eu do futuro: atualizar o post de tempos em tempos 😜
TALKING ABOUT TESTING 
9 comentários em “Nova série – Qualidade de Código em Teste de Software”