Header Ads Widget

Ticker

6/recent/ticker-posts

19 mejores prácticas para las pruebas de automatización con Node.js

 Node js se ha convertido en uno de los frameworks más populares en JavaScript en la actualidad. Utilizado por millones de desarrolladores, para desarrollar miles de proyectos, node js se está utilizando ampliamente. Cuanto más desarrolle, mejores serán las pruebas que necesite para tener una aplicación fluida y sin problemas. Este artículo comparte las mejores prácticas para el nodo de prueba en 2019, para ofrecer una aplicación web o un sitio web robustos.

Digamos que desarrolló una aplicación en Node JS sobre el pronóstico del tiempo. Probar node.js para una aplicación de pronóstico del tiempo es muy complejo debido a numerosos módulos y características. Por ejemplo, la aplicación web te dirá la previsión para hoy y junto a ella te mostrará diferentes parámetros como la precipitación y la humedad. Esta aplicación también requerirá un seguimiento de la ubicación, ya que cada usuario se encuentra en una ubicación diferente. Un usuario que usa la aplicación meteorológica necesita tener datos correctos porque muchas cosas funcionan con el clima del día y de los días siguientes, como planificar un viaje.

Una aplicación meteorológica compleja puede incluir vientos y movimientos de nubes para que los estudien los geólogos. Una aplicación utilizada a tal nivel no puede contener un solo error por el cual se predice el futuro del país completo. Entonces, después del desarrollo de estos módulos, llegamos a probar node.js para estos módulos para que todo esté verificado y funcione bien en tiempo real.

¡Espera ahora! No vamos a realizar pruebas con node.js en una aplicación meteorológica en este artículo. Sin embargo, demostraré un proyecto simple en el que inicializaremos una prueba en Node JS en pequeños pasos para que quede claro al final cómo se crean las pruebas para probar Node JS y podemos enfocarnos en las mejores prácticas para probar node. js en 2019.

Inicialización de una prueba simple en Node JS

Si es nuevo en node.js, aquí inicializaré una prueba simple en node.js para que comprenda el procedimiento de prueba en node.js. Creemos una función básica de multiplicar dos números:

1
2
3
4
function mul(x,y)
{
return x*y;
}

Esta es una función básica para la multiplicación. Pero esta función no es válida para todos los casos y puede no ser válida para varios otros números. No podemos realizar pruebas en tal situación. Ampliaremos esta función para validar la característica de igualdad.

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
dieciséis
function mul(x,y)
{
return x*y;
}
function testMul()
{
var x = 4;
var y = 5;
val mul = x*y;
var mul2 = mul(4,5);
if(mul == mul2)
console.log(‘Equality Test Passed’);
else
console.log(‘Equality Test Failed’);
}
testMul();

Después de escribir las pruebas básicas, inicializaremos el nuevo proyecto de nodo conectándolo al npm.

1
npm init

Ahora necesitas instalar los módulos. A medida que discutimos más en este artículo, aprenderá más sobre la importancia de Mocha y Chai en las pruebas de node js. Mocha le brinda una buena plataforma para definir sus conjuntos de casos de prueba, ganchos y afirmación de uso de cualquier biblioteca que desee usar. Chai, por otro lado, se usa solo para escribir las afirmaciones. Estas afirmaciones son los códigos de prueba legibles por humanos que tienen sus propias ventajas.

1
npm install --save-dev mocha chai

Después de esto, he creado dos archivos js. Uno es test.js y otro mull.js. Guarde test.js en la carpeta de prueba y mull.js en el directorio raíz.

Ahora pegue la función mul escrita arriba con una línea adicional.

1
2
3
4
5
function mul(x,y)
{
return x*y;
}
module.exports = mul;

Exportarlo nos ayudará a agregarlo a la línea require mientras realizamos pruebas con node.js.

Abra su archivo test.js en la carpeta de pruebas y escriba el siguiente código de prueba que se proporciona a continuación para seguir adelante con la prueba con node.js. Este código de prueba probará la igualdad de las dos funciones. La variable de espera es el código objeto de la biblioteca chai para escribir la parte de "espera" de la aserción y multiplicar será la variable que contiene el módulo exportado del código que se encuentra justo encima (module.exports = mul).

01
02
03
04
05
06
07
08
09
10
11
var expect = require(‘chai’).expect;
var multiply = require(‘../mul’);
describe(‘mul()’, function(){
    it(‘should multiply two number’, function(){
var x = 4;
var y = 5;
val mul = x*y;
var mul2 = mul(4,5);
expect(mul2).to.be.equal(mul)
});
});

