Esta semana deveríamos adicionar test à nossa ferramenta cli. Até agora, a coisa mais frustrante de se fazer.

Por que escolhi Jest

Sou um grande defensor do TDD (Test Driven Development). Quase todo código de peça deve ser testado. Durante minha cooperativa, passei mais da metade do tempo escrevendo testes para minhas relações públicas. Acredito que essa experiência realmente me ajudou a entender a necessidade dos testes. Fiquei surpreso ao ver como a estrutura de teste em JS e Ruby é semelhante. Usei o Jest, que é muito semelhante ao RSpec que usei durante minha cooperação. Para simular a solicitação http, usei o Nock, meio semelhante a algo chamado VCR.

Problemas que enfrentei (muitos deles)

O principal problema que enfrentei foi usar ESM em vez de CommonJS. O que tornou minha vida muito mais difícil. O primeiro problema foi jest.mock não funcionar. Depois de algumas pesquisas percebi que a forma de zombar é diferente no ESM. Infelizmente, mesmo depois de seguir a documentação, não consegui fazê-lo funcionar. Então, eu tive que fazer jest.spyOn. O segundo problema que enfrentei foi que o execa executa em child_process o index.test.js, embora ele não afete o relatório de cobertura. Então tive que usar jest.spyOn para reescrever o teste. Também tive que refatorar o index.js para que ele não levasse as flags que estou passando para brincadeira. Outro problema menor que enfrentei foi usar node --experimental-vm-modules --no-warnings node_modules/jest/bin/jest.js -c jest.config.mjs em vez de jest -c jest.config.mjs porque eu estava usando o ESM. Eu também tive que usar mock-fs para replicar o sistema de arquivos para testar FilepathResolver.test.js porque o simples jest.spyOn não o testou completamente o suficiente. Fiquei surpreso com quantos obstáculos foram causados ​​apenas pelo uso do ESM e isso apenas reflete a bagunça que o JS é.