¿Qué marcos de prueba se pueden utilizar para Node? El siguiente artículo compartirá con usted algunos marcos de prueba de Node.js. ¡Espero que le resulte útil! 
Curso de introducción rápida a Node.js: entra para aprender
Nota del editor: el autor de este artículo es Tianzhu, un ingeniero de Node.js en Ant Group. Primero presentará las bibliotecas de clases más utilizadas en cada parte y discutirá si las pruebas unitarias son necesarias. para discutir juntos.
moca y broma se utilizan comúnmente. La prueba oficial del nuevo nodo aún se está puliendo y el futuro es prometedor.
$moca prueba/egg-view-ejs.test.js prestar ✓ debería renderizar con los locales ✓ debería renderizar con caché ✓ debe renderizar con diseño ✓ debería generar un error renderizar cadena ✓ debería renderString con datos ✓ debería representar un error de cadena 6 pases (398ms)
Aunque hay tantos Runners, todos sus estándares de salida están en formato TAP y los resultados se generan a través de diferentes Reporters.
No basta con escribir una sola prueba. Necesitamos saber si todos los procesos de rama del código están cubiertos, por lo que normalmente necesitamos utilizar herramientas de cobertura de código.
Solía ser istanbuljs, pero luego el autor reescribió nyc. Tienen principalmente dos responsabilidades: una es traducir el código para insertar el código de acumulación y la otra es ayudar a varios reporteros a generar informes de cobertura.
Más tarde, estadísticas de cobertura integradas de V8.
, es decir, ya no es necesario traducir el código y la recopilación de datos de cobertura es compatible de forma nativa.
Luego este autor redactó un c8 enfocado a generar informes de cobertura.
Para verificar resultados variables, afirmar es esencial.
Históricamente: expect.js, debería.js, chai y power-assert, jest también tiene su propio expect incorporado.
Pero ahora la afirmación/estricción oficial de Node.js es bastante buena.
Entre ellos, power-assert es lo que hemos estado usando en EggJS. También lo mencioné hace muchos años: "Probablemente la mejor biblioteca JS Assert: The Emperor's New Clothes".
const afirmar = requerir('poder-afirmar');
describir('prueba/showcase.test.js', () => {
ajuste constante = [1, 2, 3];
it('afirmación de poder', () => {
afirmar(arr[1] === 10);
});
});
//producción:
4) prueba/showcase.test.js afirmación de potencia:
Error de afirmación: # prueba/showcase.test.js:6
afirmar(arr[1] === 10)
|
| 2 falso
[1,2,3]
[número] 10
=> 10
[número] arreglo[1]
=> 2PD: Si desea verificar el contenido del archivo, también escribí un archivo de afirmación, bienvenido a probarlo.
Debido a que es una prueba unitaria, a menudo es necesario simular el entorno o las respuestas posteriores.
sinonjs no es malo y admite simulacros, stubs, etc. jest también tiene su propia biblioteca simulada incorporada.
Si se trata de una prueba HTTP, nock es muy poderoso y puede ayudarlo a burlarse de la respuesta del servidor.
nock('http://www.ejemplo.com')
.post('/iniciar sesión', 'nombre de usuario=pgte&contraseña=123456')
.respuesta(200, {identificación: '123ABC' })Sin embargo, la biblioteca oficial de solicitudes undici de Node.js también tiene capacidades simuladas integradas.
También existe un término llamado instantánea, que significa volcar los datos durante la operación y usarlos directamente como datos simulados para la siguiente prueba, lo que puede mejorar la eficiencia de la escritura de pruebas hasta cierto punto.
Para probar escenarios de servidor HTTP, la biblioteca supertest es indispensable.
describir('OBTENER /usuarios', función() {
it('responde con json', función asíncrona() {
solicitud de devolución (aplicación)
.get('/usuarios')
.set('Aceptar', 'aplicación/json')
.expect('Tipo de contenido', /json/)
.esperar(200)
.entonces(respuesta => {
afirmar (respuesta.cuerpo.correo electrónico, '[email protected]');
});
});
});Uno de los principales escenarios de uso de Node.js es la CLI de línea de comandos, como Webpack y Babel, que a su vez también requieren pruebas unitarias.
Esto es lo que recomendamos:
GitHub - node-modules/clet: Pruebas E2E de línea de comando
GitHub - node-modules/coffee: Probar la línea de comando en Node.js
importar {corredor, LLAVES} desde 'clet';
it('debería funcionar con texto estándar', async () => { await runner() .cwd(tmpDir, { init: true }) .spawn('npm init') .stdin(/name:/, 'example') // espera la salida estándar, luego responde .stdin(/version:/, new Array(9).fill(KEYS.ENTER)) .stdout(/"name": "example"/) // valida la salida estándar .notStderr(/ npm ERR/) .file('package.json', { nombre: 'ejemplo', versión: '1.0.0' }) // validar archivo });
Para un rastreo de páginas ligero, se recomienda utilizar HTTP directamente para solicitar la biblioteca.
Para simular la ejecución real del navegador, se utilizaron selenium y phantomjs en los primeros días.
Luego, Google lanzó oficialmente el titiritero. Debido a la acumulación de Chromium y basado en el protocolo del protocolo devtools, rápidamente se hizo popular y eliminó a los dos primeros. Productos competidores similares incluyen dramaturgo y ciprés.
Por cierto, voy a descargar macacajs, una herramienta de prueba multiterminal que, además de los navegadores, también admite pruebas de aplicaciones móviles y aplicaciones de escritorio. Es de código abierto por los ingenieros del equipo de Yuque.
Cuando escribimos código abierto, a menudo necesitamos servicios automatizados de integración continua que nos ayuden a realizar las pruebas.
Los jugadores en este campo incluyen: Travis, Appveyor, GitHub Actions, etc.
Ahora básicamente uso GitHub Actions y el nivel de integración es genial.
No hay duda de que las pruebas unitarias son muy importantes. Es una habilidad y cualidad profesional necesaria de un programador calificado.
Por supuesto, no somos fanáticos de la cobertura al 100%. En muchos casos, debemos buscar el punto de equilibrio del ROI.
En primer lugar, permítanme corregir el punto de vista común de los recién llegados: ¿escribir pruebas unitarias es una pérdida de tiempo?
De hecho, escribir pruebas unitarias le ahorrará tiempo. La razón de esta visión contraria a la intuición es que las condiciones de comparación a menudo no son objetivas. Necesitamos considerar el costo de la regresión después de modificar el código dos veces bajo los mismos requisitos de calidad.
Para una comparación justa, además de considerar el "tiempo para escribir una sola prueba", lo que fácilmente se pasa por alto es el "tiempo para realizar pruebas de regresión después de cada modificación de código":
Al escribir una sola prueba, cree varias simulaciones de rama en la etapa inicial, y el momento para la prueba de regresión es simplemente escribir en el teclado;
Sin escribir una sola prueba, debe actualizar el código en la aplicación y luego simular manualmente varias situaciones para probar, como abrir un navegador y hacer clic en muchos lugares diferentes.
El tiempo que consumen estos dos se puede ver a simple vista.
No es más que inversión inicial + coste de mantenimiento + énfasis en la calidad del retorno. Cada empresa tiene su propio baremo a la hora de tomar decisiones tras sopesarlas.
Por supuesto, muchos de los escenarios que mencioné son bibliotecas de marco (incluidos front-end y Node.js), aplicaciones del lado del servidor, herramientas de línea de comandos, etc. Es cierto que algunas aplicaciones front-end que tienen un gran cambio en La visualización de la interfaz de usuario o la carga y descarga rápidas son Para la página de actividad, el costo de mantenimiento de la prueba única correspondiente es realmente muy alto. En este momento, es razonable abandonar adecuadamente las pruebas individuales de algunas ramas no principales según el ROI.
Pero debemos entender que este es un último recurso. Podemos reducir el costo de mantenimiento de las pruebas unitarias a través de varios medios, pero no podemos afirmar que las pruebas unitarias sean inútiles.
También hay una prueba de regresión semiautomática en el campo front-end, que se basa en diferencias para automatizar la comparación y luego recordarle al propietario que preste atención al impacto de los cambios. Esto es similar a las bibliotecas de herramientas anteriores, todas las cuales están aquí para ayudar a reducir el costo de escribir pruebas individuales.
Esta también es una visión incorrecta. Las pruebas unitarias deben ser escritas por los propios programadores , porque es su propio código y usted debe ser responsable de ello. Cualquier equipo con un poco de estandarización necesita pruebas de CI al enviar el código; de lo contrario, no habrá una colaboración de revisión de código de calidad.
Los estudiantes de pruebas son responsables de trabajos de mayor nivel, como pruebas de integración, pruebas de regresión y pruebas de un extremo a otro .
La división del trabajo es diferente, así que no culpes a los demás.
Las pruebas unitarias son muy necesarias. Escribir pruebas unitarias es la cualidad profesional básica de los programadores. Escriba tanto como pueda. En escenarios individuales, puede tomar decisiones basadas en el ROI.