Simplemente ejecute sus pruebas ahora a través de npm test en la ventana de la consola y estará listo para comenzar.

Mejores prácticas para probar Node JS

Las pruebas indican la estabilidad de su aplicación y, de lo contrario, la hace más estable, lo que a su vez le evita una confirmación incorrecta repentina que puede acabar con todo el software. Es necesario realizar pruebas antes de enviar el código a los usuarios para que nadie se vea afectado por el comportamiento no deseado de la aplicación. Siendo esto importante, veremos algunas de las mejores prácticas para probar Node JS en 2019.

Aislado y atómico

La prueba debe ser atómica y aislada. Cada prueba debe ejecutarse de forma independiente y sin depender de los demás. Si ninguna de las pruebas depende de ninguna otra, si una de ellas falla, las demás no se verán afectadas. Además, las pruebas deben seguir la propiedad de atomicidad. No debería fallar en el medio de repente. Se debe ingresar y salir de una prueba con el resultado de aprobado o reprobado sin problemas.

También debe tener en cuenta que los datos que está probando deben estar separados para cada prueba. Más de una prueba que trabaja con los mismos datos globales daña el motivo general de usar las pruebas en la aplicación. Su tiempo aumentará absolutamente y conducirá a un buen rendimiento, pero no tiene sentido. Mantenga sus datos específicos para las pruebas.

Nombre de su prueba

Esta es una de las características más básicas e importantes para escribir casos de prueba efectivos . Una prueba debe tener un nombre significativo y fácil de entender por otros departamentos que no están relacionados con las pruebas, como el equipo de desarrollo. Un nombre no debe ser un nombre aleatorio como foo () que se usa popularmente. Después de ver que su prueba no es una palabra aleatoria, debe concentrarse en cómo debe nombrar su prueba. Un nombre de prueba debe constituir

  • ¿Qué se está probando?
  • ¿Cuáles son los diferentes escenarios en los que está probando?
  • ¿Cuál debería ser el resultado esperado de la prueba?

Este es un ejemplo de una convención de nomenclatura significativa para probar node.js.

1
2
3
4
function CheckCountryLanguage()
{
//code to check if the application is showing data in the country’s official language
}

El nombre de la prueba anterior tiene sentido porque podemos obtener fácilmente lo que estaría haciendo esa función. ¿Y si hubiera escrito el nombre de la función como foo? Entonces tendría que leer el código completo para comprender el funcionamiento de la función.

Usar afirmaciones

Una afirmación en el lenguaje de programación es una declaración por la que declaramos en el momento de la codificación. Esta declaración puede ser verdadera o no y, por lo tanto, proporciona la salida booleana con verdadero o falso. La declaración en sí contiene el significado del código de prueba, como esperar ('edad'). A.be.equal (23). Esto se explica por sí mismo y corta la lógica de las líneas de código en gran medida. Si la variable 'edad' es igual a 23, entonces se imprime Verdadero o Falso. Puede aprender sobre la afirmación aquí . Las afirmaciones son más beneficiosas que las pruebas normales porque ya proporcionan una declaración en el caso de prueba. Además, cuando se ejecuta una aserción, no es necesario que sepa cuál fue la respuesta y por qué la obtuvo. Solo le proporcionará si la prueba falló o pasó.

Una prueba utilizará la lógica en los casos de prueba, mientras que las afirmaciones son las formas legibles por humanos en las que escribe pruebas en formas legibles por humanos. Esto ayuda al analizar las pruebas después de su ejecución. Puede usar la biblioteca chai para lograr lo mismo y puede obtener más información sobre la biblioteca Chai aquí .

1
expect(‘currentweather’).to.be(‘string’);

Tales afirmaciones son legibles por humanos y se explican por sí mismas sobre la prueba que están realizando. Esta expectativa muestra que el clima actual tiene que ser una cadena como Hazy, Clear o Rainy, etc.

Usar Test Runner

Un ejecutor de pruebas es una biblioteca o herramienta que toma un directorio de código fuente que contiene las pruebas unitarias y las ejecuta. Después de ejecutar las pruebas, vuelve a escribir los resultados en la consola o en los archivos de registro. Siempre se recomienda usar un buen corredor de prueba y algunos de los probadores también usan sus propios corredores de prueba. Si bien tener un ejecutor de prueba puede ser ventajoso con las bases de datos, ya que puede tomar los valores de la base de datos (ficticios o reales) y ejecutar diferentes pruebas en ella. También puede cargar accesorios. Mocha es un corredor de pruebas. Mocha puede proporcionarle una forma programática de ejecutar las pruebas a través de herramientas de línea de comandos en la base de código ES6.

