javascript - tutorial - pruebas unitarias node js

¿Cuál es el mejor enfoque para el controlador js del nodo de prueba unitaria que utiliza un método de servicio?

Question

Mi controlador => debajo del controlador está utilizando el método reqpoertService.getFiles y ese método en sí mismo utiliza una API externa para llamar a los datos.

function getFiles(req, res) {
reportService.getFiles({
fromDate: req.query.fromdate,
endDate: req.query.enddate,
fileTypes: req.query.filetypes || [],
fileStatus: req.query.filestatus || []
})
.then(data => {
logger.info(''-> reportService.getFiles :: Successfully fetched data'',
resolveLogger({ statusCode: res.statusCode })
);
res.send(data);
})
.catch(err => {
logger.error(''<- OOPS :: reportService.getFiles fail to fetch data'');
res.status(statusCodes.INTERNAL_SERVER_ERROR).send({});
logger.error(''<- ERROR'', resolveLogger({
statusCode: res.statusCode,
errMessage: err.message,
errorStack: err
}));
});
}

Servicio de reportero

function getFiles() {
return new Promise((resolve, reject) => {
requestPromise(options)
.then(data => {
var duration = new Date - start;
logger.info(resolveLogger({
duration: duration + ''ms'',
reqUrl: options.url,
bodyLengh: data && data.length
}));
logger.info(''<= Request complete successfully.'');
var resData = JSON.parse(data);
resolve(resData);
})
.catch(error => {
logger.error(''=> Request failed for URL:'', options.url);
reject(error);
});
});
}

Mi enfoque de prueba de unidad para probar el controlador anterior

it(''METHOD: getFiles -> should response 500 without data'', done => {
nock(''http://localhost:1708/fakeapi'')
.get(''/files'')
.reply(statusCodes.INTERNAL_SERVER_ERROR);
const res = buildResponse();
const req = httpMocks.createRequest({
method: ''GET'',
url: ''/api/submitted-data/1/files''
});
res.on(''end'', function () {
var data = res._getData();
expect(data).toEqual({});
expect(statusCodes.INTERNAL_SERVER_ERROR).toBe(res.statusCode);
done();
nock.cleanAll();
});
reporterController.getFiles(req, res);
});

¿Puede alguien sugerirme que el enfoque que estoy siguiendo es aceptable o que hay un mejor enfoque para hacer la prueba unitaria? Como soy principiante para hacer las pruebas unitarias.

Answer 1

Creo que su enfoque está en el camino correcto. Sus pruebas deben desacoplarse tanto de la implementación como sea posible. Por lo tanto, su código de prueba no debería saber realmente cómo ha implementado su código. Simplemente le importa que cuando llegue a sus puntos finales, el resultado sea el esperado. Desea simular las partes externas de su código, es decir, el código que no se ejecutará cuando ejecute la prueba, como las API externas. Puede simular ciertas respuestas que las API externas para que pueda escribir pruebas para cubrir esos tipos de escenarios y luego manejarlos como desee.

Este artículo de ThoughtWorks es bastante útil para explicar este enfoque de las pruebas: https://www.thoughtworks.com/insights/blog/mockists-are-dead-long-live-classicists

También sugiero ver el título de este video, Ian Cooper: TDD, donde todo salió mal: https://vimeo.com/68375232

Agradezco que mi sugerencia sea un poco de alto nivel, en resumen, creo que su prueba debería verse así:

1. establezca el contexto de su prueba, establezca datos, etc. Por lo tanto, en su caso, asegúrese de que exista un archivo (esto podría ser una respuesta burlada si proviene de una API externa)
2. configure burlas para su apis externa (para cubrir si la API externa se agota, está inactiva, 401, 500 etc.).
3. llama a tu api
4. afirmar el resultado que devuelve su punto final api

A continuación, puede tener diferentes pruebas que comprueban las diferentes respuestas que devuelven las API externas.

Answer 2

Tengo una crítica de su prueba unitaria, y es que no está utilizando BeforeAll / each para configurar realmente su prueba.

Lo que quiero decir con esto es:

• Puede usar el bloque de descripción en el que está anidado el "it" para declarar las variables que se establecerán durante la configuración de la prueba (beforeEach / All) y deben ser las que realmente "espera" durante el "it".
• Los "ellos mismos" deberían ser más limpios y más pequeños, casi solo compuestos por expectativas.

Aparte de eso, se ve bien.