[TabNews] Corrigidos BUGs nos Testes e na Geração de Slugs

Fala Turma, tudo bem?

Passada uma semana desde a publicação sobre as primeiras melhorias da Milestone 7, estou voltando para contar sobre mais alguns avanços no TabNews. Nos últimos dias corrigimos alguns bugs que estavam ocorrendo nos testes e na geração de slugs, mas continuam em andamento outras melhorias nos PRs abertos.

Estabilização de Testes

Inspirados pelo conteúdo das últimas aulas do curso.dev, corrigimos alguns testes que falhavam eventualmente.

Diferenças de Horário

Pequenas diferenças de horário entre o PostgreSQL e o Vitest causavam falhas intermitentes em alguns testes.

RSS

O campo lastBuildDate do feed RSS é preenchido com o valor de updated_at do conteúdo mais atual, mas o teste verificava contra published_at. Um definido no Node.js e o outro no banco de dados, o que ocasionalmente causava divergência. A comparação agora é feita corretamente entre lastBuildDate e updated_at.

Expiração e Revalidação do Token de Sessão

Os testes simulavam a expiração do token com tempos exatos, mas falhavam ocasionalmente. Agora, simulamos a passagem de um tempo extra além do tempo normal, garantindo que o token expire corretamente.

Criação de Usuários

Utilizamos a biblioteca @faker-js/faker para gerar dados aleatórios, mas a baixa aleatoriedade causava alguns erros.

username ou email duplicados

Era raro, mas ocorria. Agora, armazenamos os nomes e emails já utilizados durante os testes para garantir que não haja duplicidade.

username muito longo

A biblioteca não limita o tamanho do username, eventualmente resultando em nomes acima de 30 caracteres. Adicionamos substring(0, 30) para garantir que os nomes não ultrapassem o limite permitido.

Mais sobre a criação de usuários

A biblioteca @faker-js/faker só é utilizada quando não é passado um objeto com os dados do usuário. Quando passado, os dados são utilizados diretamente, sem alterações, então conseguimos testar a criação de usuários com dados específicos, como username longo ou duplicado.

Criação e Validação de Slugs

O slug dos conteúdos normalmente é gerado automaticamente, e se baseia no título. Quando o título é longo, o slug é truncado, mas às vezes era gerado um slug que terminava com hífen, o que não passava no nosso validador.

O problema estava presente desde que foi realizada a diminuição do limite do slug de 255 para 226 caracteres, mas por serem raros conteúdos com títulos tão longos, e pouco provável do hífen ser posicionado justamente no último caractere, o problema só foi notado recentemente pelo @luangregati, que relatou na issue #1721.

Durante a revisão do PR, chegamos na conclusão de que 226 caracteres era muita coisa para o slug, então optamos em reduzir para 160 caracteres, o que ainda é grande, mais do que suficiente, mas já nos deixa tranquilos de não precisar mudar novamente esse valor por mudanças nos requisitos tecnológicos.

Tamanho do slug

Após as considerações, reduzimos o limite do slug para 160 caracteres para evitar problemas futuros e ainda assim garantir URLs consistentes. O slug agora é truncado para 160 caracteres no validador.

Remoção do Hífen Final

Quando o slug é truncado, o último caractere é verificado para evitar que seja um hífen, se for, o próprio validador já remove.

Pequenas Otimizações

Fizemos otimizações na geração do slug, que é realizada com ajuda da biblioteca slug:

  • A configuração slug.extend foi movida para fora da função getSlug. Com isso ela só é executada um vez, e não a cada chamada da função.
  • O título agora também é truncado antes de ser passado para a biblioteca slug.

TAG Canônica

Foi adicionada a TAG canônica nos conteúdos "root" para evitar impactos negativos no SEO pela mudança nas URLs causada pela redução do tamanho do slug de alguns conteúdos pré-existentes.

Testes de Validação de Slugs e Títulos

Foram adicionados novos testes para garantir que os slugs gerados estejam dentro dos limites permitidos.

Os testes pré-existentes foram ajustados para considerar o novo limite de 160 caracteres.

Constantes

Foi criado um arquivo para armazenar constantes que se repetem em muitos testes. Por enquanto foram adicionadas as constantes:

  • maxSlugLength
  • maxTitleLength

O nome do arquivo é constants-for-tests.js para deixar bem clara a sua finalidade, ou seja, evitar que uma mesma constante seja utilizada para definir ao mesmo tempo o teste e o código testado.

Conclusão

Os ajustes nos testes foram realizados no PR #1720, e agora eles estão mais estáveis e confiáveis.

Já os ajustes nos slugs foram realizados no PR #1722, e agora os slugs são sempre gerados corretamente e não passam de 160 caracteres.

Ainda existem muitas melhorias em andamento, então fiquem ligados no repositório do TabNews para acompanhar mais de perto as novidades, na qual eu destaco a abertura do primeiro PR das Publicações Promovidas. E se você quiser contribuir, fique à vontade para abrir ou revisar os Pull Requests ou comentar nas Issues. 💪

Cheguei tarde nas últimas duas publicações de melhoria por conta da correria do curso e só queria responder quando eu conseguisse ler com calma cada publicação e que bom que fiz isso, muita coisa importante foi implementada 💪

E dado a quantidade de upvotes em cada publicação de melhorias mostra como que um changelog é algo extremamente importante e nunca devemos parar de fazer um 🤝

Dado a isso, me pergunto: será que tem alguma forma de automatizar ou facilitar a criação disso?

Já respondendo a minha própria pergunta: com certeza não daria para automatizar algo que fique na qualidade de uma publicação como você faz Felipe, ela é bastante humana. Mas pelo menos será que não daria para alimentar um "ChatGPT da vida" com o ruído da movimentação do repositório para ele destacar o sinal e cima disso criar uma publicação mais humana?

Por coincidência, testei isso justamente quando ia criar essa publicação aqui, mas sem sucesso. Aproveitei que os PRs estavam bem detalhados, então pensei que seria mais fácil para os LLMs criarem algo interessante. Mas nem o ChatGPT e nem o Gemini conseguiram criar algo decente. Até alimentei o prompt com outras publicações sobre novidades do TabNews e pedi para usarem como exemplo, mas só saíram cópias do conteúdo dos PRs com algumas pequenas alterações, e bem longe do formato que eu estava pedindo. Deve funcionar se criarmos um modelo de publicação mais simples e bem padronizado, por exemplo só uma lista dos PRs com um pequeno resumo do que pode ser visto na página de cada PR, mas acredito que a maioria ficará sem contexto ou com erros mais sérios. Tentarei de novo de vez em quando... 🤝