Centrarse en la cobertura de la prueba

Una cobertura de prueba mientras escribe las pruebas es la cantidad de código fuente que está cubriendo en su prueba. En palabras simples, también se puede decir la cantidad de aplicaciones en su conjunto que está cubriendo para su prueba. Al escribir las pruebas, se considera que es lo más importante en lo que trabajar. Entonces, ¿cómo puede aumentar la cobertura de su prueba?

En primer lugar, siempre debe tener en cuenta que el porcentaje de cobertura de la prueba depende totalmente de la naturaleza de su aplicación. Si se trata de una aplicación, digamos Music Player, no es necesario que tenga una cobertura de prueba del 100% porque a medida que aumentamos la cobertura de prueba, se vuelve cada vez más cara para la empresa. Pero si tiene una aplicación importante como cualquier aplicación en tiempo real que recibe datos de satélite o una aplicación para el fabricante de aviones, entonces necesita tener una cobertura del 100% porque afectará en gran medida a la aplicación. Nos centraremos en la cobertura de prueba para los próximos puntos. Para esto, puede usar Mocha junto con Estambul y ejecutar sus pruebas de Mocha en Estambul.

Utilice complementos para la cobertura de prueba

Hay complementos disponibles que prueban toda la cobertura de prueba. Los complementos no lo ayudarán a escribir las pruebas que cubren el código máximo, pero definitivamente lo ayudarán a analizar su prueba y le dirán si se omite una prueba o no. También mostrará si todos los casos de prueba están cubiertos o no. De esta manera, podría estar pensando que ha escrito las pruebas que cubren algún porcentaje del código, pero en realidad se omiten algunas pruebas, lo que reduce el porcentaje general.

Analizar el informe de cobertura de la prueba

Se puede generar un informe de cobertura de prueba con la ayuda de Istanbul y Mocha. Una vez que haya generado el informe de cobertura de la prueba, intente analizar el informe. Un informe con una cobertura de prueba del 90% que podría pensar que no cubrirá el código completo del 90% con sus casos de prueba. Mientras usa Estambul, es bastante fácil y sencillo analizar el informe de cobertura de prueba. Además, debe tomarse en serio la prueba fallida y analizar por qué fallaron y verificar si hay un problema o no.

Utilice pruebas de mutación

La prueba de mutación es el tipo de prueba en la que la condición lógica de los casos de prueba se modifica (muta) para fallar deliberadamente las pruebas o, si no, para pasarla. Las lógicas también se pueden cambiar por las mismas razones. También se le llama popularmente como plantar un error. Hay varias bibliotecas que puede obtener en Internet, pero una de ellas y la más popular es Stryker se puede usar para el mismo propósito.

Compruebe el plagio en las pruebas

Al probar node.js en el código fuente, siempre debe verificar si hay plagio en el código. No es tan raro copiar y pegar el código de Internet para que el software funcione. Es posible que nunca sepa que el código fuente puede obtener una licencia y su organización puede tener serios problemas por el mismo. Estas cosas también violan los derechos de autor. Por lo tanto, recuerde siempre verificar el código en busca de plagio para modificarlo un poco, pero para beneficio de su organización.

Para utilizar el verificador de plagio, puede instalar el paquete js npm plagiarism-checker del nodo .

Para instalarlo, simplemente escriba el siguiente código:

1
npm i plagiarism-checker

Después de eso, para usar ese SDK, escriba el siguiente código:

1
2
3
var a = require('plagiarism-checker');
var b = new a();
var config = b.getConfig();

Descarga el código de este repositorio y agrégalo a tu proyecto. Tenga en cuenta que las siguientes dependencias están instaladas

1
2
3
4
$ npm install lodash
$ npm install request
$ npm install request-promise
$ npm install mime-types

Utilice entradas realistas

Muchas veces sucede que los probadores utilizan las entradas que no son realistas o de acuerdo con los escenarios de la vida real. Por ejemplo, una entrada que requiera números de teléfono debe probarse en números que se parezcan a los números de teléfono reales. Por lo tanto, siempre debe usar entradas realistas al probar su aplicación. La mejor biblioteca disponible para este propósito es la biblioteca Faker. Según GitHub, la biblioteca Faker es una biblioteca php que genera datos falsos para la entrada que está dispuesto a probar.

También debe tener en cuenta el uso cada vez mayor de entradas para un solo parámetro de entrada para realizar pruebas intensivas. Como en la vida real, muchas entradas se procesarán en la misma función, debe usar tantas como sea posible para probarlas.

