Iniciando com testes: como começar?

[kvnol]

E aí, galera. Faz tempo que não abro uma thread aqui, mas vamos lá:

Eu trampo numa agência comum, sem nenhum grande projeto que utiliza frameworks e libs hypes do mercado, mas para não ficar para trás queria estudar testes e acho que aplicar em projetos pequenos seja bom para começar.

Mas por onde começar? Eu instalei o Mocha e fiz uns arquivos de testes (testes, testes, testes...), mas tenho dúvida do que testar, como testar etc. Como vocês começaram?

[fdaciuk]

Se você for começar de um projeto novo, comece por TDD: o primeiro passo é saber o que sua aplicação vai fazer, e descrever isso. Com esses passos em mãos, você começa a criar as funcionalidades da aplicação à partir de funções puras: elas recebem valores, computam e retornam novos valores.

Essa é a forma mais fácil de começar =)

Se for um projeto já em andamento, você pode começar tentando isolar funcionalidades em funções puras para poder testá-las. Mas a ideia é sempre começar pela parte mais simples.

Dá pra brincar bastante com isso, e faz muitos testes de forma fácil com funções puras. Depois de entender bem como tudo funciona, ae você parte para outros tipos de teste (integração, E2E, etc) =)

[vitocaio]

Bom, uma boa pratica para inicia, seria testar as principais funcoes do seu projeto, por exemplo: funcao que chama um servico e executa algo, ai voce testa o retorno, se e o esperado, entao voce testa tambem se o servico retorna algo de fato e por ai vai

[kvnol]

Maravilha, fazendo uns arquivos pra brincar aqui percebi que não estava funcionando um arquivo de bobeira porque não tinha feito um module.exports, hahahaha.

[Cleysonlb]

Rapaz, escrever teste é um mindset que demorei um pouco a adquirir, oq testar, como testar, pq testar...
Comece testando pequenos métodos, por exemplo:

• Um método que tem um JSON como input e formata para um formato especifico
• Métodos de uma service que recebe uma request e salva no banco dados específicos

[kvnol]

Massa, galera. Farei isso, começar a fazer testes para pequenas funções em projetos pequenos aqui na agência, separá-los em módulos e tal. Vai ficar legal.

[yanmagale]

Concordo com tudo o que o pessoal já disse, são as práticas que eu também costumo fazer.

@kvnol parabéns pela atitude e iniciar o aprendizado, poucas pessoas dão a devida importância a este tema. O mais comum é você cair num projeto que não tem testes. Felizmente este cenário vem mudando...

Você vai perceber ao longo dos estudos o quão bom é desenvolver com TDD e atuar em projetos que possuam testes. Sua percepção e sua forma de escrever código vão melhorar bastante.

[kvnol]

Sim, @yanmagale. Vi essa necessidade por trabalhar numa agência que, como já disse, não tem projetos grandes ou outros devs mais experientes (sou só eu) e se eu não testar novas coisas, não vou conseguir evoluir. E tenho muito mais facilidade de aprender as coisas na prática do dia-a-dia, em problemas reais do que em cursos (e olha que compro muitos cursos, mas não consigo ir até o fim).

[Cleysonlb]

Outro beneficio que eu vi em escrever teste foi um melhor entendimento do código e aperfeiçoamento de lógica de programação, você literalmente da um salto de entendimento de código quando começa a escrever testes

[laurindo]

Hoje a minha stack usando redux com react-native é:

• redux
• redux-thunk
• redux-promise
• redux-persist

Ainda estou tentando compreender tudo direitinho, mas estou curtindo muito.

[ninetails]

Diria pra dar uma olhada no Jest, pessoalmente achei muito mais fácil pra configurar es6 + babel com code coverage em relação a quando tentei configurar na mão karma + mocha + istanbul. Fora facilidades em relação a mockar dependências.

Diria também que faz pouco tempo que tentei adotar testes e o que me facilitou foi Single Responsability Principle do SOLID e o hype de programação funcional que, mesmo com currying, trabalhando com funções puras. Quando vejo que uma função tem muitos testes, tento quebrar em mais funções por talvez agregar muita funcionalidade em um só lugar, além de facilitar posteriormente em relação a legibilidade de código. E como indiquei o Jest, um bom indicativo é o code coverage, mas lembrando sempre que code coverage alto não quer dizer sistema livre de bugs.

E uma última recomendação seria de buscar meetups sobre coding dojo, ou mesmo ver de implementar na agência dado que ajuda bastante em relação a cultura de testes e aumenta o entrosamento da equipe, melhor ainda se tiver code reviews.

[luizbills]

ótima leitura: "5 Questions Every Unit Test Must Answer" do Eric Elliott

[Cleysonlb]

Aproveitando vou deixar uma dica, a Thoughtworks disponibilizou um ebook bem legal sobre teste, segue o link
PRÁTICAS E TENDÊNCIAS EM TESTE (EBOOK)

[willianjusten]

Opa, acabei vendo essa issue aqui por acaso. Então, aconselho a leitura daquele artigo do Eric Elliott, que é uma boa partida para entender o conceito de teste. A base é praticamente:

• Um método deve esperar algo (uma entrada /chamada)
• Ele deve realizar alguma ação (trabalhar com o dado de alguma forma)
• E ele pode ou não retornar algo (um novo valor, uma resposta de algo)

A partir dessa base, é que você consegue começar seus projetos e testes de uma forma bem simples. Criando perguntas "burras" e fazendo seu código respondê-las e sempre ir refatorando e melhorando a cada processo. No final vai perceber que além de ter feito o projeto, já vai ter testado todos os casos.

Não fazendo jabá, mas acabando fazendo... No meu curso de JS com TDD, eu acabo ensinando a criar libs, interfaces, CLI, componente react na prática e usando sempre esse pensamento do TDD, talvez te auxilie para pegar isso.

Eu também fiz um post bem básico ensinando a criar um componente react com TDD, onde vou fazendo bem devagar etapa por etapa, meio que como deve ser no TDD mesmo. É claro, que depois de uma prática adquirida, as etapas vão encurtando, mas o processo é sempre o mesmo.

[Matheus-de-Souza]

Estou fazendo o curso de TDD com Javascript do @willianjusten e vim aqui na thread justo pra recomendar ele, mas o próprio instrutor veio antes para falar do curso, hehehe. Vale muito a pena fazer não apenas pelo TDD, mas pelas dicas de boas práticas em novos projetos e também pra quem está aprendendo ES6.

[felisio]

Bom dia @kvnol li agora essa issue e queria deixar um contribuição para você, além de todas as técnicas para se escrever um bom teste, que como já li você esta com material de sobra, pense antes de tudo no levantamento de requisito do projeto para escrever seus testes e funções. Não adianta você ter uma função que não quebre, se ela não atende o requisito do seu negocio.
Eu sempre começo e escrever os requisitos, e em cima deles vou escrevendo o teste e o que espero que que aquelas funções façam para o meu negocio seguindo os passos citado a cima.