Chegamos ao último post da série de qualidade de código em teste de software
Se você está chegando neste post agora e ainda não leu os conteúdos anteriores, recomendo começar por eles. Seguem os links:
- Escreva pequenas unidades de código
- Escreva simples unidades de código
- Escreva código uma só vez
- Mantenha as interfaces da unidade pequenas
- Separe responsabilidades em módulos
- Acople a arquitetura de componentes fracamente
- Mantenha a arquitetura de componentes equilibrada
- Mantenha sua base de código pequena
- Automatize testes
Agora se você já leu os primeiros posts da série, vamos falar sobre a décima e última guideline do Better Code Hub: Escreva código limpo.
Segundo o BCH:
- Código limpo é mais fácil de manter
- Pró-ativamente procure e remova cheiros ruins do código
- Remova comentários desnecessários, blocos de código comentado e código morto. Refatore exceções pobremente implementadas, constantes mágicas e unidades ou variáveis mal nomeadas.
Código limpo é mais fácil de manter
Vejamos um exemplo de um teste escrito com o framework Cypress, onde o código não estava limpo.
// cypress/integration/vidbits.spec.js describe("Vidbits", () => { context("Empty state", () => { it("creates two videos", () => { cy.exec("npm run drop-db"); cy.visit("videos"); cy.get(".add-video-button").click(); cy.get("#video-title-input") .type("Chaos and intuition engineering"); cy.get("#video-description-input") .type("GOTO 2016 • Chaos & Intuition Engineering at Netflix • Casey Rosenthal."); cy.get("#video-url-input") .type("https://www.youtube.com/embed/Q4nniyAarbs"); cy.get("#submit-button").click(); cy.visit("videos"); cy.get(".add-video-button").click(); cy.get("#video-title-input") .type("appear.in & Star Wars"); cy.get("#video-description-input") .type("Sed ut perspiciatis unde omnis iste natus error."); cy.get("#video-url-input") .type("https://www.youtube.com/embed/vHTIYVHTSxA"); cy.get("#submit-button").click(); cy.visit("videos"); cy.get(".video-card").its("length").should("eq", 2); }); }); });
Perceba que o código do teste é longo e cheio de detalhes de implementação e duplicações.
Agora, vejamos tal código refatorado com o uso de iteração em um array, comandos customizados e fixtures.
// cypress/integration/vidbits.spec.js describe("Vidbits", () => { const videos = require("../fixtures/videos"); context("Empty state", () => { beforeEach(() => cy.exec("npm run drop-db")); it("creates two videos", () => { videos.forEach(video => cy.createVideo(video)); cy.visit("videos"); cy.get(".video-card").its("length").should("eq", 2); }); }); });
O teste demonstrado faz o mesmo que o anterior, porém é focado somente no que importa para o teste, não se importando em guardar os dados dos videos que serão criados, nem mesmo nos detalhes para a criação de um video. Além disso, neste código não há duplicações, ou seja, não há mais este bad smell.
Vejamos agora o arquivo de fixtures cypress/fixtures/videos.json.
[ { "title": "Chaos and intuition engineering", "description": "GOTO 2016 • Chaos & Intuition Engineering at Netflix • Casey Rosenthal.", "url": "https://www.youtube.com/embed/Q4nniyAarbs" }, { "title": "appear.in & Star Wars", "description": "Sed ut perspiciatis unde omnis iste natus error.", "url": "https://www.youtube.com/embed/vHTIYVHTSxA" } ]
Perceba que tal arquivo tem a única responsabilidade de guardar os dados que serão usados para criação dos videos no teste, nada mais.
E por fim, vejamos o comando customizado createVideo, criado no arquivo cypress/support/commands.js.
Cypress.Commands.add("createVideo", video => { cy.visit("videos/create"); cy.get("#video-title-input") .type(video.title); cy.get("#video-description-input") .type(video.description); cy.get("#video-url-input") .type(video.url); cy.get("#submit-button").click(); });
Neste arquivo podemos ver os detalhes de como um video é criado (detalhes de implementação), podendo esta função ser reaproveitada onde necessário com apenas uma linha de código (cy.createVideo(someVideoObjectHere)).
Obs.: os códigos demonstrados até aqui podem ser visto antes e após a refatoração nestes links, em minha conta no GitHub.
Pró-ativamente procure e remova cheiros ruins (bad smells) do código
Conforme visto no exemplo anterior, removemos um cheiro ruim do código ao remover duplicação do código.
Existem outros cheiros ruins em código, portanto, recomendo a leitura dos code smells do Refactoring Guru.
Limpe o código
Sempre que perceber que determinada parte do código pode ser melhorada, o faça.
“Não deixe para amanhã o que você pode fazer hoje.”
Veja um exemplo simples de limpeza de código que o tornou mais simples de ser entendido.
Neste caso, deixei mais claro para os leitores do código o que aquele número 3000 significava.
Porém, conforme comentado, existem outras formas de limpar código, tais como:
- Remover comentários desnecessários
- Tal abordagem diminiu o tamanho do arquivo
- E remove redundâncias (quando por exemplo, o comentário explica algo já explicado pelo próprio nome de uma função ou método)
- Remover blocos de código comentado e código morto
- Tal abordagem diminiu o tamanho do arquivo
- Remove distrações ao leitor
- E remove código implementado e nunca utilizado
- Refatorar exceções pobremente implementadas
- Torna o código mais robusto
- Nomeando propriamente constantes mágicas
- Dá-se melhor significado as coisas
- E melhor nomeando unidades ou variáveis mal nomeadas
- Dá-se também melhor significado as coisas
Espero que este último conteúdo da série de Qualidade de código em teste de software lhe inspire a limpar o código de seus projetos de software sempre que tiveres a oportudidade.
Aproveite também para conferir o infográfico da série.
E minha dica final é:
“Não deixe a oportunidade passar, pois é a prática que o levará à perfeição.”
Até a próxima e bons testes! 👋🧐
Um comentário em “Escreva código limpo {🧹}”