Como escrever testes em TS com Jest
Essa é uma das reportagens de uma série, se veio parar aqui por causa de algum Hobbit ter te falado para virar “a esquerda na taverna, depois a direita no lago, a direita novamente na pedra verde, depois a esquerda nos orcs petrificados, subir um rio, atravessar uma ponte e escalar a montanha”, agora provavelmente estás perdido, recomendo dar uma olhada sobre mais nessa introdução.
O que são testes?
Se você não tem um background de computação e pretende começar a programar a idéia de testes podem parecer um tanto quanto intuitiva: uma sequência de caminhos que devem ser seguidos a risca, sejam eles resultados positivos ou negativos.
Não gosto de dizer que testes tem a ver com input ou output porque um “Hello, World!” não necessariamente terá um input.
Testes podem ser automatizados ou não, você pode digitar ou clicar toda as vezes que a sua aplicação pedir. Para evitar má interpretação ou algo do tipo, a partir de agora quando eu me referir a testes no resto da reportagem, considere como os automatizados a não ser que esteja explícito que não o são.
Quando devo escrever um teste?
Comecei a escrever testes quando percebi que não escrever eles fazia falta e isso é algo bem contraintuitivo: “como algo pode fazer falta quando na realidade nunca estava lá para começo de conversa?”
O principal motivo por eu não fazer testes até pouco tempo atrás é simples: “não havia necessidade”. Testes demandam linhas de código — lines of code(loc) — , refatorados, atualizados, corrigidos com alguma atualização de software, etc, etc; em suma, testes demandam tempo.
Quando o seu código começa a crescer além do esperado e ele tem mais pela a frente do que o que passou, isso é um ótimo sinal para começar a pensar em automatizar os testes. Isso evita que a dor de cabeça de automatizá-los seja menor do que não automatizar.
Meu turning point sobre testes foi quando vi o vídeo seguinte:
Por onde começo?
Se você já cansou de toda e qualquer interação com a aplicação depender de você para realizá-la e perde mais tempo com isso do que gostaria, além do fator tempo, ter que rodar os testes nos meus bots poderiam levar uns 10 min de forma não automatizada comigo realizando toda e qualquer requisição; hoje, como foram automatizados, levam 15s.
O vídeo já citado foi um dos motivos de eu querer começar um projeto novo, colocar em prática o que vi. Considerando o código da reportagem anteriror, Escrevendo um bot para Telegram em Node+TS, agora serão adcionados mais pastas e arquivos:
Caso você se estranhe com o package-lock.json e se pergunte como ele brotou lá, a primeira vez que você roda o comando de instalação de pacotes através do npm esse arquivo é criado. Abra o .gitignore e adicione a linha que representa uma pasta coverage que será gerada automaticamente mais tarde:
E para finalizar, rode o seguinte comando:
Jest
Essa biblioteca linda e simples de ser configurada — assim como o próprio TS em si, um pequeno disclaimer aqui é que não consegui me adaptar com o Babel muito quando programava apenas em JS puro — é mantida por nada mais e nada menos que o Facebook, assim como o uso de Telegraf necessita de alguns casos de olhar-se a documentação, com o Jest verá ser similar.
obs: particularmente eu caí de paraquedas no Jest, sei que existem outras bibliotecas que realizam testes também mas não posso pontuar vantagems ou desvantagens com relação ao Jest. Mas saiba que para esta aplicação ele supre as necessidades.
Escrevendo os testes
No seu package.json, adicione a seguinte linha:
Isso irá garantir a facilidade de rodar o projeto. O — ci é uma flag não necessária caso não pretenda fazer o CI mais tarde.
E para não ter warning sobre tipos do Jest, no seu tsconfig.json, adicione o seguinte:
Já o seu jest.config.js deverá se encontrar da seguinte maneira:
Por motivos de não querer entupir a vossa visão de um scroll minúsculo com arquivos desnecessário, apenas linkarei os arquivos dentro da pasta do __mocksData__.
Lembre-se de escrever um export na frente de cada função em main.ts na pasta src para que possam ser importardas no main.test.ts:
A principal vantagem de se escrever testes em aplicações que dependem de APIs é que quando a API não se encontrar disponível a aplicação em si ainda poderá ser debbugada e, além disso, no caso de deploy para um CI client a requisição em disco pode te economizar alguns segundos da sua quota mensal de CI.
Uma vez com os testes escritos, basta rodar o seguinte comando:
npm testPelo motivo de test ser um script importante ele não precisa do comando run antes. Além disso, reparou que não precisou compilar para JavaScript antes para rodar? Isso se dá graças ao ts-jest.
Após rodar o comando você deve esperar um output parecido com o seguinte:
Esse comando também gera a pasta coverage, que contem os outputs desse teste rodado. Tenha em mente que não é necessário mandar essa pasta para o Github por motivos de que toda vez que você roda ele, mesmo que não tenha mudado nada no código, arquivos diferentes serão gerados. Isso significa que uma pessoa rodando o código na máquina dela teria resultados diferentes e, portanto, não seria necessário enviar arquivos que são gerados on the fly e não são de extrema necessidade — o Coveralls utiliza eles para verificar a coverage e poder gerar a badge, mas isso será visto no próximo artigo.
E é isso, você acaba de realizar os testes, parabéns! Pode agradecer aos deuses do TDD porque terá horas que eles salvarão seu pescoço de coisas que você nem sequer imaginava.
O que o futuro nos reserva
Não serei hipocrita dizendo que qualquer console.log daqui para frente eu escreverei um teste, que o Test Driven Development(TDD) mudo minha vida e não consigo viver mais sem ele. Projetos pequenos ou que não possuo um tempo hábil para entregar continuarão sendo feitos sem testes — beijos professores da faculdade — , mas aqueles que eu posso me dedicar, que são uma maratona e não uma corrida de 100m, esses sim receberão um carinho maior e testes.
Mesmo TDD sendo um estilo de programação quase e deveria ser pensada desde o começo do projeto, resolvi colocá-la como o segundo capítulo dessa saga pelo simples fato de que foi assim que aconteceu comigo; não tive introdução a computação junto com testes e acredito que não fui o único. Primeiro você aprende a programar e depois a fazer testes, mas recomendaria que todo projeto os testes sejam escritos desde o começo para ser um verdadeiro TDD e o projeto escalando junto com eles.
Indo além
Eu não coloco esse código no Github por motivos de “não tem como”, e você pode se perguntar “como assim?”… Esses trechos de código que eu disponibilizo aqui são feitos com o intuito de serem didático, não são códigos do meu dia a dia, me preocupo mais com outras coisas também como segurança e lógica além de tipagem. Caso ainda continue com vontade de ver o código original que eu fiz, ele pode ser encontrado em:
