Santiago Gonzalez
student•
hace 4 años
Santiago Gonzalez
Jose Gabriel Argüello
David Hilera
Juan Camilo Vega
Francisco Alejandro García Munguía
Jhonathan Andres Mauricio la Torre
David Antonio Garcia Saaib
Nicolas Molina
Jorge Mario Martinez Martinez
Andrés Mauricio Gutiérrez Rojas
Daniel Achury
Miguel Angel Reyes Moreno
Iván Antonio Bustos Calderón
configuración de jest
{ "moduleFileExtensions": ["js"], "rootDir": ".", "testEnvironment": "node", "testRegex": ".e2e.js$" }
script de package.json
"test:e2e": "jest --config ./e2e/jest-e2e.json --forceExit",
no se si lo veremos en las próximas clases pero lo podemos resolver con async/await :
describe('test for [GET]/', () => { test('should return "Hello World!', async () => { const response = await request(app).get('/'); console.log('response', response); expect(response.text).toEqual('Hello World!'); }); });
Gracias por el aporte.
Aparentemente al profe no le falla, pero es porque al usar --forceExit no espera que llegue la respuesta y obliga la salida del test. Sin embargo el mismo jest te manda un mensaje que uses --detectOpenHandles para manejar asincronía y es ahí cuando notas que la prueba en realidad no es pasada. Tu solución me ayudo a entender mejor como funciona, de nuevo gracias.
Ahora que he decidido no renovar la suscripción, encuentro tus cursos. Es una pena que no estés a cargo de la escuela de Javascript :S
Las pruebas e2e las guardamos en una carpeta aparte llamada e2e. En esa carpeta creamos el archivo de configuración de jest para las pruebas e2e "jest-e2e.json". En ese archivo le decimos a jest como correr nuestras pruebas de integración.
{ // Como van a ser nuestros archivos, nuestro stack. "moduleFileExtensions": ["js"], // Cuál es nuestra ruta principal "rootDir": ".", // Cuál es el ambiente de pruebas. "testEnvironment": "node", // Expresiónregular para reconocer pruebas "testRegex": ".e2e.js$" }
En nuestro package.json agregamos el siguiente comando en scripts:
"test:e2e": "jest --config ./e2e/jest-e2e.json --forceExit"
describe('GET /', () => { test('should return a hello world message', async () => { const response = await request(app).get('/'); console.log('🚀 ~ file: hello.e2e.js:20 ~ test ~ response:', response.text); expect(response.status).toBe(200); expect(response.text).toBe('Hello World!'); }); }); ``` describe('GET /', () => { test('should return a hello world message', async () => { const response = await request(app).get('/'); console.log('🚀 ~ file: hello.e2e.js:20 ~ test ~ response:', response.text); expect(response.status).toBe(200); expect(response.text).toBe('Hello World!'); }); });
Hacer las request desde un postman cuenta como una prueba e2e? I mean, utilizando la DB conectada cuenta como 2e2?
Hola, no cuenta como e2e, ya que el objetivo de una prueba es que sea automatizada y pueda validar que cumpla con ciertos criterios y postman no lo haría. Pero Postman tiene Automated Testing en el cual si puedes llegar a escribir pruebas e2e con postman.
Error: Can't find a root directory while resolving a config file path. Provided path to resolve: ./e2e/jest-e2e.json
Recuerda ajustar el package.json con la ruta desde la que estés ejecutando las pruebas e2e, por lo menos a mi me sirvió este: "test:e2e": "jest --config ./api/e2e/jest-e2e.json --forceExit",
Hola, es necesario tener el proyecto que vamos a probar dentro de nuestro proyecto de pruebas?, considero que puede ser difícil de mantener cuando el proyecto es muy grande. otra pregunta, puedo tener un proyecto enfocado a probar una API alojada en la nube?
Ahora veo por qué a los QA les pagan muy bien :eyes:
En mi trabajo usamos las pruebas exportadas desde postman y las ejecutamos con newman en el proyecto. Me gusta más supertest, creo que sigue con la lógica de las unitarias y no se extrapola a una herramienta externa.