Un simple retrato de la situación puede ser la misma aplicación meteorológica que discutimos al comienzo de este capítulo.

1
2
3
4
function CountryName(string country)
{
//code
}

Ahora, esta función debe probarse con entradas realistas como

1
2
3
4
5
6
7
8
function CountryName(India)
{
//code
}
function CountryName(Netherlands)
{
//code
}

En lugar de :

1
2
3
4
5
6
7
8
function CountryName(abc)
{
//code
}
function CountryName(foo)
{
//code
}

Utilice linters

Según Wikipedia, linter es una herramienta que analiza el código fuente para marcar errores de programación, errores, errores de estilo y construcciones sospechosas. Los linters son excelentes para encontrar ciertas clases de errores, incluida la asignación a una variable no declarada y el uso de variables no definidas. El uso de linters puede ayudarlo mucho a determinar los errores en la forma estructural del código. Para Node JS, puede usar ESLint para el mismo propósito.

Pruebas basadas en propiedades

Las pruebas basadas en propiedades dependen de diferentes propiedades de la función. Se utiliza para verificar la propiedad de la entidad (función, programa, etc.) en particular. Una propiedad es una característica de la entidad. Por ejemplo, si tiene una función que toma los argumentos de entrada como a, by mantiene la propiedad de que b siempre es par entonces mediante la verificación basada en propiedades, verificamos si b es siempre par o no.

para todos (a, b)

b es siempre un número par

Las pruebas basadas en propiedades nos ayudan a

  • Contiene el alcance de todas las entradas y eso puede generar una gran cantidad de casos de prueba
  • Puede llevarnos a la falla en muy poco tiempo ya que tiene algo específico para poner como entrada como números pares en el caso anterior. Puede seguir insertando números pares hasta el punto en que falla y podemos obtener el valor de umbral de la función con bastante facilidad.

Puede utilizar FastCheck, QuickCheck o Mocha Test Check para realizar pruebas basadas en propiedades.

Usar la biblioteca Chai

La detección de errores debe realizarse con bibliotecas específicas como la biblioteca Chai. Espera las afirmaciones y, por lo tanto, le da de qué se trata el error. Este podría no ser el caso con la declaración try-catch-finalmente. Una declaración Try-Catch-Finalmente arrojará alguna declaración de error genérica porque toma las excepciones como una clase completa de excepciones y errores y no da el resultado específico sobre lo mismo. Luego, se necesita mucho tiempo para decodificar de qué se trata realmente el error.

Por ejemplo,

1
expect(‘a’).to.not.have.property(‘b’);

de esta manera, pocas líneas de código se resumen en una sola línea de aserción chai.

Verifique escenarios excepcionales

Si bien los casos de prueba y los escenarios que diseñe pueden cubrir todo en el código fuente, hay algunas excepciones que son muy importantes al probar el comportamiento / respuesta / resultado de la aplicación. Digamos que hay una función en su aplicación que envía un correo electrónico cuando se agrega un nuevo usuario. El correo electrónico se envía tanto al administrador como al usuario. Esto se convierte en un escenario excepcional, ya que el método debe pasar correctamente, pero es posible que no reciba ningún correo electrónico. Estas cosas deben probarse. La prueba también debe incluir el envío forzoso de código de respuesta diferente desde el lado del servidor para que podamos saber cómo se comporta la aplicación de esa manera y qué valores se devuelven.

Muchas empresas desarrollan sus propios métodos para lograr estas cosas. Un buen ejemplo es Netflix, que ha desarrollado algo que llaman Chaos Engineering, que prueba sus funciones y método eliminando sus servidores uno por uno. De esta forma también se les asegura que incluso si falla un servidor, la aplicación funciona correctamente.

Siga la pirámide de pruebas

Mientras prueba con node.js, debe intentar seguir la pirámide de automatización de pruebas . Como se ve en la siguiente imagen, la prueba unitaria debe tomarse como la base de todas las pruebas.

Prueba de automatización

Lo hacemos porque la prueba unitaria cubrirá las unidades básicas de funcionalidad independientemente unas de otras. Una vez realizadas las pruebas unitarias, continúe con las pruebas de integración. Las pruebas de integración le permitirán probar los diferentes módulos combinados entre sí como un grupo. Después de eso, pasamos a la siguiente parte de la pirámide y probamos las pruebas de interfaz de usuario o front-end utilizando Selenium o herramientas similares.

