Então, posso dizer que já "fui um desses"... um cara que rapidamente escrevia uma funcionalidade enorme, com trezentas e tantas linhas de código e, no momento que julgava estar com tudo pronto, abria meu navegador para então executar os meus testes (manuais) no software que acabara de construir. E era aí que iniciava-se um ciclo, onde eu encontrava alguns bugs, corrigia-os e testava tudo novamente! Então novos bugs eram encontrados, fazia outras tantas correções até que PÁ... o produto estava finalmente pronto (pelo menos no meu ponto de vista) para ir pra produção. Agora, o caminho natural era apenas esperar a validação final do meu trabalho, que seria feita por outro profissional, o famigerado Analista de Qualidade (ou QA).
A grande maioria dos desenvolvedores que conheço não gosta de testar software pelo simples fato de que executar uma bateria de testes de forma manual é extremamente cansativo. Com isso, nós desenvolvedores criamos o péssimo hábito de testar superficialmente tudo que produzimos, e pela força dos processos inseridos nas empresas acabamos delegando para um terceiro a responsabilidade de testar o que acabamos de desenvolver. Mudar essa realidade é complicado, mas não impossível, e certamente uma boa maneira de mudarmos esse paradigma é tornar o processo de "testar" natural e agradável ao desenvolvedor. Agora, meu caro, eu te pergunto: que tal utilizar o seu melhor skill (que é programar) para tornar os processos de teste manuais em rotinas automatizadas? Parece uma boa, não? Pois bem, esse será nosso desafio daqui para frente.
Para quem está iniciando nesta jornada, a curva de aprendizado pode parecer um tanto quanto assustadora, e o maior desafio, sem dúvida, é equalizar a sua aparente falta de conhecimento sobre o tema a uma nova filosofia que guiará todo o seu processo de trabalho. Somado a isso, surgirão uma série de decisões que você precisará tomar para a saída do que eu costumo chamar de "zero absoluto". As perguntas que certamente vêm à tona nesse momento são: por onde devemos começar e qual caminho devemos seguir???
Mocha, Jasmine, ... (testing frameworks)
Chai.js, Should.js, ... (para expect/should/assertion)
Sinon.js, TestDouble.js, ... (para spies, stubs e mocks)
Istanbul.js, Blanket.js, JsCover, ... (para code coverage)
Hummm... bom, chegando nesse ponto, deu para perceber que existe um certo nível de complexidade para configurar essa stack. O simples fato de decidir quais ferramentas utilizar (caso alguma escolha não seja a mais acertada) pode trazer consequências futuras para a manutenabilidade dessa stack, uma vez que trocar uma peça que não funcione tão bem pode impactar em uma quantidade significativa de testes já escritos.
Era exatamente isso que você precisava fazer...até ontem. A boa notícia é que hoje é um belo dia e você já tem opções bem mais elegantes para execução dos seus testes. Então não desista, pois daqui pra frente você vai poder focar no melhor do seu trabalho, que é escrever testes e produzir código de qualidade, sem se preocupar com essa barrreira de entrada!
Ah não pode ser... venha Jest, que hoje quero lhe usar!!!
Vamos começar instalando o Jest. Nesse ponto é importante que você entenda que o Jest é distruído como um módulo da plataforma node.js. Portanto, é vital certificar-se que esse último está instalado. Você pode abrir seu terminal e digitar o seguinte comando para isso:
testar seu software, além de necessário é sua responsabilidade, portanto, não delegue-o a terceiros!