Jest: global antes de todo

¿Has visto setupFiles ?

Como referencia, mi proyecto usa setupFiles así:

package.json

{
  "jest": {
    "setupFiles": [
      "./private/mocks/runtime.js"
    ]
  }
}

./private/mocks/runtime.js

global.__meteor_runtime_config__ = {ROOT_URL: 'localhost'};

FYI Stack Overflow podría ser un mejor lugar para este tipo de preguntas. (pregunta sobre el uso en lugar de un informe de error/solicitud de función).

También me he dado de baja de este problema, así que no recibiré ninguna notificación si respondes.

Estoy usando crear-reaccionar-aplicación.
y setupFiles se ejecutan nuevamente para cada archivo de prueba.

dando una respuesta que no es correcta y cerrando un problema después de eso. ¡Bravo!

@cpojer @ashtonsix No creo que esto deba cerrarse y la respuesta no es correcta, ambos setupFiles o setupTestFrameworkScriptFile se ejecutan para cada conjunto de pruebas, por lo que no hay un "global" beforeAll donde podemos establecer pensamientos como limpiar una base de datos de prueba antes de probar en

¿Puedes tener un pretest en package.json?

@ Negan1911 : tal vez, pero es difícil saber qué significa en el OP. ¿Podría considerar crear un segundo problema si cree que es una función útil y desea aportar más claridad a esta solicitud de función?

@cpojer @ashtonsix Si lo entiendo correctamente, actualmente no es posible tener una configuración y desmontaje global como se discutió aquí en Mocha .
El caso de uso que tengo (y probablemente el OP) es que quiero ejecutar un servidor y solo entonces todas mis pruebas de integración (y probablemente después de que todas se hayan ejecutado, elimine la base de datos de prueba).
¿Tiene algún consejo o mejores prácticas para hacer esto?
Lo que encontré es que la mayoría de las personas dicen que inicie un servidor y lo cierre para cada conjunto de pruebas en "local" antes de todo/después de todo, por ejemplo, aquí por @kentcdodds , pero implica mucha duplicación, ¿no?

+1 sobre tener una configuración global, en mi caso de uso, también quiero ejecutar un servidor proxy

@ashtonsix por lo que vale, el OP fue claro en mi opinión. Me gustaría que se reabriera este tema.

Puede crear un jest-environment personalizado, ver jest-environment-node o jest-environment-jsdom y subclasificarlo. Debería permitirle configurar el entorno de la forma que desee. Discutimos agregar un enlace asíncrono para esto también, y estoy feliz de aceptar relaciones públicas para ello.

+1 Quería probar broma proveniente de mocha y me impresionó la facilidad de jest-codemods y los documentos, hasta que me quedé atascado con este mismo problema.

Cada primer describe de cada archivo separado tardaba sorprendentemente en ejecutarse. Resulta que la configuración, como se explica en los comentarios anteriores, se ejecutó una vez por archivo, lo que resultó en toneladas de operaciones innecesarias que consumían mucho tiempo, como DROP DATABASE , CREATE DATABASE y más.

Desafortunadamente, no hay una solución alternativa en los documentos (que a su vez me trajeron aquí), excepto para ejecutar node setup.js && jest que no es lo ideal.

+1 para configuración global. Al igual que otros usuarios, me gustaría configurar y desmantelar la aplicación/base de datos solo una vez.

+1

Fijo en #4506

Existen las siguientes opciones de broma globalSetup y globalTeardown . https://facebook.github.io/jest/docs/en/configuration.html#globalsetup -cadena

Intenté usar globalSetup , sin embargo, sigo recibiendo el siguiente error. Creo que esta opción podría funcionar @shai32. Sin embargo, parece que no puedo hacerlo funcionar 🤣...

"jest": "^21.2.1"

 "jest": {
    "globalSetup": "./jest-config.js"
  }



md5-d3a1dcf99642fcf0b9c99c838aadb689



● Validation Warning:

  Unknown option "globalSetup" with value "./jest-setup.js" was found.
  This is probably a typing mistake. Fixing it will remove this message.

  Configuration Documentation:
  https://facebook.github.io/jest/docs/configuration.html

Aún no ha sido lanzado. Broma 22 entrante cualquier día ahora 🙂

