Leí la documentación oficial de jest sobre async/await , así como numerosas publicaciones de blog que tratan sobre el tema. Todos describen diferentes formas de await un valor en el que se realizan aserciones, así como esperar a que se complete la función de prueba. Ninguno de ellos incluía el siguiente patrón, sin embargo, no veo por qué debería causar problemas: supongamos que tengo un
const getValue: () => Promise<string>y que lo estoy probando con
test("await in expect", async () => { expect(await getValue()).toBe("b") })No puedo reproducir el problema con una implementación como
const getValue = () => new Promise((resolve) => { setTimeout(() => { resolve("b") }, 4000) }) sin embargo, estoy experimentando aproximadamente un 20 % de fallas en una prueba de integración en la que getValue ejecuta consultas en una base de datos real porque la función afterAll se llama antes y finaliza la conexión.
Soy consciente de que puedo superar esto con resolves y otros usos de await o done or else, por ejemplo
test("await in expect", async () => { await expect(getValue()).resolves.toBe("b") })y ya logré superar el problema en mi prueba de integración del mundo real con este enfoque.
Sin embargo, me gustaría ampliar mi comprensión de lo que está pasando y lo que estoy haciendo cuando uso await dentro de expect() .
Estoy usando Jest 27.
Hay una buena razón por la que uno debería crear reproductores reales para problemas y preguntas: el problema podría convertirse en algo completamente diferente.
En este caso, la promesa TypeORM Repository.save aparentemente regresa antes de que la instancia guardada se vacíe en la base de datos o en el caché o lo que sea que Repository.find .
Podría investigar más a fondo o simplemente dormir 100 ms después de guardar. Y sí, puede citar eso en otra publicación de blog sobre por qué los ORM son problemáticos.