Soy nuevo en las pruebas unitarias en su conjunto y especialmente nuevo con javascript. Estoy trabajando en algunas pruebas unitarias con Jest y encontré este script que no tiene mucho sentido para mí. Pero, pensé que intentaría escribir una prueba para ello.
Soy completamente nuevo en esto, así que incluso aprender sobre EventEmitter me está desconcertando. Leí que tiene que llamar, en este caso, newCommandEmitter pero este script no tiene eso en absoluto. Son solo tres líneas.
El código está debajo, pero quiero saber, ¿vale la pena escribir una prueba para esto?
const EventEmitter = require('events') const newCommandEmitter = new EventEmitter() module.exports = newCommandEmitterMi script de prueba es el siguiente:
const newCommandEmitter = require("./newCommandEmitter.js"); const events = require("events"); jest.mock("./newCommandEmitter.js"); jest.mock("events") describe("Testing for events if command is used for events.", () => { test("First test to see if we get events data.", async () => { expect(newCommandEmitter).toBeTruthy(); }); });Respuesta corta: No, no vale la pena probar un código como este.
¿Por qué?
Ineficiencia de tiempo: probar rutas de ejecución triviales/piezas de código (como la que ha proporcionado) nos brinda pocos o ningún beneficio, pero cuesta mucho tiempo, debido a la frecuencia con la que aparece dicha ruta/código. Es por eso que generalmente probamos todo lo que posiblemente pueda romperse. Las pruebas exageradas desperdician un tiempo precioso que se puede utilizar para escribir código funcional o escribir pruebas donde se necesitan.
Cuestionando los axiomas de nuestro lenguaje/marco de programación: lo que está haciendo aquí puede considerarse como tal, porque lo único que hace además de exportar/importar es crear un objeto con un constructor integrado. Cuando usamos funciones integradas, asumimos que funcionan bien tal como están y que nunca deberían romperse (excepto en los casos especificados en los documentos). De lo contrario, para mantener la coherencia, necesitaríamos cuestionar todas y cada una de las funciones, clases y operadores que nos proporcionaron los creadores del lenguaje/biblioteca. Las pruebas unitarias no deben probar el lenguaje en el que está escrito el código, sino el código en sí.