Seja um projeto novo ou antigo, dar manutenção e adicionar novas funcionalidades de forma rápida e segura é complicado. Rápido é subjetivo, em empresas que trabalham com o método ágil, principalmente statups, parece que você não tem o tempo suficiente para escrever um teste mais bem elaborado, ou algo do tipo. Eu entendo, passo por isso em toda sprint, cada vez entra mais funcionalidades e o débito técnico... ah o velho débito técnico.
Porém existem formas de garantir uma certa estabilidade do código, e foi aplicando estas regras (que você poderá ver em seguida), que conseguimos reduzir para quase nenhum hotfix (correções em produção de algo que não está funcionando) por mês.
Dica 1: Configure bem seu ESLint
Muitos bugs podem ser pegos pelo linter. Usou uma variável que não existe (digitou um 'a' a mais ou a menos na palavra)? O linter vai te mostrar que existe essa falha. Definiu uma função nova e não especificou o que ela vai receber? O linter vai te mostrar que existe essa falha. Hoje usamos Javascript nos nossos projetos, implementar o Typescript exige um esforço que não é a prioridade, mas você pode exigir que os desenvolvedores definam os tipos dos dados através de documentação com JSDoc. Não é tão preciso quanto uma ferramenta que realmente transpila seu código, como o tsc, mas é muito útil e foi peça chave para nos prevenir de fazer cagada.
Dica 2: Use um hook de pré-commit para checar se o código fonte está de acordo com as regras do ESLint.
Usamos Husky e Lint-Staged para prevenir que coisas como console.log(some.very.important.info) vá para produção. Mas como isso funciona?
O Husky é uma ferramenta que, sempre que um hook do git for disparado, vai executar algum comando. Por exemplo:
// package.json
{
"husky": {
"hooks": {
"pre-commit": "npm run test"
}
}
}
Ou seja, sempre que você fizer um commit, o Husky irá disparar o comando especificado e se caso o comando terminar com sucesso, o commit será concluído, caso contrário o commit será abortado.
Usamos o Lint-Staged em comjunto com o Husky para verificar, antes de cada commit, se todo o código que está no modo preparado (staged), está de acordo com as regras estabelecidas no nosso arquivo de configuração do ESLint. Esta é a nossa primeira barreira para combater códigos que estejam fora dos padrões da aplicação. Recomendo esta leitura aos curiosos de plantão: Code consistency with ESLint and Husky.
Dica 3: Escreva testes unitários, mas não muitos
Se você ainda não sabe, deixa eu te contar: testar se um monte de componentes eletrônicos estão funcionando corretamente, não significa que a televisão está funcionando corretamente. Inclusive, eu recomendo não escrever testes de snapshot se o produto que você desenvolve estiver em constante mudança.
Mas escrever testes de ponta a ponta é muito demorado, a empresa pode não estar disposta a investir tempo neste nível de confiabilidade do sistema por enquanto, porém é importante pelo menos ter a certeza de que componentes críticos no seu sistema estão funcionando como deveriam funcionar.
Por exemplo, se o seu produto tiver suporte a múltiplas línguas, você gostará de saber que seus arquivos de tradução estão consistentes. Se o seu produto suporta múltiplas moedas, você gostará de saber que seus métodos e componentes que lidam com valores monetários estão funcionando sem erros.
Dica 4: Use o Storybook como ferramenta de desenvolvimento primária
Hoje meu fluxo de desenvolvimento quando preciso criar algo novo é: criar o arquivo que conterá o componente e então criar mais duas pastas: __tests__ e __stories__. Na pasta __tests__ vou escrever os testes, se for algo crítico serão vários, se for algo não crítico serão poucos ou nenhum (volto a dizer, ter a maior cobertura de testes não é a prioridade hoje). Na pasta __stories__ eu defino o componente e acoplo nele vários plugins para fazer testes visuais com o Storybook.
O callback está sendo chamado na hora certa e com os dados certos? Ótimo. O componente está se comportando visualmente da forma correta? Melhor ainda. Pessoas com deficiência visual estão conseguindo distinguir as cores ou está tudo uma bagunça? Tudo isso e mais muitas coisas você consegue testar enquanto desenvolve usando o Storybook. Por fim, você só precisará plugar este componente (que neste ponto estará totalmente desacoplado do restante da aplicação) no restante da aplicação.
O Storybook é uma ferramenta incrível que traz muita velocidade durante o desenvolvimento. Desenvolver e ter um feedback imediato, isolado e testável do que você está fazendo é uma adição incrível ao seu fluxo de trabalho.
Ah, sua equipe de QA pode acessar todas as stories que você já escreveu no Storybook e fazer asserções sobre seu componente de forma isolada, sem precisar procurar o componente novo em algum lugar na aplicação.
Se você trabalha em um produto que está em constante mudança, com melhorias contínuas a cada semana e precisa ter algumas garantias sobre o código ou melhorar a estabilidade mas sem ter muito tempo para escrever testes longos e bastante assertivos, talvez seja interessante testar algumas coisas que escrevi neste artigo.
Top comments (0)