Como puede ver, el costo incurrido sigue aumentando a medida que avanzamos hacia la pirámide, pero la velocidad sigue disminuyendo. La prueba unitaria toma la mayor parte del tiempo para ejecutarse, mientras que la interfaz se prueba más rápido debido a la menor complejidad y los módulos.

Usar pruebas de componentes

La prueba de componentes prueba la funcionalidad de los módulos que se pueden probar por separado. El comportamiento de entrada / salida del objeto de prueba es verificado por la prueba de componentes.

Prueba de automatización

Como se ve en la imagen, cada componente tiene un plan de prueba y cada plan de prueba tiene varias pruebas diferentes debajo y luego se prueban para verificar la funcionalidad del componente. Se recomienda utilizar la prueba de componentes después de la prueba unitaria en la pirámide. La prueba de componentes es un enfoque muy bueno y tiene una gran cobertura y una velocidad mayor que la prueba unitaria.

Tenga en cuenta los problemas de infraestructura

Más a menudo, los probadores piensan que la prueba del código fuente teniendo en cuenta las prácticas anteriores es todo lo que tienen que hacer para el correcto funcionamiento de la aplicación. Pero están equivocados. Los probadores tienden a olvidar los problemas de infraestructura y probarlos, que tienen un gran porcentaje de suceder en los escenarios prácticos de la vida real. Estos problemas de infraestructura incluyen la sobrecarga de la memoria y cómo se comporta la aplicación cuando ocurre. Otros problemas de infraestructura pueden incluir el apagado repentino del servidor o API que se vuelve un 50% más lento que se usa en la aplicación. Las pruebas de infraestructura incluyen probar estos problemas y proporcionar un informe de retroalimentación al respecto para que puedan administrarse de manera eficiente.

Yendo en paralelo

Las pruebas en paralelo significan ejecutar varios casos de prueba, simultáneamente. La ejecución de diferentes pruebas en paralelo tiene sus propias ventajas. Si no está siguiendo el paralelismo, entonces ejecutará una prueba y proporcionará los comentarios al respecto, luego ejecutará otras pruebas y proporcionará comentarios al respecto, etc. Estas retroalimentaciones luego se analizan y se trabajan. Luego, el equipo verificará los comentarios de la segunda prueba que hizo y luego los resolverá. Mientras sigue el paralelismo, puede reducir drásticamente el ciclo de retroalimentación y proporcionar retroalimentación de muchas pruebas en conjunto que se pueden resolver en menos tiempo que antes. De esta forma se puede ahorrar mucho tiempo y recursos de la empresa. Hay muchas bibliotecas disponibles para realizar pruebas en paralelo, siendo las más populares Mocha y Jest.

Automatice la actualización de sus dependencias

Ejecutar las pruebas y seguir diferentes reglas requiere muchas bibliotecas y diferentes herramientas para trabajar en conjunto para lograr la prueba perfecta. Pero a veces sucede que las dependencias quedan obsoletas y otras dependencias requieren la última versión para ejecutarse entre sí. Esto crea una perturbación en el buen funcionamiento de las pruebas y se puede resolver automatizando la actualización de sus dependencias. Una vez que automatice la actualización, cada dependencia se actualizará por sí misma y no requerirá una intervención manual después de levantar la bandera para la misma.

Utilice una cuadrícula de selenio en línea para pruebas en varios navegadores

Hablando de automatización, todo el mundo favorece a Selenium como fuente abierta para realizar pruebas en varios navegadores . Sin embargo, existe una limitación en la cantidad de navegadores y máquinas a las que tiene acceso a medida que avanza en la configuración de su cuadrícula de Selenium . La realización de una ronda exhaustiva de pruebas automatizadas entre navegadores requiere un proveedor basado en la nube como LambdaTest .

LambdaTest ofrece una cuadrícula de Selenium en línea con la que puede realizar pruebas con node.js en más de 2000 navegadores reales y versiones de navegadores que se ejecutan en diferentes sistemas operativos. Puede automatizar su proceso de prueba e incluso puede realizar pruebas con node.js en paralelo. Incluso puede realizar pruebas utilizando cualquier otro marco de automatización de pruebas con respecto a diferentes lenguajes como Python, PHP, C #, Java y más.

Bueno, eso fue todo de mi parte. Probar con node.js puede parecer un poco aterrador al principio. Sin embargo, puede deshacerse de las dudas y actuar como un profesional si tiene en cuenta las mejores prácticas anteriores para probar Node JS. Avíseme si hay alguna práctica especial que me haya perdido y que crea que es indispensable para el artículo. ¡Feliz prueba!

Publicar un comentario

0 Comentarios