Documentación de Mocha
Probar si una parte individual de una aplicación, como una función o un método, es apta para su uso. Una unidad puede definirse como la parte más pequeña comprobable de una aplicación. Los desarrolladores realizan pruebas unitarias para asegurarse de que una unidad, por sí sola, puede realizar lo que se pretende hacer sin afectar a otras áreas del código.
A medida que su código se vuelve más complejo con nuevas funciones, dependencias y clases, es importante tener pruebas unitarias en su aplicación para comprobar si alguno de los nuevos códigos está creando errores en la aplicación. Esto hace que sea más eficiente para detectar bugs y errores en su código.
Como puedes ver en el código, estamos usando el propio CSS de Mocha para dar estilo a la página y cargando mocha.js y chai.js <script> en la página. Luego llamamos a mocha.setup(‘bdd’) para cargar su interfaz BDD (Behavior Driven Development).
Nota: En la práctica, hay muchos casos en los que la función puede ser incorrecta pero las pruebas se pasan. Una forma adecuada de lidiar con esto es entender lo que se supone que la función debe hacer y probar para ese uso específico.
Pruebas unitarias de Node js con mocha y chai
Mocha.js proporciona funciones que se ejecutan en un orden específico y registra los resultados en la ventana del terminal. También limpia el estado del software que se está probando para garantizar que los casos de prueba se ejecuten de forma independiente.
El desarrollo dirigido por el comportamiento (BDD) tiene como objetivo ayudar a los desarrolladores a construir software que sea predecible, resistente a los cambios y no propenso a errores. Ha evolucionado a partir del desarrollo dirigido por pruebas (TDD), que requiere que se haga:
La principal diferencia entre TDD y BDD es que BDD exige escribir los casos de prueba en un lenguaje compartido para simplificar la comunicación entre las partes interesadas técnicas y no técnicas, como los desarrolladores, los equipos de control de calidad y los líderes empresariales.
En este momento, tenemos todo configurado para ejecutar sus pruebas con Mocha, pero todavía no tenemos ninguna prueba que ejecutar. El siguiente paso es comenzar a escribir pruebas para las funcionalidades deseadas de su software.
Si estás usando Mocha en un entorno Node.js, puedes usar el módulo assert incorporado como tu biblioteca de aserciones. Sin embargo, hay bibliotecas de aserción más extensas que puedes utilizar, como Chai, Expect.js, Should.js, etc.
Ejemplo de prueba de Mocha github
# Resumen del ciclo de ejecuciónActualizado para la v8.0.0.Lo siguiente es un esquema de nivel medio del “flujo de ejecución” de Mocha cuando se ejecuta en Node.js; se han omitido los detalles “menos importantes”.En un navegador, los archivos de prueba se cargan mediante etiquetas <script>, y la llamada a mocha.run() comienza en el paso 9 de abajo.# Modo en serie# Modo en paralelo# Detecta múltiples llamadas a done()Si utilizas pruebas asíncronas basadas en callbacks, Mocha lanzará un error si se llama a done() varias veces. Esto es útil para detectar devoluciones de llamada dobles accidentales.it(‘double done’, function (done) {
# AssertionsMocha te permite utilizar cualquier librería de aserción que desees. En el ejemplo anterior, estamos utilizando el módulo de aserción incorporado de Node.js – pero generalmente, si lanza un Error, ¡funcionará! Esto significa que puedes utilizar librerías como:# Código asíncronoAgregando un argumento (normalmente llamado done) a it() a un callback de prueba, Mocha sabrá que debe esperar a que esta función sea llamada para completar la prueba. Este callback acepta tanto una instancia de Error (o subclase de la misma) como un valor falso; cualquier otra cosa es un uso inválido y lanza un error (normalmente causando un test fallido).describe(‘User’, function () {
Prueba del chai
Por ejemplo, creamos una función f. Escribimos algo de código, probamos: f(1) funciona, pero f(2) no funciona. Arreglamos el código y ahora f(2) funciona. Parece completo… Pero nos olvidamos de volver a probar f(1). Eso puede dar lugar a un error.
Eso es muy típico. Cuando desarrollamos algo, tenemos en mente muchos casos de uso posibles. Pero es difícil esperar que un programador los compruebe todos manualmente después de cada cambio. Así que es fácil arreglar una cosa y romper otra.
Las funciones assert.* se utilizan para comprobar si pow funciona como se espera. Aquí estamos usando una de ellas – assert.equal, que compara los argumentos y da un error si no son iguales. Aquí comprueba que el resultado de pow(2, 3) es igual a 8. Hay otros tipos de comparaciones y comprobaciones, que añadiremos más adelante.
Así, el desarrollo es iterativo. Escribimos la especificación, la implementamos, nos aseguramos de que las pruebas pasan, luego escribimos más pruebas, nos aseguramos de que funcionan, etc. Al final tenemos una implementación que funciona y pruebas para ella.
La principal diferencia es que cuando assert provoca un error, el bloque it termina inmediatamente. Así que, en la primera variante, si el primer assert falla, nunca veremos el resultado del segundo assert.