Fijo en #4506

Sé que está vinculado allí, pero para cualquiera que busque: https://github.com/facebook/jest/pull/4716

@btav son 2 errores 😓

1. tiene que usar la ruta absoluta por ahora, o ("../../../~ root ~")
2. las advertencias de validación son falsos positivos

ver aquí
también #5093

los errores deben corregirse con # 5095 # 5096

¿Se puede usar esto para establecer una variable global? Lo intenté, pero no funciona... ¿es esto por diseño?

Mi caso de uso es que tengo una función de registro personalizada que quiero configurar globalmente. Probé _setup.test.js , pero mis variables globales no se transfieren.

@zwhitchcox usa la opción de configuración setupFiles: https://facebook.github.io/jest/docs/en/configuration.html#setupfiles -array

A veces puede ser útil compartir una variable global que se configura a través de una función asíncrona. Por ejemplo, sería útil configurar el navegador titiritero una vez en globalSetup y luego generar una nueva página en cada prueba/conjunto de pruebas.

@tdenovan Eso es exactamente lo que estoy tratando de hacer en este momento. Pero no parece funcionar. He hecho esto en moca antes y fue pan comido, pero en broma creo que necesito encontrar otras formas.
Esta es mi configuración de broma

"jest": {
    "verbose": true,
    "testEnvironment": "node",
    "globalSetup": "<rootDir>/scripts/testSetup.js",
    "globalTeardown": "<rootDir>/scripts/testTeardown.js"
  },

// globalSetup.js
module.exports = async () => {
  const browser = await puppeteer.launch({ headless: false });
  const page = await browser.newPage();
  bot = Bot(browser, page);
  await bot.goto(bot.baseUrl);
  global.bot = bot;
}

Pero no puedo acceder al bot en mis casos de prueba.

GGWP! Acabo de resolverlo.

"e2e": "jest --testRegex '.*.e2e.js'"

// globalTeardown.js
module.exports = async () => {
  if (process.testSetup) {
    process.testSetup.bot.close();
  }
}

 process.testSetup = { bot };
// and then im my tests
const { bot } = process.testSetup;

y cualquiera se pregunta qué es el bot,

const Bot = (browser, page) => ({
  browser: browser,
  page: page,
  baseUrl: 'http://localhost:4000',
  user: {
    name: faker.name.findName(),
    email: faker.internet.email(),
    password: 'Test<strong i="13">@123</strong>',
  },
  oldUser: {
    email: '[email protected]',
    password: 'Test<strong i="14">@123</strong>',
  },
  clearSession: async () => {
    await page.evaluate(() => sessionStorage.clear());
  },
  goto: async (url) => {
    await page.goto(url);
  },
  clickButton: async (id) => {
    await page.waitForSelector(id);
    await page.click(id);
  },
  checkText: async (expect, id, text) => {
    await page.waitForSelector(id);
    const elText = await page.$eval(id, el => el.innerHTML);
    expect(elText).toContain(text);
  },
  type: async (id, text) => {
    await page.waitForSelector(id);
    await page.$eval(id, el => el.value = '');
    await page.type(id, text);
  },
  wait: async () => {
    await page.waitForNavigation();
  },
  close: () => {
    browser.close();
  },
});

Hay una guía para titiriteros en el sitio web: https://facebook.github.io/jest/docs/en/puppeteer.html

Sí, pero eso sugiere que es posible configurar un global en el método asíncrono globalSetup, que según lo anterior no parece ser b

@SimenB ahh ... hombre ... Estaba tratando de resolver esto y también estuve en los documentos de broma durante bastante tiempo y nunca noté esa sección. Pérdida de mi tiempo.

Tengo un problema en el que los objetos globales que configuro en globalSetup no están disponibles si se ejecutan varios conjuntos de pruebas en paralelo (esto es de forma predeterminada). Al ejecutar una prueba de una sola suite, los objetos están disponibles o si configuro --runInBand para ejecutar pruebas en serie. ¿Cómo puedo obtener acceso a las variables que establecí en globalSetup si las pruebas se ejecutan en paralelo?
Probé el ejemplo usado anteriormente (usando el objeto de proceso) y también probé la versión en la que estoy usando un TestEnvironment personalizado pero sin suerte:

