Esta semana se suponía que íbamos a agregar pruebas a nuestra herramienta CLI. Hasta ahora lo más frustrante que se puede hacer.

Por qué elegí Jest

Soy un gran partidario de TDD (Desarrollo basado en pruebas). Casi todos los códigos de pieza deben probarse. Durante mi cooperativa, pasé más de la mitad del tiempo escribiendo exámenes para mis relaciones públicas. Creo que esa experiencia realmente me ayudó a comprender la necesidad de realizar pruebas. Me sorprendió ver cuán similares son los marcos de prueba en JS y Ruby. Usé Jest, que es muy similar a RSpec que usé durante mi cooperativa. Para simular una solicitud http utilicé Nock, algo similar a algo llamado VCR.

Problemas que he enfrentado (muchos de ellos)

El principal problema al que me enfrenté fue que usé ESM en lugar de CommonJS. Lo que hizo mi vida mucho más difícil. El primer problema fue que jest.mock no funcionaba. Después de investigar un poco, me di cuenta de que la forma de burlarse es diferente en ESM. Desafortunadamente, incluso después de seguir los documentos no pude hacerlo funcionar. Entonces, tuve que hacer jest.spyOn. El segundo problema que enfrenté fue que execa se ejecuta en child_process index.test.js, aunque se ejecuta, no afecta el informe de cobertura. Entonces tuve que usar jest.spyOn para reescribir la prueba. También tuve que refactorizar index.js para que no tome las banderas que estoy pasando en broma. Otro problema menor que enfrenté fue el uso de node --experimental-vm-modules --no-warnings node_modules/jest/bin/jest.js -c jest.config.mjs en lugar de jest -c jest.config.mjs porque estaba utilizando ESM. También tuve que usar simulacro-fs para replicar el sistema de archivos y probar FilepathResolver.test.js porque el simple jest.spyOn no lo probó lo suficientemente a fondo. Me sorprendió la cantidad de obstáculos que se produjeron simplemente usando ESM y esto simplemente refleja el desastre que es JS.

Después de muchos errores de prueba obtuve una cobertura bastante buena.