Implementar testes de componentes about sme-filadacreche HOT 17 CLOSED

Estou implementando testes unitário das utils que ainda não têm.

from sme-filadacreche.

Sim, sim, eu vi. Eu quis dizer que a minha configuração do CI estava incompleta. Eu estava só testando o que acontecia quando eu ligava o "Auto DevOps" e deixava rolar. Não esperava que ele fosse ficar marcando os commits daqui como falhos se os testes caíssem. Enfim, faz todo sentido os testes terem falhado e certamente é culpa da configuração das .env.
Acho inclusive que talvez seja mais fácil que algum de vocês faça o CI, já que eu nunca deployei esse código, e nem posso, acho. Me avisa se concordar que paro de me preocupar com isso, mas posso tentar mais se quiserem.

from sme-filadacreche.

Ah, acho que não ficou claro. Eu quis dizer que, na minha opinião, os testes e2e são essenciais e, se quisermos testar mais do que isso, sugiro que sigamos pelas opções 2 e 3, além dos testes.

from sme-filadacreche.

@victorsenam desculpa a demora. O item 1 estamos em progresso, certo?

Eu não sou especialista no assunto, mas me parece que o 3 é mais interessante que o 2, uma vez que boa parte dos ganhos em usar testes snapshot já está coberto em teste e2e, certo? Me corrija se eu tiver viajado.

from sme-filadacreche.

Eu concordo, o 3 está me parecendo mais útil agora, ele agiliza bastante o processo todo de produzir código, melhora muito a clareza e evita muita bobagem.
Snapshots são testes unitários, os coitados nunca são uma prioridade.

from sme-filadacreche.

@victorsenam vi que estão testando um CI acho que aqui: https://gitlab.com/victorsenam/SME-FilaDaCreche/-/jobs/94606944

Estou achando que esse teste falhou por falta das .env vars. Depois explica pra nós como está fazendo a CI / testes?

from sme-filadacreche.

Eu fiz isso para testar e estava incompleto. Não queria que ele ficasse sujando o repositório, desculpa.
Mas obrigado por lembrar sobre as .env vars, provavelmente esse é o problema. Vou explorar um pouco mais.

from sme-filadacreche.

Mas os testes que falharam são os das utils que já existiam antes, e eles não falham aqui quando estou desenvolvendo localmente.

Parece que eles falham por não encontrar os módulos do app, eu acho que é porque falta o NODE_PATH='src/'. Me explica melhor como você tá fazendo o CI no GitLab?

from sme-filadacreche.

Certo. Na minha opinião, seria mais interessante você focar nos testes e a gente tentar cuidar dessa parte de CI e deploy. @ludimila de acordo?

from sme-filadacreche.

@bplmp não concordo, mas também não acho que o CI seja prioridade no momento, era mais pra ser um beta e ver se valeria a pena migrar para o CI do gitlab.

from sme-filadacreche.

@ludimila ou seja, você acha que nenhum dos dois (testes e CI) são prioridade no momento?

Eu acho testes importantes pra gente conseguir agilizar a aceitação dos pull requests sem ter que checar as funcionalidades 100% manualmente.

from sme-filadacreche.

Os testes podem manter.

from sme-filadacreche.

Desculpa pelo textão, eu gosto de dar sugestões grandes e, já que a gente não tem muito contato pessoal, esse é o jeito.

Agora que eu terminei de implementar os testes óbvios, que eram esses das utils, eu comecei a pensar em como completar o resto dessa issue. Não é muito óbvio o que quer dizer testar componentes no React. A ideia seria criar um teste unitário para cada componente? Não tenho ideia de como faria isso.
Pra mim a única coisa que faz sentido testar como teste unitário é a busca por endereço. Podemos refatorar ela e encapsular a busca numa util, acho que ia ser legal até porque o processamento desses dados tá um pouco entrelaçado na aplicação. Tendo isso separado numa util a coisa fica mais clara e a gente pode testar como testamos as outras.
Com alguma pesquisa e me baseando na minha experiência, eu pensei em um plano de testes que pode ser bem útil pra gente. Assumindo que vamos manter os testes das utils e refatorar como eu acabei de sugerir. Minha ideia era fazer três coisas pra deixar a aplicação mais confiável:

