Executando verificação de segurança...
8

A jornada da primeira contribuição

E aí galera!

Para tentar estimular mais pessoas a contribuírem pela primeira vez (seja aqui ou em outros projetos), vou contar como foi minha jornada da primeira contribuição no TabNews, o projeto mais massinha da comunidade dev mundial 😄.

Sempre quis contribuir com projetos open-source, mas sempre tive receio por me deparar com projetos já consolidados e muitas vezes com uma codebase extensa. Porém só de observar todas as interações nas issues e PRs do TabNews me senti confortável para arriscar.

A primeira coisa que fiz foi buscar nas issues uma necessidade do projeto que eu gostaria de contribuir. Como gosto mais do backend, filtrei pela tag back e encontrei a issue #350, já muito bem detalhada quanto ao que deveria ser feito.

Encontrada a issue, explorei um pouco o projeto para entender melhor sua organização e funcionamento. Existem várias abordagens para adquirir esse entendimento, mas uma que gosto bastante é começar pelos testes, porque eles descrevem as regras da aplicação e isso ajuda demais no início. Um problema dessa abordagem é que ela depende de testes bem descritivos e bem implementados, mas isso não foi um problema aqui. Os testes estão muito bem feitos no Tab News, parabéns pessoal!

Como o projeto está muito bem estruturado e a issue estava muito bem descrita, consegui tranquilamente aplicar TDD no desenvolvimento, iniciando pelo teste e partindo para implementar o mínimo possível para obter o "verde" (conto mais um pouquinho sobre como foi esse processo no fim da postagem). Mais uma vez, parabéns a todo mundo que ajuda a manter e evoluir o projeto!

O primeiro passo foi implementar o teste para cobrir o caso de um Default user, sem os privilégios necessários, tentar modificar o conteúdo criado por outro usuário. Foi um passo interessante para aprender a utilizar o commitizen, que nunca tinha utilizado.

Em seguida, iniciei o desenvolvimento da feature em si, seguindo as sugestões do Mich Filipe. Adicionei outra categoria de usuários no arquivo tabnews.com.br/tests/integration/api/v1/contents/[username]/[slug]/patch.test.js e desenvolvi o teste completo: criação do usuário A (com a feature update:content:others), criação do usuário B (dono do conteúdo a ser editado), requisição para usuário A alterar o conteúdo criado pelo usuário B e verificação do resultado. Utilizei como base o teste desenvolvido anteriormente, e também o teste Content with "owner_id" pointing to another user, que já fornecia uma ótima base para testar um caso de sucesso de edição do conteúdo.

Com o teste implementado e falhando, iniciei a implementação da feature sempre observando o resultado no teste após alguma mudança. Na primeira execução, a requisição falhou com a exceção ValidationError, pois a feature update:content:others ainda não tinha sido adicionada na lista de features de autorização permitidas. Depois de inseri-la na lista, o teste passou a falhar por ForbiddenError, pois ainda não havia adicionado o código para permitir que usuários com a feature update:content:others editem conteúdo de outros usuários. Após adicionar o código sugerido pelo Filipe na descrição da issue, obtive sucesso no teste, finalizando assim a implementação 😄

E é isso, pessoal!
Espero que esse texto tenha inspirado vocês a também contribuírem com esse ou outros projetos!

Vocês podem ver mais sobre a implementação dessa feature nos PRs #412 e #424. (Caso não tenha acesso ao repositório, veja essa postagem)

Carregando publicação patrocinada...
1

Lucas, mandou muito bem, tanto na parte do código, dos testes automatizados, dos testes manuais em homologação, e agora com essa publicação!

E vou te falar, a feature não era complexa de implementar, mas tinha que ter muita coragem para implementar ela, pois é a primeira vez oficial que é exposto na API uma forma de uma pessoa alterar o conteúdo da outra 🤝 inclusive, já usei hoje para adicionar a tag Pitch: na frente de uma publicação e foi uma mão na roda 😍

Vamo que vamo!!!!