const PuppeteerJsdomEnvironment = require('jest-puppe-shots/lib/jsdom-environment');

class JestPuppeShotsEnv extends PuppeteerJsdomEnvironment {

  async setup(config) {
    await super.setup(config);
    const { allThemesCss } = global;

    // make the allThemesCss object available in test suites
    Object.assign(this.global, {
      allThemesCss
    });
  }
}

module.exports = JestPuppeShotsEnv;

Esto obtiene allThemesCss de globalSetup.js y se asegura de que se transmita a las suites de prueba.

@ovidiu-lapadus Pude hacer que globalSetup funcionara usando process en lugar de global. Funciona con y sin --runInBand . P.ej

// globalSetup.js
module.exports = async () => {
  process.FOOT = 'BALL';
};

// globalTeardown.js
module.exports = async () => {
  console.log(process.FOOT) // BALL 
};

// some.test.js
it('expects 1 to be 1', () => {
    expect(1).toBe(1);
     console.log(process.FOOT); // BALL
});

Y para el equipo de broma, no estoy seguro de por qué global no están definidos en las pruebas ( babel-jest 22.2.2 ), pero están definidos en globalTeardown.js . Tal vez sea un error. Por ahora solo usaré process . ¡Salud!

¡Gracias @cellis , me salvaste el día! Me he estado golpeando la cabeza contra la pared tratando de entender por qué global.FOO no funcionaba. process.FOO hace el truco :-)

@kalutheo Hay un par de advertencias sobre el uso de process.FOO. Primero, no creo que puedas hacer variables profundamente anidadas en process o process.env. Descubrí una manera aún mejor de hacer que los globales funcionen, pero estaba esperando para publicarlo. Lo que hice fue usar el paquete jest-environment para crear mi propio dbEnvironment . Allí, verifico que se definan bases de datos globales y, si no, las redefino. El entorno de la base de datos solo se ejecuta para pruebas de db, tengo otra configuración solo para pruebas de interfaz. De esa manera, no pierdo el tiempo ejecutando pruebas de base de datos para cada cambio de interfaz. En segundo lugar, tengo una forma de configurar múltiples bases de datos "réplica" que siempre están activas; no es necesario migrarlas o descargarlas en cada ejecución de broma, ya que las migro junto con la base de datos de desarrollo (puede ver destellos de esto en la esencia que he compartido), lo que permite que las pruebas se ejecuten aún más rápido. Configuré un grupo de estas réplicas para poder obtener el máximo paralelismo en las pruebas. Está algo documentado en la documentación de broma, pero no se explica lo suficientemente bien. De todos modos, aquí está la esencia: https://gist.github.com/cellis/08cc332dacf9a548005e8cf35d4b16e2

@ovidiu-lapadus Después de una inspección más cercana, creo que quizás su problema es que llamó a super.setup() antes de asignar sus globales. Consulte la esencia que publiqué anteriormente para obtener una solución funcional.

@cellis gracias por esta valiosa información. Lo intentaré con un entorno personalizado como el que describiste.

Chicos, ¿no se supone que globalSetup debe incluir aquí todas las tareas de elevación como babel-polyfill , combinar con chai , requerir jest-extended ?
Parece que globalSetup funciona de manera muy diferente a setupTestFrameworkScriptFile y lo que funcionó allí no funciona en globalSetup .
Sé que todos los casos de prueba de broma se ejecutan en su entorno de snadbox, pero no hacer las cosas en setupTestFrameworkScriptFile hace que la prueba se ejecute muy lentamente.

Moca: 9s
Broma: 60 s, en modo reloj: 170 s-200 s

?

Usar process es un truco que probablemente fallará (es un error).

Probablemente quieras seguir #7184

Esto no es un beforeAll() global como se preguntó en la pregunta, pero con esto, evita fácilmente la duplicación de código. Puede crear un entorno de nodo, que se configurará para todos sus archivos de prueba: https://stackoverflow.com/a/61260044/4934640

Actualizar

Acabo de descubrir que puedo configurar una variable de entorno en globalSetup , lo que significa que puedo compartir la dirección del servidor entre los casos/suites/archivos de prueba: https://github.com/facebook/jest/issues/7184# problemacomentario -612003555