1. Testes e2e
   Como já está sugerido na issue #9. São um jeito muito prático de garantir que a experiência do usuário não quebre. Isso tem a cara do aplicativo. Já que ele é idealizado em cima de uma conversa, basta a gente criar alguns cenários bons dessa conversa que já vamos ter uma garantia bem grande de que nenhum dano muito grave foi causado.
2. Snapshots
   Eu nunca usei pessoalmente, mas já ouvi falar bem, está como sugestão na doc do Jest e estamos aqui pra aprender, certo? A ideia é renderizar alguns componentes com props definidas por nós e tirar "snapshots" disso. Desse jeito, se a coisa mudar em algum momento, você vai ser avisado e vai ter que confirmar que aquela mudança está correta. É um ótimo jeito de submeter commits bem testados porque ele te diz o que mudou e o que você deveria testar, quais páginas deveria visitar.
3. Tipagem
   Isso é um certo esforço porque requer que você passe de novo por todo o projeto, mas pode ser feito aos pouquinhos, o que vai melhorando a aplicação com calma da parte mais importante pra menos. Tem umas bibliotecas que tipam o react, como o Typescript e o Flow. Tipagem garante que as informações estão fluindo consistentemente e, talvez ainda mais importante, garante que você trate os casos de nulidade e coisas do tipo, evitando os bugs mais esquisistos como o #21. Na minha experiência, isso é a coisa mais sensacional do mundo. A maioria das bobagens é pega por isso, ele te força a pensar sobre todos os casos. De quebra, o código fica muito mais claro de entender. Você abre um componente e já sabe tudo que pode aparecer no estado e nas props, já consegue ter uma ideia bem boa do que ele faz bem de cara.

O que acham? Estou dizendo isso pra conseguir definir o que queremos dizer com os testes que queremos. Posso focar em aplicar esse plano a partir de agora e ir corrigindo o que eu for encontrando no caminho.
Eu fiz a lista em ordem de importância. O e2e, na minha opinião, é muito mais importante que os outros.

from sme-filadacreche.

Escrevi testar componentes apenas para os testes unitários não serem confundidos com os de e2e. Eu particularmente estou mais familiarizada com testes e2e e acho que seria mais simples para outras pessoas continuarem do ponto onde você parar. Eu ficaria com a opção 1 ou 2. @bplmp o que acha?

from sme-filadacreche.

Então o próximo passo é tornar o js tipado? Se o dev quiser passar um objeto como prop para outro componente, vai ter que criar um tipo para esse objeto dizendo quais os tipos dos campos que ele possui, ao invés de só confiar que quem implementar vai mandar o tipo certo, isso parece bom e ruim ao mesmo tempo, não vejo como isso deixa o processo mais rápido, mas pode ser que deixe com maior qualidade. Como outras pessoas que vierem a contribuir se beneficiam com isso ao invés de se desmotivar?

from sme-filadacreche.

De fato aumenta um pouco a barreira de aprendizado, apesar de ser bastante intuitivo.
O flow te permite misturar código tipado e não tipado sem problema, então a gente poderia continuar aceitando código normal, se a gente decidir que vai trabalhar assim.
O processo fica mais rápido, na minha opinião, porque a investigação do código fica muito mais simples.

Apesar disso, acho que essa discussão tá se estendendo e não é tão importante assim, vamos deixar isso de lado por enquanto? Se surgir no futuro uma vontade de tipar de novo, a gente tem aqui alguns argumentos pra considerar já.

from sme-filadacreche.

Concordo em deixar de lado por enquanto, depois pensar os reais ganhos de tipar. Como é uma aplicação que não deve crescer muito, talvez não valha a pena tipar por enquanto, na minha opinião.

from sme-filadacreche.