Jest: console.log no se muestra cuando se ejecutan pruebas

Creado en 25 dic. 2016  ·  236Comentarios  ·  Fuente: facebook/jest

¿Quieres solicitar una función o informar de un error ?

Informar de un error .

¿Cuál es el comportamiento actual?

Llamar a console.log usando el entorno de prueba predeterminado de jsdom no se imprime en stdout.

Si el comportamiento actual es un error, proporcione los pasos para reproducir y una demostración de repl.it a través de https://repl.it/languages/jest o un repositorio mínimo en GitHub que podamos yarn install y yarn test .

  1. Clonar https://github.com/udbhav/jest-test
  2. Ejecutar yarn test
  3. Confirma que no ves nada de console.log
  4. Cambie la configuración de testEnvironment Jest a node
  5. Vuelva a ejecutar yarn test
  6. Confirme que está viendo la salida de console.log

¿Cuál es el comportamiento esperado?

Esperaría tener la salida de console.log siempre mientras se ejecutan mis pruebas.

Proporcione su configuración exacta de Jest y mencione su versión de Jest, nodo, yarn / npm y sistema operativo.

Consulte package.json y yarn.lock en el repositorio para ver las versiones del paquete. Estoy ejecutando el nodo 7.3.0 y el hilo 0.18.1

Comentario más útil

Estoy usando el nodo v4.4.7, y en lo que a mí respecta, no mostrar nada en la salida estándar cuando uso console.log es un problema. No estoy tratando de obtener ayuda con la codificación, estoy informando lo que parece ser un error para mí. La única otra cosa que ha cambiado es que tenía varios archivos de prueba ejecutándose antes, y ahora solo uno. déjeme ver si volver a habilitar las otras pruebas hace que las salidas console.log aparezcan nuevamente.

Todos 236 comentarios

Solo probé esto usando repl.it: https://repl.it/EwfT/0

La buena noticia es que funciona como se esperaba y sale de console.log. Intenté degradar mi versión de broma a 17.0.3, seguía viendo los mismos problemas. Se instaló nvm para probar con el nodo v6.9.2, y hurra console.log funciona con jsdom, así que supongo que el problema está relacionado con el nodo v7.

Gracias por informar de esto, pero es un duplicado de # 2166 y también ocurre en el Nodo 6.

@thymikee ¿Cómo es esto un duplicado de # 2166? En este escenario, console.log no genera nada en absoluto. Tengo este problema con Node v4. Lo frustrante es que hoy estaba funcionando bien, y con 0 cambios en mi entorno, no recibo más salidas console.log en mi terminal.

@thisissami , parece que su prueba o código no se está ejecutando en ese momento. El conjunto de pruebas de Jest pasa el nodo 4 y el nodo 6, lo que garantiza que la impresión de la consola funcione bien y estamos trabajando en una solución para 7.3.

@cpojer - Mis pruebas pasan / fallan correctamente - solo los mensajes console.log no aparecen. Descubrí esto cuando trataba de averiguar cuáles son las propiedades de un objeto en particular al console.log ingiriéndolo y sin ver ningún resultado. Agregué muchas declaraciones console.log y ninguna aparece en mi terminal ahora. = / Actualmente estoy volviendo a Jest v17 para ver si eso cambia algo.

Si hoy funcionaba para usted y ya no lo está, debe haber realizado una actualización o haber roto algo usted mismo. No publicamos un lanzamiento de Jest en dos semanas.

bien, lo único que ha cambiado en mi código de prueba es que he agregado un comentario de varias líneas después del código que se supone que debe ejecutarse (como referencia para mí). Veré si eliminar eso hace la diferencia.

@cpojer No sé qué decir, no veo nada malo en mi código de prueba, pero no se envía nada a la salida estándar:

import React from 'react';
import {shallow} from 'enzyme';
import FundPercentage from '../../src/reactClasses/fund_percentage';

console.log('cmon');
describe('Normal Percentage', () => {
  console.log('do this');
  const percentage1 = shallow(
    <FundPercentage percentage={0.5}/>
  );
  const percentage2 = shallow(
    <FundPercentage percentage={0.26}/>
  );
  it('should work', () => {
    console.log(percentage1.childAt(0));
    expect(0).toBe(1);
  });
});

La prueba falla, como se esperaba, así que sé que está funcionando. Mi configuración en package.json es realmente simple, únicamente:

  "jest": {
    "collectCoverageFrom": [
      "src/*.jsx"
    ]
  }

Jest funcionó con total normalidad, sin banderas adicionales adjuntas. El mismo problema con Jest v17 y 18.

No he cambiado ningún otro archivo que no sea este en toda la tarde. Acabo de entender cómo funciona enzyme al enviar varias cosas a stdout , y después de comenzar a agregar algunos expects , el console.logs detuvo trabajando cuando los necesitaba de nuevo, y ahora no funcionan en absoluto, no importa lo que tenga en la prueba. Tampoco he cambiado nada en mi entorno (más allá de degradar ahora a v17), lo cual es ciertamente confuso.

Parece que actualizó al nodo 7.3. Tenemos algunas soluciones para eso. Tenga en cuenta que este rastreador de problemas no es un foro de ayuda; use stackoverflow para preguntas :)

Estoy usando el nodo v4.4.7, y en lo que a mí respecta, no mostrar nada en la salida estándar cuando uso console.log es un problema. No estoy tratando de obtener ayuda con la codificación, estoy informando lo que parece ser un error para mí. La única otra cosa que ha cambiado es que tenía varios archivos de prueba ejecutándose antes, y ahora solo uno. déjeme ver si volver a habilitar las otras pruebas hace que las salidas console.log aparezcan nuevamente.

@cpojer Estoy bastante seguro de que tienen un error aquí.

Tener 3 pruebas ejecutadas (como en 3 archivos diferentes con .test.js , con 2 de esos archivos como ejemplos de sus tutoriales) funciona sin problemas. Mi prueba (copiada arriba) muestra todos los registros de la consola.

Tener solo 1 prueba de ejecución (también conocido como cambio .test.js nombre de .teast.js en 2 de los archivos) da como resultado que no se procesen las salidas de console.log.

Seguiré ejecutando una segunda prueba arbitraria para ver el resultado que necesito, por lo que soy bueno para mis propias necesidades personales, pero esto debería abordarse en mi opinión, suponiendo que sea reproducible en otro lugar.

El conjunto de pruebas de Jest prueba este comportamiento en el nodo 4, el nodo 6 y el nodo 7.3. Funciona para 4 y 6 pero se rompió en 7.3. Estoy arreglando esto para el nodo 7.3 y publicaré una nueva versión de Jest en breve: https://github.com/facebook/jest/pull/2464

Si el propio conjunto de pruebas de Jest que usa el nodo 4 falla, es probable que algo esté mal con su configuración.

Clona el repositorio y pruébalo ahora.

Todo pasó excepto estas 3 pruebas. No estoy seguro de qué implicaciones podría tener. Tienes toda la información de los errores relacionados con console.log que tengo, así como la imagen a continuación. Si eso no es un error en broma, que así sea. Sin embargo, me parece extraño que no hacer nada más que seguir las guías resulte en un escenario en el que no puedo ver mis registros cuando solo ejecuto un archivo de prueba.

screen shot 2016-12-28 at 5 55 29 pm

Estos solo indican que no tienes Mercurial (hg) instalado, sin relación con tu problema. Parece que el conjunto de pruebas pasa por ti y como se dijo; probamos explícitamente el comportamiento del registro en el conjunto de pruebas, por lo que debe haber algo que no funcione correctamente con su código o configuración.

Está bien, gracias por tus comentarios. ¿Tiene alguna idea de lo que podría estar causando que funcione cuando hay varios archivos, pero no cuando solo hay 1? Si no le viene a la mente un "oh, esto a veces causa un problema como ese" obvio, no se preocupe, solo me aseguraré de que siempre haya al menos 2 archivos en ejecución. :)

Estoy experimentando el mismo problema, console.log no se está generando para mí ahora (y anteriormente fue hace aproximadamente una hora). Estoy usando el nodo 6.9.1 y también habilitando la bandera --forceSalir. Cuando no tengo esta bandera habilitada, aparece la salida de console.log.

Sin embargo, tengo otra secuencia de comandos de prueba que utiliza el indicador --forceSalir y aparece console.log, por lo que no puedo decir que el indicador --forceSalir esté causando este comportamiento.

Como lo está haciendo

Tenía el mismo problema, pero descubrí que se debía a la ejecución de jest a través de jest-cli (jest.runCLI) dentro de gulpfile.js y se estaba tragando la salida de console.log. Si ejecuto Jest directamente, veo la salida de la consola.

Ahora estoy viendo un comportamiento extraño, que todavía no puedo aislar en un caso de prueba simple, de lo contrario, presentaría un nuevo problema.

1) Jest realiza una prueba
2) Jest genera las declaraciones de console.log (no parpadees aquí)
3) Jest retrocede hasta un número arbitrario de líneas, que a veces cubre todas las líneas de console.log, a veces algunas y a veces todas.
4) Jest ejecuta la siguiente prueba (las líneas de console.log de la prueba anterior desaparecen).

broma v18.1.0

Como no puedo aislar esto en una prueba simple, supongo que tiene algo que ver con ejecutar una prueba asincrónica más compleja.

Tengo el mismo problema, me pregunto si su salida está sobrescribiendo otra salida. De vez en cuando veo algo como esto:

image

Es como si un proceso arrojara un error (tipos de props fallidos) pero los registros de salida de prueba simplemente lo escriben.

Más:

image

Y, a veces, si Ctrl + c mientras se ejecutan las pruebas, veré registros de la consola que no vería si dejo que finalicen las pruebas.

Versiones
Broma: 17.0.1
Nodo: 6.6.0
NPM: 3.10.3
macOS: 10.12.2
Terminal: 2.7.1 (y también en iTerm2 3.0.13)
Script (en package.json ): jest /src/main/js --watch o jest /src/main/js --coverage o jest --watch --onlyChanged todos tienen el mismo comportamiento.

@davidgilbertson ¿sucede en v18.1?

Probé 18.1.0 y parece aún más defectuoso. Y todavía veo cosas como esta:

image

No puedo elegir ningún patrón en particular, pero han sucedido algunas cosas (tengo un console.warn('----------------') en uno de mis componentes).

  • Si me desplazo un poco hacia arriba desde la parte inferior cuando ejecuto las pruebas, veo el registro. Si me desplazo hacia abajo por la ventana de la terminal mientras las pruebas se están ejecutando (para que comience a desplazarse automáticamente), cuando la prueba finaliza, me desplazo hacia arriba y la línea console.warn desaparece (presumiblemente se sobrescribe).
  • Si ejecuto las pruebas y de inmediato presiono ctrl + c , veo algunos registros de la consola. Pero si hago lo mismo y no interrumpo, esos registros de la consola no son visibles.
  • Cuando ejecuto jest /src/main/js --watch una vez, luego presiono a para ejecutar de nuevo, recoge una gran cantidad de pruebas heredadas en un directorio src/main/assets/legacy , que no coincide con el glob.
  • Igual que el anterior si solo ejecuto jest --watch (todas mis pruebas terminan en .test.js o .test.jsx ). Entonces, presionar 'a' en el modo de reloj parece ir a buscar en todas partes, incluida una vieja prueba de jazmín llamada src/test/js/spec/categoryselector/spec.js . Pulsar Enter parece hacer lo que espero.

¿Podría ser que todos los errores generados por los accesorios faltantes causen este problema? Tengo que mantener ctrl+c en la salida para intentar detectar estos errores antes de que se sobrescriban.

Tampoco me funciona (broma 19.0.1, nodo 5.12). Curiosamente, funciona en otro proyecto con la misma configuración. No estoy seguro de cómo depurar las pruebas de Jest, por lo que creo que poder ver algunos mensajes de la consola sería bastante importante.

¿Ha intentado usar la bandera de broma --runInBand para ver si eso lo resuelve ejecutando pruebas en serie? Alguien me mencionó esto, pero no tuve la oportunidad de probarlo.

La bandera bail evita que se impriman los registros de la consola.

Intentaré. Lo un poco desconcertante es que en el mismo proyecto algunas declaraciones de registro de la consola se generan en la consola, otras no. Desafortunadamente, los que intenté agregar donde falla un caso de prueba no obtienen salida (intenté agregar en todas partes en el caso de prueba, en la unidad probada, etc. sin éxito). Entonces, en realidad, no creo que esto pueda deberse a una bandera, ya que el comportamiento no es conciso. Es un proyecto nativo de reacción, siguiendo el diseño estándar por cierto.

Nada de esto parece ayudar. La bandera --bail simplemente evita que se ejecuten otras pruebas (la ofensiva es la última de todos modos en mi caso), y --runInBands no parece tener ninguna diferencia observable. Jest ejecuta los archivos actualizados por cierto, por lo que si inserto una declaración console.log, el seguimiento de la pila de errores muestra que el error proviene del número de línea actualizado. Es solo que el registro de la consola no ocurre. Dado que es difícil / imposible depurar estas pruebas en un navegador (por favor corríjame si este no es el caso), console.log es absolutamente vital para solucionar algunos problemas en las pruebas.

Parece que este caso de prueba no se estaba ejecutando en realidad. Hubo un TypeError (acceder a una propiedad en un indefinido). Lo que me engañó es que en realidad vi el seguimiento de la pila en la consola, lo que sugiere que se está ejecutando. Entonces, ver el rastro pero no ver el mensaje de registro no cuadró del todo :) ¿Alguien sabe por qué se hace de esta manera, entonces, si una prueba falla con un error de tiempo de ejecución, los registros no se generan como parece? (Para que quede claro, me refiero a los registros que han ocurrido hasta el punto del error, obviamente no me refiero a los registros después del error :))

En mi entorno, tenía verbose: true establecido en las opciones de broma en package.json . Cambiar esto a falso (o eliminarlo) solucionó el problema para mí. Todos los registros de mi consola se muestran ahora.

Esto está en 18.1.

Para cualquier otra persona que tenga este problema, verifique las dependencias agregadas recientemente. Comencé a tener problemas después de agregar mock-browser en un intento de simular los objetos del navegador. Aparentemente, reemplaza global con su propio objeto.

package.json (configuración de broma)

"jest": {
    "testEnvironment": "node",
    "moduleFileExtensions": [
        "js",
        "json"
    ],
    "moduleDirectories": [
        "node_modules",
        "src"
    ],
    "transform": {
        "^.+\\.js$": "babel-jest"
    },
    "roots": [
        "<rootDir>/__test__"
    ],
    "setupFiles": [
        "<rootDir>/__test__/test-setup.js"
    ],
    "moduleNameMapper": {
        "client": "<rootDir>/src/client",
        "common": "<rootDir>/src/common",
        "server": "<rootDir>/src/server",
        "!CONFIG": "<rootDir>/config/env/test.js",
        "\\.(jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$": "<rootDir>/__mocks__/file.js",
        "\\.(css|less)$": "identity-obj-proxy"
    }
}

test-setup.js

const mockBrowser = require('mock-browser').mocks.MockBrowser;

const MockBrowser = new mockBrowser();
global.APP_CONFIG = require('!CONFIG').default;

global.__DEVELOPMENT__ = false;
global.__TESTING__ = true;
global.__PRODUCTION__ = false;
global.document = MockBrowser.createDocument();
global.window = MockBrowser.createWindow();
global.localStorage = MockBrowser.getLocalStorage();

test-setup.js
Comentando los mock-browser bits ...

// const mockBrowser = require('mock-browser').mocks.MockBrowser;

// const MockBrowser = new mockBrowser();
global.APP_CONFIG = require('!CONFIG').default;

global.__DEVELOPMENT__ = false;
global.__TESTING__ = true;
global.__PRODUCTION__ = false;
// global.document = MockBrowser.createDocument();
// global.window = MockBrowser.createWindow();
// global.localStorage = MockBrowser.getLocalStorage();

console.log funciona bien.

¿Por qué está cerrado este problema? Claramente no es un duplicado de # 2166

Agregaré mis $ 0.02 porque acabo de encontrarme con esto.

Asunto:

  • Estoy ejecutando jest --watch --verbose (v19.0.2)
  • Algunas (¡pero no todas!) console.log declaraciones no aparecen, ni durante la ejecución de la prueba ni en el resumen.
  • En mi caso, puedo aislar a un _.reduce llamada: todos los console.log sentencias dentro de este bloque no se console.log se muestran las intervenciones fuera del bloque de reducir. He verificado por otros medios (cobertura, resultados de la prueba) que, de hecho, se está llamando al cuerpo reductor. Esto es extraño ya que no estoy haciendo nada asíncrono / promesa basado en esta parte del código, no puedo entender por qué la llamada de reducción afectaría algo.
  • Si invoco broma con --runInBand , veo todas las declaraciones console.log .
  • A diferencia de la mayoría de los informes anteriores, estoy ejecutando "testEnvironment": "node" , no jsdom

Los siguientes comentarios parecen estar relacionados con mi problema:

https://github.com/facebook/jest/issues/2441#issuecomment -273643521
https://github.com/facebook/jest/issues/2441#issuecomment -278202180

Es bastante rápido, pero parece como los console.logs en realidad están siendo atraídos por la pantalla y luego sobreescriben.

Acabo de confirmar con un video que el console.log de hecho se está dibujando en la pantalla durante ~ 0.2s antes de ser dibujado.

Ejecutar --watch sin --verbose parece solucionar este problema.

Pasé 10 minutos tratando de obtener un caso de reproducción aislado, pero parece que no puedo hacerlo. Probablemente solo se manifieste con suites de prueba grandes (bueno,> 1).

Puedes ver el comportamiento aquí:

  • Antes de console.log
    screen shot 2017-03-29 at 3 38 51 pm

  • console.log: se muestra durante una fracción de segundo (<0.2s)
    screen shot 2017-03-29 at 3 39 34 pm

  • Después de pintar sobre console.log
    screen shot 2017-03-29 at 3 39 47 pm

Este problema realmente apesta, desperdicia mucho tiempo en este tema y nada parece funcionar. Escogí broma porque pensé que los ingenieros de Facebook tenían un conjunto de pruebas decente y ahora esto ...

Por eso no me gusta Jest. No importa lo que hagas, borrarán tu consola y se negarán a mostrar las declaraciones de la consola, y luego, de alguna manera, aparecerán al azar, hasta que tengas un error que necesites corregir, en cuyo caso harán todo lo posible para ocultar cada declaración de registro para que no pueda solucionarlo.

¿Por qué no DEJAN de intentar ocultar la salida de la consola a los desarrolladores? ¡Si quiero ruedas de entrenamiento, usaré Angular 1!

Eso es bastante agresivo @halis. Estamos haciendo esto porque Jest paraleliza las pruebas y muchas pruebas pueden registrarse en la terminal al mismo tiempo, lo que significa que la salida de Jest se vuelve inútil. De hecho, solíamos hacer eso. Si está usando --verbose , en realidad no almacenamos nada y escribimos directamente en la consola.

Si eso no funciona para usted, tal vez pueda ayudarnos enviando un PR a Jest y mejorando este comportamiento.

Lo siento, estaba teniendo un mal día el viernes y estaba frustrado. No hay razón para desquitarse contigo, solo estás tratando de ayudar.

Encontré la bandera --verbose el viernes, que me dio suficiente salida para solucionar mis problemas.

Una vez más, lo siento por ser tan idiota al respecto.

Genial. No dejes que las herramientas de JavaScript arruinen tus viernes 😀

¿Alguna noticia sobre esto? ¿Cómo mostrar console.log?

comportamiento muy interesante, después de golpearme la cabeza un par de veces (más bien varias veces) descubrí que --verbose es de hecho el culpable de que no se imprima console.log.
Mi mejor solución fue crear otro script en package.json que no tenga un indicador detallado cuando quiero que se imprima algún mensaje en mi consola. Realmente agradecería si arreglaran esto pronto

Este problema es bastante molesto, ya que dificulta / imposibilita la depuración de pruebas con console.log (lo sé ... de la vieja escuela, pero aún así es conveniente).
Para mí, usar las opciones --runInBand hizo que aparecieran mis declaraciones de registro.

EDITAR: Estoy bastante seguro de que está relacionado con la forma en que se muestran los resultados en la pantalla ... una opción sería tener un reportero 'ficticio' que simplemente no intente una representación elegante. Otra opción sería dejar que el desarrollador elija un reportero como lo hace mocha.

Es peor que no mostrar registros:

Si tengo algún tipo de error en una prueba asíncrona, no solo no veo los mensajes de registro, sino que los errores expect también están ocultos y se tragan las excepciones.

test('async', (done) => { setTimeout((() => { expect(1).toEqual(2); throw new Error(); done(); }), 1000); });

En ninguna parte se muestra mi prueba expect .

`` ``
Tiempo de espera: no se invocó la devolución de llamada asíncrona dentro del tiempo de espera especificado por jasmine.DEFAULT_TIMEOUT_INTERVAL.

  at Timeout.callback [as _onTimeout] (../../../../../../../../usr/local/lib/node_modules/jest/node_modules/jsdom/lib/jsdom/browser/Window.js:523:19)
  at ontimeout (timers.js:386:14)
  at tryOnTimeout (timers.js:250:5)
  at Timer.listOnTimeout (timers.js:214:5)

`` ``

Ni runInBand ni verbose:false ayudan.

Tengo una configuración trivialmente simple ( babel-jest ).

@richburdon para pruebas asíncronas usando done callback necesita cubrir el caso fallido con done.fail()

@thymikee gracias por la rápida respuesta. Aunque no sé a qué te refieres. ¿Puedes modificar mi prueba y / o apuntarme a docs. Muchas gracias.

test('async', (done) => { setTimeout((() => { expect(1).toEqual(2); throw new Error(); done(); }), 1000); });

test('async', (done) => {
  setTimeout((() => {
    expect(1).toEqual(2);
    try {
      throw new Error();
    } catch (error) {
      done.fail(error);
    }
    done();
  }), 1000);
});

Entiendo que esto no es ideal, pero así es como funciona actualmente. Vale la pena señalar que no es un problema cuando la función probada devuelve una Promesa . Hay un par de problemas afectados por este comportamiento, como https://github.com/facebook/jest/issues/2136 o https://github.com/facebook/jest/issues/2059. Si tiene una idea sobre cómo mejorarlo, nos encantaría revisar un PR y hacerlo realidad.

Pero este no es un tema relevante para discutirlo, puede publicar sus ideas en otro lugar.

@thymikee , mi ejemplo no fue bueno ya que setTimeout tiene problemas relacionados con promesas que no tienen nada que ver con bromas ...

Vale la pena señalar que no es un problema cuando la función probada devuelve una Promesa.

No veo eso:

`` ``
test ('async', (hecho) => {
function foo () {
return Promise.resolve (1);
}

foo (). luego (valor => {
esperar (valor) .toEqual (2); // Nunca reportado; solo se agota el tiempo.
hecho();
});
});
`` ``

No es obvio que el código de prueba deba detectar excepciones para las llamadas expect (es decir, parte del marco de prueba en sí). ¿Esto parece bastante complicado?

Entonces, para ser claro, debería envolver TODAS las pruebas que involucren cualquier función probada que devuelva promesas con un bloque de captura - para atrapar llamadas expect , que de lo contrario: a) tiempo de espera; b) no reportar el error.

A menos que esté cometiendo un error diferente:

a). ¿Quizás documentar esto (https://facebook.github.io/jest/docs/asynchronous.html#content)?

B). ¿Por qué no registrar el error? y / o tienes la opción de salir?

Tengo el mismo problema con console.log.
Funcionaba bien en v19 y pude ver el resultado en la consola.
Después de actualizar a v20.0.3, la salida desaparece.
Intenté agregar --runInBand o --verbose , pero no ayudó.

Actualice a la última versión de nodejs, por favor. Es un problema conocido en el nodo ~ 7.3.

@thymikee Entonces, ¿van a solucionar este problema? He probado de todo bajo el sol. Todavía no hay registros de la consola. Estoy usando el preprocesador proporcionado por jest y mecanografiado. Estaba usando ts-jest y su preprocesador funcionó. ¿Es posible que tenga algo que ver con el preprocesador?

@cpojer @lsentkiewicz ¿Deberíamos abrir una nueva edición ya que es una nueva edición en una nueva versión?

Como mencionó @cpojer , el uso de la última versión de node soluciona el problema.

@marcusjwhelan
Funciona para mí en v7.10.0

Sigo viendo que la salida de la consola se traga cuando uso jest --bail .

@cpojer No funciona en v8.0.0

No funciona en el nodo 8.0.0

Siento que este es un error grave si tienes que estar en una versión determinada para que funcione. ¿Qué sucede si su sistema se ejecuta en 6.0 y no funciona en 7.0 debido a algunos cambios de nodejs? ¿No debería funcionar broma en al menos versiones modernas de Node? al menos 5 años de soporte? @cpojer @taion

Este es un error solo en el nodo 7.3. Fusionaron un mal cambio y lo revertieron por 7.4 o 7.5.

La gente me dice que no funciona en el nodo 8, pero tenemos una prueba para este comportamiento y está pasando. Si a la gente le gustaría crear una reproducción adecuada con Jest 20 y el nodo 8, cree un problema para eso.

@cpojer No

$ node --version
v7.4.0

Archivos

package.json :

{
  "dependencies": {
    "@types/jest": "19.2.4",
    "jest": "20.0.4",
    "ts-jest": "20.0.6",
    "typescript": "2.3.4"
  }
}

__tests__/jestconfig.json :

{
  "rootDir": "../",
  "globals": {
    "__TS_CONFIG__": {}

  },
  "moduleFileExtensions": [
    "ts",
    "tsx",
    "js",
    "jsx",
    "json"
  ],
  "transform": {
    "\\.(ts|tsx)$": "<rootDir>/node_modules/ts-jest/preprocessor.js"
  },
  "testRegex": "__tests__/.*test_.*\\.(ts|tsx|js)$"

__tests__/test_foo.ts :

import {} from 'jest';

console.log('CONSOLE before test');
test('fail', () => {
  console.log('CONSOLE inside test');
  expect(true).toEqual(false);
  console.log('CONSOLE end of test');
})

__tests__/test_bar.js :

console.log('BAR CONSOLE before test');
test('fail', () => {
  console.log('BAR CONSOLE inside test');
  expect(true).toEqual(false);
  console.log('BAR CONSOLE end of test');
})

Producción

$ jest -c __tests__/jestconfig.json 
 FAIL  __tests__/test_foo.ts
  ● fail

    expect(received).toEqual(expected)

    Expected value to equal:
      false
    Received:
      true

      at Object.<anonymous> (__tests__/test_foo.ts:6:16)
      at Promise.resolve.then.el (node_modules/p-map/index.js:42:16)

 FAIL  __tests__/test_bar.js
  ● fail

    expect(received).toEqual(expected)

    Expected value to equal:
      false
    Received:
      true

      at Object.<anonymous>.test (__tests__/test_bar.js:4:16)
      at Promise.resolve.then.el (node_modules/p-map/index.js:42:16)

Test Suites: 2 failed, 2 total
Tests:       2 failed, 2 total
Snapshots:   0 total
Time:        1.379s
Ran all test suites.

Prueba JS única:

$ jest -c __tests__/jestconfig.json __tests__/test_bar.js 
 FAIL  __tests__/test_bar.js
  ● fail

    expect(received).toEqual(expected)

    Expected value to equal:
      false
    Received:
      true

      at Object.<anonymous>.test (__tests__/test_bar.js:4:16)
      at Promise.resolve.then.el (node_modules/p-map/index.js:42:16)

  ✕ fail (7ms)

Test Suites: 1 failed, 1 total
Tests:       1 failed, 1 total
Snapshots:   0 total
Time:        0.596s, estimated 1s
Ran all test suites matching "__tests__/test_bar.js".

Prueba de TS única:

$ jest -c __tests__/jestconfig.json __tests__/test_foo.ts 
 FAIL  __tests__/test_foo.ts
  ● fail

    expect(received).toEqual(expected)

    Expected value to equal:
      false
    Received:
      true

      at Object.<anonymous> (__tests__/test_foo.ts:6:16)
      at Promise.resolve.then.el (node_modules/p-map/index.js:42:16)

  ✕ fail (116ms)

Test Suites: 1 failed, 1 total
Tests:       1 failed, 1 total
Snapshots:   0 total
Time:        1.27s
Ran all test suites matching "__tests__/test_foo.ts".

Tener este mismo problema con el nodo v8.1.2. También probé el nodo v7.10.0 y tampoco funcionó

Trabajando en un proyecto de React probé Jest porque con Jasmine es una búsqueda total para probar llamadas HTTP con whatwg-fetch , ejecución de Node.js y transpilación de Babel. Pero cuando vi que en este momento con Jest no se puede imprimir en la consola, fue un no-no usar este marco. Tener el problema con Node.js 7.10 y Jest 20.0.4.

Finalmente pude configurar todo el entorno de prueba con la ejecución de Jasmine y Node.js declarando xmlhttprequest en el alcance global y usando nock como servidor falso.

Los errores pueden ser muy difíciles de detectar y corregir. Pero este es un P0 informado hace 6 meses que evitará que cualquiera considere a Jest en serio como el marco de prueba para cualquier proyecto de React.

Estaba teniendo el mismo problema que en las capturas de pantalla de @davidgilbertson (los resultados de la prueba sobrescriben el archivo console.log) en Jest 19.0.2 y Node 7.10.0 al ejecutar jest --verbose . Lo que me ayudó: cuando usé jest --verbose --runInBand funcionó correctamente (primer resultado de prueba, luego todo console.log).

@cpojer @thymikee , ¿ llame la atención?

@iffy , ¿puedes crear un problema por separado con tu reproducción? Intentaré clasificarlo y ver qué pasa.
Por cierto, no se llamará a nada por debajo de la expectativa fallida, porque espera arroja.

@thymikee hecho (aunque ya me

También tuve este problema, e incluso después de leer todo este hilo y probar todo, no puedo solucionar el problema. Mi prueba es muy simple, porque acabo de implementar jest en mi aplicación, y aun así console.log no aparece.

Luego intenté usar winston para iniciar sesión en un archivo de salida y funcionó. Luego intenté usar winston para iniciar sesión en la consola y, adivina qué, ¡funcionó!

Así que les sugiero que hagan lo mismo. Verifique mi archivo logger.js :

'use strict';

const winston = require('winston');

const customColors = {
  trace: 'white',
  debug: 'blue',
  info: 'green',
  warn: 'yellow',
  crit: 'red',
  error: 'red'
};

let config = {
  colors: customColors,

  levels: {
    trace: 0,
    debug: 1,
    info: 2,
    warn: 3,
    crit: 4,
    error: 5
  },
  transports: [
  ]
};

config.transports.push(
  new(winston.transports.Console)({
    name: 'consoleLogger',
    level: 'error',
    colorize: true,
    timestamp: true
  })
);

const logger = new (winston.Logger)(config);
winston.addColors(customColors);

module.exports = logger;

En los archivos de prueba solo use:

let log = require('./logger.js');
log.debug('some log here!');

Winston funciona porque usa process.stdout.write que soluciona este error en Jest. Terminé haciendo mi propio console.log usando el módulo util del nodo.

@eranimo @Daymannovaes mira el error # 3853

Ese comentario dice que funciona en 8.1.2 pero lo intenté y no lo conseguí. Ya me cambié a moca porque era un error bastante malo.

¿Se solucionará este error en la próxima versión? Además, ¿dónde encuentro cuándo es eso?

No puedo actualizar a la última versión del nodo (no es una opción), así que esa no es una solución. Podría hacer mi propia utilidad de registrador con la que puedo jugar. Estoy considerando convertirme a moca, pero depende de cómo vaya mi experimento de registrador.

Solucione lo antes posible, los registros de la consola son extremadamente útiles para escribir mis pruebas.

He bajado temporalmente a 19.0.2 y eso está funcionando.

Tuve el mismo problema y lo probé con la última versión de node. Ahora funciona. : 100:

También me funciona después de pasar de Node.js v7.10 a v8.1.

arreglado para mí al actualizar el nodo de 7.4.0 -> 8.2.1

Obteniendo esto en el nodo v8.4.0 y Jest 21.0.0-beta.1.

Cuando se ejecuta solo un caso de prueba con test.only , la salida de console.log no aparece.

Pero si elimino --testPathPattern file y ejecuto todas las pruebas, aparece el resultado.

Además, si agrego await Promise.delay(100) como último paso en la prueba, aparece el resultado.

perdón por este comentario, pero es su forma de hacer que Jest llegue a console.log en tiempo real en lugar de después de que una prueba haya pasado o fallado. mi prueba usa un bucle while Estaba tratando de obtener valores registrados mientras el bucle se está ejecutando?

@nharrisanalyst usa --verbose bandera

gracias por la respuesta, pero uso esta bandera y solo console.log () después de que una prueba haya pasado o fallado. así que si mi bucle while se atasca, no puedo depurarlo con console.log al realizar la prueba porque la prueba no pasa ni falla, simplemente se atasca en un bucle.

Jest parece comerse cualquier consola que hago en un setupFiles , setupTestFrameworkScriptFile o beforeAll , lo que hace imposible escribir scripts de configuración de prueba que soliciten la entrada del usuario y validar el comando banderas de línea. Sucede con o sin "verbose": true

Compartiendo mis observaciones en console.log () no aparece cuando se ejecutan pruebas con Jest.

El requisito previo para esto es ejecutar Jest con la bandera --verbose .

Si está ejecutando pruebas con varios archivos de prueba , la salida de console.log () no es visible (la mayor parte del tiempo).
Si Jest está ejecutando pruebas desde un solo archivo de prueba , console.log () funciona como se esperaba.

Puede solucionar este problema de la siguiente manera:

  • Ejecute pruebas de Jest desde solo 1 archivo. Sí ... no es realista en absoluto, así que mira la siguiente opción.
  • Utilice la bandera --maxWorkers=1 . De alguna manera, esto funciona muy bien para mí. Mi conjetura (*) es ... Jest se ejecuta en el mismo proceso y no hay necesidad de almacenar en búfer la salida estándar de cada proceso para devolverlos al proceso principal.

Si mi suposición (*) es un comportamiento esperado, sugiero actualizar los documentos para indicarlo claramente para evitar que los desarrolladores pierdan el tiempo tratando de averiguar "por qué mi console.log () no se muestra ... a veces".

De acuerdo, esto sigue siendo un problema para algunas personas, incluyéndome a mí hoy. Imagino que seguirá siendo una cosa.

De mis pruebas, Jest sale del proceso antes de generar registros, lo que significa que parece que los registros se están tragando.

Para mí, configuré verbose: true y bail: false en mi configuración de broma. Jest continuará hasta que se ejecuten todas las pruebas y generará todos los errores y registros. Esto es favorable. También ejecuté --runInBand , que hace lo mismo que configurar --maxWorkers=1 .

La mayor ayuda fue bail: false porque eso permitió que todas las pruebas se ejecutaran hasta que terminaran. Todavía salió con el código 1 pero puedo ver todos los registros nuevamente.

Ejecutando Jest v19.0.2 con el nodo v8.1.4.

La ejecución de --verbose --testPathPattern=<path/to/file> llevó a que se imprimieran los registros. De lo contrario, se lo traga.

¿Alguien puede proporcionar una pequeña reproducción que falle en jest 21.2.0 y los nodos actuales (entonces 4.8.4, 6.11.4 u 8.7.0)?

No es necesario configurar verbose o configuraciones de broma adicionales y el problema simplemente desaparece cuando actualizo la versión de mi nodo de 7.4.0 a 8.0.0 . Esas son mis observaciones.

Usando [email protected]

¡Esto es TAN frustrante! Tengo las últimas versiones de todo y aún Jest corta la salida de console.log en lugares aparentemente aleatorios. Esto hace que sea muy difícil depurar pruebas fallidas.

¡Acabo de encontrar la respuesta a esto! Si desactiva el modo detallado, aparecerán todos los resultados de console.log. Creo que cuando los resultados de Jest son detallados, lo escribe en la parte superior de los resultados de los últimos registros de console.logs.

¿Tiene algún fragmento de código que reproduzca esto de manera consistente? Podría ayudarnos a eliminar la inconsistencia subyacente que causa el problema.

Usé expect(<value>).toEqual("someImpossibleValue") con bail: false para solucionar esto cuando solo intentaba arreglar algo roto. Definitivamente no es ideal, pero rápido y sucio ...

Tal vez podría introducir una función de asumir () que sea similar a esperar (), pero no se resbale.

ejecutando v 22.0.4 sin console.log .... agregue esto a una de las muchas otras razones por las que no recomiendo broma

@mvolkmann gracias por la pista sobre el modo detallado. Si el modo no detallado es el predeterminado en broma, podría valer la pena considerar un cambio. No me parece intuitivo que console.logs que colocas en tu código simplemente no aparece. Es lo primero y básico que uno intenta cuando falla una prueba.

(nodo v9.3.0 y jest v20.0.4 aquí)

jest ^21.2.1 y node 8.9.4

Jest todavía no arroja registros de consola a veces, la opción --verbose no me resuelve el problema. No entiendo por qué este problema está cerrado.

@fega, ya que nadie ha proporcionado un estuche de reproducción que podamos probar.

$ jest --verbose

este comando mostrará todos los registros de la consola

@odykyi no me funciona. broma 22.1.0 y v8.9.4

comportamiento extraño. Si configuro verbose en false , se imprimieron mis declaraciones de console.log.

en [email protected] , [email protected] , y usando --forceExit , no veo la salida de console.log de mi código probado a menos que establezca explícitamente verbose a false o elimine la bandera --forceExit (que estoy usando temporalmente).

en [email protected] , [email protected] , y usando --forceSalir, no veo el resultado de console.log de mi código probado a menos que establezca explícitamente verbose en falso o elimine el indicador --forceSalir (que estoy usando temporalmente).

Ver exactamente el mismo comportamiento que se indicó anteriormente. [email protected] , [email protected].

console.logging antes de que se llame a done() , pero la salida no se muestra con --forceExit . Cuando se elimina --forceExit , la salida de console.log se muestra al final.

Test Suites: 1 passed, 1 total
Tests:       35 skipped, 1 passed, 36 total
Snapshots:   0 total
Time:        2.512s
Ran all test suites matching /test\/api.test.js/i.
  console.log test/api.test.js:247
    bar

Entonces, ¿no es la solución obvia aquí antes de forzar la salida de vaciado de cualquier broma del búfer de salida que tenga internamente?

Tenemos un caso de prueba para ello: https://github.com/facebook/jest/blob/497be7627ef851c947da830d4a8e21046f847a78/integration-tests/__tests__/console_log_output_when_run_in_band.test.js#L24 ¿Es defectuoso de alguna manera?

¿Alguien puede configurar un repositorio de reproducción al que podamos echar un vistazo?

Adición rápida: jest --no-cache también parece significar que console.logs no se muestra.

Con Node 9.7.1 y jest 22.4.2 con babel 7, el uso de verbose parece funcionar bien para mostrar registros de consola desde dentro de las pruebas:

package.json

"dependencies": {
  ...
},
"jest": {
  "verbose": true
}

Ha pasado algún tiempo desde que esto no requirió la intervención del usuario, pero parece que el remedio ha sido consistente.

Este problema también nos ha estado molestando durante bastante tiempo, primero con la salida truncada aleatoriamente, ahora la salida totalmente ignorada. Para reproducir, clone la rama dev / dexie-search-index de este repositorio:
[email protected] : WorldBrain / Memex.git

Agregue esta línea en algún lugar de insertTestData () en src / search / index.test.ts:
console.log('!?!?!?!!?!?!!?'); expect(1).toBe(2)

Probado con las versiones 6.11 y 8.10 de Node.js. Resuelva esto lo antes posible, ya que hace que la codificación sea mucho más lenta :(

@frankred gracias. Configuré verbose: "false" y funciona.

Me encontré con este problema https://github.com/evanw/node-source-map-support/issues/207 ayer y parecía terriblemente similar a este problema aquí.

La razón por la que esto es problemático es porque las escrituras en process.stdout en Node.js a veces son asincrónicas y pueden ocurrir en múltiples ticks del ciclo de eventos de Node.js. Sin embargo, llamar a process.exit () obliga al proceso a salir antes de que se puedan realizar esas escrituras adicionales en stdout.

https://nodejs.org/api/process.html#process_process_exit_code

No he comprobado el código, pero si se usa process.exit() con --forceExit , explicaría por qué falta la salida del registro.

Acabo de agregar una solución que me funcionó en este problema relacionado: https://github.com/facebook/jest/issues/3853#issuecomment -375183943

@ledbit Eso no funcionó para mí. Vaya, un problema que ha durado un año y medio y aún no tiene solución.

Eso es cierto, pero todavía no hay mucho para que los desarrolladores continúen.

Encontré este problema más comúnmente dentro de una llamada asincrónica anidada dentro de un ejemplo asincrónico. No estoy muy seguro del caso con nadie más, pero mostrar su uso de console.log seguramente sería útil para resolver esto.

Ciertamente me está sucediendo. ¿Qué necesitas de mí para que puedas arreglarlo?

El 22 de marzo de 2018, a las 8:32 a. M., Dennis Brown [email protected] escribió:

Eso es cierto, pero todavía no hay mucho para que los desarrolladores continúen.

Encontré este problema más comúnmente dentro de una llamada asincrónica anidada dentro de un ejemplo asincrónico. No estoy muy seguro del caso con nadie más, pero mostrar su uso de console.log seguramente sería útil para resolver esto.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/facebook/jest/issues/2441#issuecomment-375349444 , o silencie el hilo https://github.com/notifications/unsubscribe-auth/ADrayIO4NBB2dZM1XL8ZQO32W9SUnu2Yks5Jtg8MQC .

Mejor aún, ¡adelante! Aquí está mi repositorio. https://github.com/RALifeCoach/handandfootserver.git

Ejecute jest desde npm o ejecute desde la línea de comando. Verá que hay muchos, muchos console.logs, pero la mayoría están cubiertos.

Allí, el equipo de desarrollo tiene todo lo que necesitan. Solucione este problema.

El 22 de marzo de 2018, a las 8:36 a.m., Christopher Oliphant [email protected] escribió:

Ciertamente me está sucediendo. ¿Qué necesitas de mí para que puedas arreglarlo?

El 22 de marzo de 2018, a las 8:32 a. M., Dennis Brown < [email protected] [email protected] > escribió:

Eso es cierto, pero todavía no hay mucho para que los desarrolladores continúen.

Encontré este problema más comúnmente dentro de una llamada asincrónica anidada dentro de un ejemplo asincrónico. No estoy muy seguro del caso con nadie más, pero mostrar su uso de console.log seguramente sería útil para resolver esto.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/facebook/jest/issues/2441#issuecomment-375349444 , o silencie el hilo https://github.com/notifications/unsubscribe-auth/ADrayIO4NBB2dZM1XL8ZQO32W9SUnu2Yks5Jtg8MQC .

@RALifeCoach mirando su repositorio ahora, hay bastante registro allí. ¿Le importaría señalar qué registro en particular se está perdiendo?

Ejecutarlo. Verá algunos resultados, pero muchos se sobrescriben.

El sábado 14 de abril de 2018 a las 3:10 a. M. Simen Bekkhus [email protected]
escribió:

@RALifeCoach https://github.com/RALifeCoach mirando su repositorio ahora,
hay bastante registro allí. Recuerde señalar qué inicio de sesión
en particular te estas perdiendo?

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/facebook/jest/issues/2441#issuecomment-381318608 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/ADrayHQCc8C0NmMmrtE7mEo2jN999CChks5tocsKgaJpZM4LVbUv
.

No estoy seguro de a qué te refieres con sobrescrito. ¿Se borra algo de la salida a la consola?

Si se escriben seis líneas usando console.log, las 6 aparecen brevemente y luego
el resumen de la prueba se superpone a algunas de las 6 líneas.

El sábado 14 de abril de 2018 a las 8:58 a. M. Simen Bekkhus [email protected]
escribió:

No estoy seguro de a qué te refieres con sobrescrito. ¿Es algo de salida al
¿La consola luego se borró?

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/facebook/jest/issues/2441#issuecomment-381339074 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/ADrayF0P5SqpHjaAAYcPaIAF7ubSMVRTks5tohyIgaJpZM4LVbUv
.

También estoy experimentando lo que describe @RALifeCoach . Veré que mi salida de registro parpadea en la pantalla a medida que se disparan las pruebas, luego, cuando me desplazo hacia arriba, esa salida ya no está allí.

Parece que esto sigue siendo un problema, incluso en el nodo 8.11.1. ¿Quizás deberíamos presentar un nuevo error y volver a consultar aquí?

Todavía tengo el mismo problema en el nodo v8.9.0.

Puedo confirmar el comentario de @RALifeCoach sobre la "sobrescritura" de la salida del registro: finalmente obtuve que aparecieran los registros etiquetando cada uno con una cadena particular de caracteres (por ejemplo, @@@ ) y ejecutando:

yarn test --verbose | grep '@@@'

Es un truco terrible (pierde todos los colores de la consola, pero aún ve fallas de prueba y un resumen de prueba final) pero es lo único que ha funcionado hasta ahora. Probé todo lo demás en los comentarios anteriores. Tenga en cuenta que el --verbose arg es necesario para esta solución (y se combina implícitamente con --watch través de react-scripts ).

[Usando react-scripts bifurcado para usar el último Jest v23.0.0, nodo v8.11.2]

La configuración de "verbose": true en package.json ayuda. Los registros aparecen en la parte inferior de la salida.

Hombre, para un problema cerrado, todavía veo a la gente quejarse de esto desde que se creó hace 2 años.

Creo que hay un código en Jest que nos juega una broma y "secuestra" console.log (),
convirtiéndolo en una operación no operativa, algo así como ...

console.log = function(){ /* do nothing */}

El remedio para restablecer console.log es, irónicamente, ver https://stackoverflow.com/questions/7089443/restoring-console-log
- para eliminar console.log

delete console.log
console.log("Can you hear me now, Jesters...?");

... y de repente - ¡Voila! - como un Fénix de las llamas - ¡ console.log() funciona de nuevo en Jest ...!
Jest incluso imprime "console.log (información de ubicación)" antes de registrar tu mensaje ...

>

console.log __tests __ \ libarray-helpers.test.js: 35
¿Pueden oírme ahora, bufones ...?

Además, he estado usando "logatim" isomórfico últimamente https://www.npmjs.com/package/logatim en lugar de console.log (), y
parece inmune a los intentos de secuestro de Jest ... (tal vez reinicia console.log ...)

Incluso puede "secuestrar" la consola de forma preventiva.Registrarse usted mismo por logatim
para registrar un mensaje de nivel de "información" en verde ...

// const logatim = require('logatim') // ES5
import logatim from 'logatim' // ES6
/* ... */
console.log = function(...args){ logatim.green.info("[INFO]",...args) } // ES6

(Por favor, no interpretes mi jocosidad como belicosidad ... ¿dónde está la alegría de nombrar un buen producto Broma si no puedes bromear un poco?)

Antes de difundir el odio, @ yanshuf0 , considere las herramientas gratuitas y abiertas de las que claramente se está beneficiando. Elegiste usar Jest. Si no le gusta, puede optar por irse (o arreglarlo usted mismo, el equipo es amigable y abierto a las relaciones públicas).

Estaba teniendo este problema de "sobrescritura" (Windows 10, terminal VS Code, proyecto node.js) y luego, mientras jugaba con él, el error dejó de ocurrir. Pensé que dejó de suceder porque dejé de usar --watch o porque agregué una opción "verbose": false , pero revertir esos cambios no hizo que el error regresara.

Sin embargo, tengo que preguntar, ¿Jest no asocia intencionalmente la salida del registro con la prueba que la produjo? Durante un tiempo, toda la salida de la consola estuvo por debajo de todos los resultados de las pruebas, pero ahora se muestra por encima de todos los resultados de las pruebas. Tan aleatorio.

--watchAll flag lo bloqueó. ahora funciona para mi

Después de usar broma durante meses, esto también me sucedió de la nada con el nodo 8.9. En un minuto, console.log estaba saliendo bien, al siguiente simplemente dejó de funcionar. Terminé en este hilo y probé algunas cosas. No usar --watch solucionó el problema, pero luego tuve que volver a ejecutar mi comando de prueba cada vez. El uso de --watch --verbose false solucionó el problema y automáticamente ejecutaría mis pruebas.

Encontrando el mismo problema aquí, gracias por la solución temporal @bkempner

Puedo confirmar que este es un problema tanto en 22.4.4 como en 23.4.1 (actualizado a partir de este comentario). Las banderas que estoy usando son:

$ jest --forceExit --runInBand --bail --ci --json --outputFile=/tmp/jest_results.json

Otro problema sobre el mismo tema sugirió agregar la opción --json , que funcionó durante un tiempo ... Tal vez alguna dependencia haya cambiado desde entonces, pero la salida STDOUT y STDERR siempre se suprime. Lo más cerca que estuve de algo que funcionó fue usar --watch ; a veces, algunos resultados se agregaban al final sin sobrescribirlos.

Encontré que --silent es verdadero por defecto, configúrelo como falso generará el archivo console.log: jest --silent=false

Parece que todavía hay un montón de informes de esto, algo claramente todavía está roto. Esto se cerró como una trampa de # 2166 que ahora está cerrado, pero aún así persiste.

@thymikee ¿Podríamos reabrir este problema?

Voy a reabrir esto, ya que el problema ha vuelto parcialmente y debemos solucionarlo.

En v23, el problema aparece en modo reloj, ya que hemos cambiado la forma en que funciona bajo el capó para ejecutar pruebas casi siempre en paralelo, por lo que el TTY no está bloqueado y uno puede cancelar pruebas de larga duración fácilmente: https: // github. com / facebook / jest / pull / 6647.
El único caso en el que no estamos generando trabajadores en el modo de vigilancia es cuando tenemos exactamente 1 prueba para ejecutar y es relativamente rápido (se ejecuta en menos de 1 s); en este caso, aún deberíamos ver console.log s apareciendo como siempre.

En mi caso, ejecutar todas las pruebas en el modo de reloj no ingrese correctamente. Si utilizo el modo de patrón para filtrar a una sola clase de prueba, el registro se trunca

Según el comentario de @davidgilbertson (https://github.com/facebook/jest/issues/2441#issuecomment-286248619) eliminando verbose: true en mi package.json y eliminando --verbose de mi Los indicadores de línea de comando me permiten ver los registros de la consola que de otra manera estaban ocultos. Eso es bastante confuso.

Tengo verbose: true en mi package.json y encuentro que las declaraciones console.log veces están allí y otras no (si tengo como 10 en total agrupadas, parecen aparecer, pero no por solo uno) - Creo que esto es quizás un problema asincrónico

Ocasionalmente también tengo este problema, habilito runInBand (https://jestjs.io/docs/en/cli.html#runinband) y eso lo soluciona.

@ndelangen eso es curioso, me pregunto si tal vez sea un problema asincrónico. Pensé que Jest recopiló todos los registros de la consola y luego los imprimió al final, ¿no?

El problema es recurrente ahora aunque no estoy usando verbose .

--runInBand no me lo arregla. La única solución alternativa confiable hasta ahora es simplemente registrar algo varias veces para que parte del resultado no se sobrescriba con broma.

Hice un análisis, agregué algunos comentarios y logré crear un parche parcial aquí:

https://github.com/facebook/jest/issues/3853#issuecomment -413622844

editar:

repositorio que contiene código para reproducir fácilmente disponible aquí: https://github.com/spion/jest-logging-repro

análisis de salida aquí: https://gist.github.com/spion/bbb34c5abc1230a37ad5f4f01336b8df

El parche es parcial porque

  • muchas pruebas de integración están fallando ahora debido a los cambios necesarios en la salida
  • a veces (desafortunadamente) la salida del registro aparece después de la última actualización de estado; la razón es probablemente el hecho de que los flujos del proceso secundario se vacían después de que el proceso secundario envía el mensaje de éxito al padre.

@philraj mismo problema para mí ... tengo que iniciar sesión varias veces para ver de manera confiable el mensaje de registro previsto

¿Cómo no es esto una preocupación importante y no se resuelve lo antes posible? ¿Cómo está abierto este problema desde 2016?

Actualización: con este parche, solo tengo 8 pruebas fallidas:

diff --git a/packages/jest-runner/src/index.js b/packages/jest-runner/src/index.js
index 2f4dd724..618a8cbf 100644
--- a/packages/jest-runner/src/index.js
+++ b/packages/jest-runner/src/index.js
@@ -97,11 +97,14 @@ class TestRunner {
     // $FlowFixMe: class object is augmented with worker when instantiating.
     const worker: WorkerInterface = new Worker(TEST_WORKER_PATH, {
       exposedMethods: ['worker'],
-      forkOptions: {stdio: 'inherit'},
+      forkOptions: {stdio: 'pipe'},
       maxRetries: 3,
       numWorkers: this._globalConfig.maxWorkers,
     });

+    worker.getStdout().pipe(process.stdout);
+    worker.getStderr().pipe(process.stderr);
+
     const mutex = throat(this._globalConfig.maxWorkers);

     // Send test suites to workers continuously instead of all at once to track
diff --git a/packages/jest-worker/src/worker.js b/packages/jest-worker/src/worker.js
index 5eee64af..17d76d36 100644
--- a/packages/jest-worker/src/worker.js
+++ b/packages/jest-worker/src/worker.js
@@ -87,6 +87,13 @@ export default class {
   }

   _initialize() {
+    const forceColor =
+      'FORCE_COLOR' in process.env
+        ? process.env['FORCE_COLOR']
+        : // $FlowFixMe: Does not know about isTTY
+          process.stdout.isTTY
+          ? '1'
+          : '0';
     const child = childProcess.fork(
       require.resolve('./child'),
       // $FlowFixMe: Flow does not work well with Object.assign.
@@ -94,6 +101,7 @@ export default class {
         {
           cwd: process.cwd(),
           env: Object.assign({}, process.env, {
+            FORCE_COLOR: forceColor,
             JEST_WORKER_ID: this._options.workerId,
           }),
           // Suppress --debug / --inspect flags while preserving others (like --harmony).

Se trata principalmente de no esperar que FORCE_COLORS en process.env, hg scm y packages/jest-runner/src/__tests__/test_runner.test.js no se burlen completamente de las transmisiones (por lo que no hay métodos de tubería en ellas.

A este ritmo, podré enviar un PR que corrija esto la próxima semana ... siempre que encuentre una solución para la salida del registro que aparece después de que el informe completo esté terminado.

Como dijo @bkempner , usar --watch --verbose false soluciona el problema.

La salida de la consola en --watch se sobrescribe moviendo el cursor es consistente con lo que estoy viendo. La presencia / ausencia de --verbose , --maxWorkers 1 , --runInBand no produce éxito.

Mi solución alternativa actual es jest --watch | cat . Pierdo todo el color y me quedo en la parte superior de la ventana, pero obtengo la salida de la consola.

O TERM=dumb jest --watch . Pierdo la posibilidad de quedarme en la parte superior de la ventana, pero obtengo color y la salida de la consola.

Yo tuve el mismo problema.

Lo que funcionó para mí fue usar console.debug

TERM=dumb me lo arregla también

FWIW, TERM = tonto me lo arregla también

deshabilitar verbose en la configuración de broma funcionó para mí 0_o \

Agregar --verbose false al script package.json "test" resolvió el problema por mí. Nunca lo hubiera encontrado sin este hilo.

p.ej

"scripts": {
    "test": "jest --watch --verbose false"
}

Es extraño cómo algunas de las últimas consolas desaparecen, pero no todas, lo arreglé con --verbose false en el comando de mi reloj.

Funciona bien cuando se ejecuta sin --watch por lo que es algo sobre la bandera del reloj lo que lo hace.

¡Lo que es tan irónico es que es más detallado cuando console.log funciona!

Comencé a notar este problema con detalles en Jest 23.6, volví a 23.5 y todavía lo veo. Si ejecuto --clearCache esto se corrige detallado por un tiempo hasta que vuelve a fallar. No tengo claro cuál es el desencadenante, como muchas fallas de registro o algo por el estilo. Una vez que eso sucede, parece que Jest corrompe el caché. Estoy probando el --verbose false y veo si eso impide que siga adelante.

Gracias @jamespolanco El uso de la opción --clearCache solucionó el problema (por el momento). Voy a ejecutar mis pruebas usando la opción --no-cache y veré si eso evita que el problema vuelva a ocurrir en el futuro.

EDITAR: Debería haber mencionado que mi problema era que solo se imprimieron algunos de mis mensajes console.log . Usé 5 console.log líneas en una prueba y solo se imprimieron las primeras 3 líneas. El uso de --clearCache solucionó este problema. ¿Quizás hay un problema diferente donde no aparecen console.log s?

Estoy teniendo este problema también. Intenté usar console.log, console.debug y console.error. También intenté usar el indicador --no-cache. En todos los casos, la declaración de mi consola se ignora por completo.

También tengo este problema en el modo reloj. Versión 23.6.0

Incluso lo grabé si a alguien le gusta verlo por sí mismo:
asciicast

como otros, solo se borra cuando se ejecuta con --watch . Intenté --verbose false y eso no ayudó.

También tengo el mismo problema.

También estoy experimentando esto cuando uso verbose o cuando estoy en modo reloj

Lo crea o no, a veces registro arrojando un error. También haciendo node --inspect node_modules/.bin/jest --runInBand mypath/to/my.test.js muestra las salidas reales console.log en mi caso.

Nodo v9.11.1
Broma: v23.6.0

Configuración de broma en package.json :

  "jest": {
    "preset": "react-native",
    "verbose": true,
    "testEnvironment": "node",
    "haste": {
      "defaultPlatform": "android",
      "platforms": [
        "android",
        "ios",
        "native"
      ],
      "providesModuleNodeModules": [
        "react-native"
      ]
    },
    "setupFiles": ["<rootDir>/__tests__/setup"]
  },

Confirmo que este problema es detallado. El problema es que el cálculo del recuento de líneas se estropea cuando el modo detallado está activado.

Si alguien puede señalarme el lugar donde imprime el mensaje, puedo intentarlo.

Puede mitigar la emisión usando jest-watch-toggle-config por el momento.

Configúrelo así:

module.exports = {
  "watchPlugins": [
    ["jest-watch-toggle-config", { "setting": "verbose" }]
  ]
}

Cuando ejecute su prueba, presione v para habilitar verbose y luego v nuevamente para deshabilitarlo .

Después de eso, siempre y cuando no esté detallado, podrá ver todos los registros.

--verbose=false solucionó el problema al probar la enzima superficial . Sin embargo, console.logs funcionaba sin la corrección para el montaje de enzimas .

Eso sugiere una diferencia entre cómo los errores son registrados por react-test-renderer, versus cómo son registrados por el renderizador incorporado de react (ya que la enzima no interfiere con las funciones de la consola)

Para su información, este PR soluciona el problema por mí: https://github.com/facebook/jest/pull/6871

Aún no está listo, es posible que necesite un cambio en el enfoque, pero muestra todos los datos registrados en modo detallado.

No se ha actualizado todavía (ejecutando broma 22.4.2) pero al usar el modo de reloj, mis registros no se muestran. Ejecutar con --runInBand solucionó en modo reloj.

    "test": "jest --watch --runInBand",
    "test:once": "jest",

Tampoco he actualizado (Jest 23.6.0), y ejecutar con "jest --watch --verbose = false" lo soluciona para mí también.

Me encantaría que las personas que tienen problemas prueben las relaciones públicas mencionadas anteriormente. Está disponible en jest@beta ( 24.0.0-alpha.9 ahora mismo)

¿Entonces el hilo agrega broma @ beta?

ons. 19. des. 2018 kl. 16:46 skrev Simen Bekkhus [email protected] :

Me encantaría que las personas que tienen problemas prueben las relaciones públicas mencionadas anteriormente. Es
disponible en jest @ beta (24.0.0-alpha.9 ahora mismo)

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/facebook/jest/issues/2441#issuecomment-448641697 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAM5P7ijQjSbWB0-zzDCfC9Uggyk5RGoks5u6l9EgaJpZM4LVbUv
.

>


Tarjei Huse
Móvil: 920 63 413

@tarjei , sí:

yarn add --dev jest<strong i="7">@beta</strong>

Me está funcionando. 🎉

Esto es realmente tonto, pero en caso de que ayude a alguien más, estoy trabajando en un proyecto nuevo (para mí): jest se estaba ejecutando con la opción --silent que desactiva la salida. Eliminé eso y ahora veo registros 🤦‍♂️

Observe que cuando se habilita verbose (lo alterno usando jest-watch-toggle-config ), parte del registro de la consola se está bloqueando en beta.

--verbose = falso

Esto funcionó para mí.

Me di cuenta de que algunos console.log() estaban funcionando mientras que otros no en mis pruebas (nodo v8, [email protected])

const something = () => new Promise(resolve => {
  console.log('NOT logged for some reason!')
  setTimeout(resolve, 100);
});

describe('Something', () => {
  it('logging works in non-async test', function () {
    console.log('logged 1')
    console.log('logged 2')
    expect(true).toBe(true);
  });

  it('console log does not work well in async test', async () => {
    console.log('logged 3')
    await something();
    console.log('NOT logged!')
    expect(true).toBe(true);
  });
});

/* Output:
> logged 1
> logged 2
> logged 3
*/

Hay algo muy raro en marcha, con async pruebas en las que el primer console.log no se está registrando en la prueba asíncrono, también el que después de que el await no se registra.

Agregue un poco más de console.log en esa prueba async y comenzará a notar un comportamiento aún más extraño, como algunos de los registros después de que await repente funcionen 🤷‍♀️ 🤷‍♂️

Entonces, lo que @philwhln escribió arriba hace dos años

Como no puedo aislar esto en una prueba simple, supongo que tiene algo que ver con ejecutar una prueba asincrónica más compleja.

Parece tener algo de verdad.

--verbose = falso

También funcionó para mí en este caso.

@DanweDE, ¿puedes comprobar si el último alfa yarn add jest<strong i="6">@beta</strong> --dev soluciona el problema, incluso con la configuración detallada en true ?

Agregar --verbose false solucionó el problema. Eso parece un poco intuitivo :)

¿Está esto arreglado? Sigo sin aparecer console.logs en "jest": "23.6.0"

@iDVB Si lees el hilo de un par de comentarios arriba, verás que hay una versión beta que se supone que soluciona el problema. Pruébelo e informe si resuelve su problema para ayudar a @spion

Además, todos los que vienen aquí para decir --verbose false o --verbose true o cualquier combinación de indicadores o versiones de Node o Jest solucionaron su problema, pruebe la versión beta e informe si soluciona su problema sin su solución alternativa.

aparecen los registros de la consola en las clases que estoy probando

@philraj hemos cambiado a la versión beta "24.0.0-alpha.9" en @leaplabs y funciona a la perfección. En el sentido de que no vi desaparecer ningún registro desde que actualizamos.

También puede confirmar, funciona en 24.0.0-alpha.9 sin ningún argumento de línea de comando.

Soy relativamente nuevo en React y Jest. No pude obtener registros consistentes usando los valores predeterminados de create-react-app. Expulsé y ahora los registros funcionan bien. No creo que la expulsión haya cambiado la versión de Jest. Tal vez eso solo cambió una de las configuraciones de cómo se estaba ejecutando Jest. Esto es con 23.6.0 .

Cuando uso 24.0.0-alpha.16 no veo ningún registro de la consola a menos que agregue verbose=false .

También obtengo resultados bastante inconsistentes con esto en [email protected]. Si ejecuto en modo de reloj todo (a), entonces puedo ver la salida de la consola, pero no si ejecuto en el modo de reloj de cambios relacionados (o).

--verbose=false arregló esto también 🎉

Estoy usando 24.1.0 y funciona incluso sin la opción detallada. Sin embargo, no genera ninguna declaración console.log en el archivo de prueba cuando el archivo de prueba contiene, por ejemplo. referencia a la clase, que no se importa. Por ejemplo

image

Eso es un error de ts-jest y no es realmente relevante aquí

Sí, pero cuando se produce ese error, no se muestra la salida del registro de la consola. ¿Sigue siendo relevante para ts-jest ? No estoy muy familiarizado con lo que es responsable de cada biblioteca alrededor de broma.

IDK cómo funciona ts-jest , pero si no ejecuta ninguna prueba en los errores de tipo, eso explicaría por qué faltan: el código nunca se ejecuta

Todavía estoy luchando para que console.log funcione aquí. De vez en cuando obtengo registros, pero parece que no hay un patrón discernible para el éxito.

Estoy usando Jest 24.7.1 y también he probado 24.7.1 y 24.2.0-alpha.0 .

La configuración verbose=false y verbose=true han podido proporcionar una solución.

También intenté usar el nodo v10.8.0 y v6.17.1 , también sin solución.

¿Falta algo aquí?

@mulholio, ¿estás 100% seguro de que estás ejecutando Jest instalado localmente? Informé problemas en el pasado que solo sucedieron porque tenía una versión global anterior de un paquete que se estaba ejecutando en lugar de la instalada localmente.

Sí, no hay versiones globales de Jest instaladas

Puedo confirmar que no se ha resuelto. a veces console.log funciona y a veces no, qué confundido me.
mi entorno de la siguiente manera:
broma 23.6.0
nodo v8.13.0
y mi jest.config.js

const path = require('path');

module.exports = {
  moduleNameMapper: {
    "\\.(jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$": "<rootDir>/__mocks__/fileMock.js",
    "\\.(less|css|scss)$": "<rootDir>/__mocks__/cssMock.js",
    "^@\/(.*)$": "<rootDir>/src/client/$1",
  },
  bail: true,
  setupTestFrameworkScriptFile: "<rootDir>/setupTests.js",
  collectCoverageFrom: [
    "src/client/**/*.{js,jsx}",
  ],
  verbose: true,
  coverageReporters: ["text", "text-summary", "lcov", "json"],
  coveragePathIgnorePatterns: ["src/client/index.js"],
}

sí, después de eliminar verbose: true , parece estar bien

También veo este error, ¿podemos volver a abrir este problema?

FYI: Si uso fit para ejecutar una sola prueba, mis console.log s no arrojaron nada. Cuando ejecuté todo el conjunto de pruebas, los console.log s funcionaron bien.

Al encontrar el mismo problema, algunos registros de la consola se "devoran". Para aquellos que tienen este problema, ¿pueden verificar pero clonar varios registros de la consola?

console.log('ok');
console.log('ok');
console.log('eaten up');

Parece que el búfer para la declaración [PASS] está escribiendo sobre las últimas 2 líneas de registro de la consola (puedo ver parte del número de línea de registro de la consola al final de la declaración Pass)

+1000

suena muy tonto, pero asegúrate de yarn build antes de las pruebas.

Todavía no hay salida con --verbose=true o --verbose=false cuando se usa [email protected] ; no estoy seguro de por qué sigue siendo un problema 3 años después de que se registró originalmente.

¿Ha intentado usar la bandera de broma --runInBand para ver si eso lo resuelve ejecutando pruebas en serie? Alguien me mencionó esto, pero no tuve la oportunidad de probarlo.

Gracias, funciona! Pero, ¿por qué no establecerlo de forma predeterminada para que tenga la salida de console.log ..?

Esto sigue siendo un problema para mí, [email protected]

En realidad, encontré una solución, las últimas 2 líneas en el último caso de prueba (en cascada) se anulan, así que haga de este su último caso de prueba

it('bugfix for [email protected]', () => {
  console.log("[email protected] bug|last 2 lines get override. remove this once 24.8.0 gets fixed");
  console.log("[email protected] bug|last 2 lines get override. remove this once 24.8.0 gets fixed");
});

Para aquellos que usan ts-jest , tuve que desactivar los diagnósticos para ver el archivo console.logs
jest.config.js

  globals: {
    'ts-jest': {
      diagnostics: false,
    },
  },

Para aquellos que usan ts-jest , tuve que desactivar los diagnósticos para ver el archivo console.logs
jest.config.js

  globals: {
    'ts-jest': {
      diagnostics: false,
    },
  },

Esta opción no nos funcionó. También intentamos configurar verbose = false que tampoco ayudó.

Nuestro ambiente:

  • Nodo 10.16.0
  • broma 24.8.0
  • ts-broma: 24.0.2
  • mecanografiado 3.5.2
  • @ tipos / broma 24.0.15

Parece que el búfer para la declaración [PASS] está escribiendo sobre las últimas 2 líneas de registro de la consola (puedo ver parte del número de línea de registro de la consola al final de la declaración Pass)

Este parece ser mi caso ([email protected]). En mi sistema, la línea de salida del terminal con [PASS] parece parpadear algún contenido antes de que se borre.

Experimentando este problema también.

No puedo iniciar sesión con ninguna de las soluciones anteriores, pero como solución temporal, espero fallar con el valor y verificar la diferencia:

expect(thingIWantToLog).toBe({})

También encontré esto: parece que la salida "PASS: ..." está sobrescribiendo la salida estándar, por lo que su "último" console.log será devorado.

Si --verbose=false no funciona, puede agregar un montón de nuevas líneas de sacrificio ( \n ) a su último archivo console.log.

¿Ha intentado usar la bandera de broma --runInBand para ver si eso lo resuelve ejecutando pruebas en serie? Alguien me mencionó esto, pero no tuve la oportunidad de probarlo.

Agregar esta bandera ayudó a resolver el problema.
De vez en cuando tampoco mostraba las salidas de console.log.
Usando este comando:
npm test -- --verbose --runInBand -t "My Test Name"

Versiones de nodo y NPM:
node v8.16.0
npm 6.4.1

Esta es mi ronda de trabajo:

npm install --save-dev sprintf-js

En tu broma setupTest.js , o donde sea:

import {sprintf} from 'sprintf-js';

console.log = (msg, args) => {
    const str = sprintf(msg, args);
    process.stderr.write(str + '\n');
  };

Todavía no hay salida con --verbose=true o --verbose=false cuando se usa [email protected] ; no estoy seguro de por qué sigue siendo un problema 3 años después de que se registró originalmente.

Este es mi jest.config.js y funcionó para mí.
jest -v 23.6.0 & node -v 8.11.2

module.exports = {
  clearMocks: true,
  moduleDirectories: [
    'node_modules',
  ],
  testEnvironment: 'node',
  testMatch: [
    '**/__tests__/**/*.js?(x)',
    '**/?(*.)+(spec|test).js?(x)',
  ],
  verbose: false,
};

Luego, en package.json tengo:

"scripts": {
  "test": "jest --config ./jest.config.js",
}

Luego, ejecute su conjunto de pruebas específico con este comando:

yarn test -- -t 'test-suite-name-here'

--verbose=false parece haber funcionado para mí. ¡Gracias!

Broma oculte los registros y las advertencias cuando pase la opción --silent
Prueba yarn jest , debería funcionar

Este error es tan molesto ... 3 años ...

apagar --silent
¡y para pruebas ts usando la solución ts-jest @ mr-madamin que funciona para mí!

Sin usar verbose o silent , he probado --runInBand , TERM=dumb , ejecutando todas las pruebas frente a un solo archivo de prueba, y console.log aparece cuando colocados en bloques de configuración pero no dentro de los bloques it() .

Cuando todo lo demás falla, aún debería poder hacer:

require('fs').writeFileSync('./output', data);

Pero me siento como un hombre de las cavernas que usa una piedra para romper un maní.

editar: "jest": "^24.9.0"

Estoy usando este comando y funciona:

npm test -- --runInBand -t "My Test Name"

Puede especificar su Nombre de prueba después de la marca -t para ejecutar pruebas individuales o grupos de pruebas bajo el mismo describe () .

Sin usar verbose o silent , he probado --runInBand , TERM=dumb , ejecutando todas las pruebas frente a un solo archivo de prueba, y console.log aparece cuando colocados en bloques de configuración pero no dentro de los bloques it() .

Cuando todo lo demás falla, aún debería poder hacer:

require('fs').writeFileSync('./output', data);

Pero me siento como un hombre de las cavernas que usa una piedra para romper un maní.

editar: "jest": "^24.9.0"

Estaba emocionado de finalmente comenzar a usar broma en el backend para lograr uniformidad. En cambio, me encuentro con este problema y, a partir de ahora, estoy volviendo a mocha / proxyquire. No hay salida console.log visible (en módulos o casos de prueba) y después de pasar varias horas en ella, ninguna de las soluciones parece ayudar. No estoy interesado en ninguna solución alternativa que implique el registro en archivos ...

Probado contra el nodo 8/10 LTS con "jest": "^24.9.0",

Sí. Yo también estoy al límite. Parece que es más popular aquí cerrar el problema y recomendar hacks en lugar de solucionar problemas obvios durante más de 3 años.

Hola samlevin y pavelloz,
¿Has probado esta opción?

Estoy usando este comando y funciona:
npm test -- --runInBand -t "My Test Name"

Puede especificar su Nombre de prueba después de la marca -t para ejecutar pruebas individuales o grupos de pruebas bajo el mismo describe ().
¿Podrías hacerme saber si funciona? Como lo he estado usando por un tiempo.

Aquí hay una captura de pantalla con un código de ejemplo y una salida.
TENGA EN CUENTA que: en caso de que no lo sepa, el archivo console.lg se imprime encima de todos los demás informes, y no al final donde ve el informe de cobertura del código o el resumen del error.
Jest test console log

Versiones de My Node y NPM:

node v8.16.0
npm 6.4.1

Estaba emocionado de finalmente comenzar a usar broma en el backend para lograr uniformidad. En cambio, me encuentro con este problema y, a partir de ahora, estoy volviendo a mocha / proxyquire. No hay salida de console.log visible (en módulos o casos de prueba) y después de pasar varias horas en ella, ninguna de las soluciones parece ayudar. No estoy interesado en ninguna solución alternativa que implique el registro en archivos ...

Probado contra el nodo 8/10 LTS con "jest": "^24.9.0",

He probado todas y cada una de las soluciones de este hilo.

Solo para verificar si nada cambió a este respecto:
image

bash-5.0$ npm -v ; node -v; cat node_modules/jest/package.json |grep version
6.12.0
v12.11.0
  "version": "24.9.0",

Editar

TENGA EN CUENTA que: en caso de que no lo sepa, el archivo console.lg se imprime encima de todos los demás informes, y no al final donde ve el informe de cobertura del código o el resumen del error.

Ni siquiera estaba revisando la parte inferior del informe, pero ahí es exactamente donde aterrizó mi registro. Así que supongo que funciona, pero no de manera consistente / de la misma manera para todos.

image

Gracias por tu ayuda.

La pregunta es cuánto afecta el rendimiento, pero eso es para otro día, el registro es más importante.

Tienes razón @pavelloz , cuando ejecutas las pruebas con la opción --runInBand, tomará más tiempo terminar las pruebas porque hace esto:

--runInBand, -i                 Run all tests serially in the current process
                                  (rather than creating a worker pool of child
                                  processes that run tests). This is sometimes
                                  useful for debugging, but such use cases are
                                  pretty rare.

Entonces, lo que hago es usar esa opción solo cuando necesito depurar un problema en una prueba.
El resto del tiempo, simplemente ejecute la prueba normalmente.

Salud

componente constante = superficial (...)
console.log (componente.debug ())

Es increíble que esto aún no se haya solucionado.

@ivandosreisandrade Pude verificar la solución alternativa de la bandera runInBand , pero en este momento prefiero no perder el tiempo agregando el paso adicional para otros desarrolladores, y he vuelto a algo que se comporta como se esperaba fuera de la caja. permanecerá suscrito para ver si algo cambia al respecto

Probé todo en este hilo y todavía no puedo ver el resultado de console.log. --runInBand no me resuelve el problema. Usando node @ 12 y la última broma. La depuración con web dev es bastante difícil, sería realmente útil si al menos pudiera imprimir en la pantalla para ver por qué mi prueba unitaria está fallando

@ u84six ¿has probado mi solución?
Aquí está el enlace a mi respuesta en la publicación.
https://github.com/facebook/jest/issues/2441#issuecomment -552368939

Salud

@ivandosreisandrade, lo que sucede es que si hay un error en el código (como hacer referencia a un valor indefinido), no se imprimirá, incluso si la llamada a console.log es anterior al error. Si todo en la prueba pasa, veré el registro. Ese tipo de comportamiento lo hace totalmente inútil para depurar.

@ivandosreisandrade ¿cómo se ve su package.json? Estoy tratando de seguir esto:

npm test - --runInBand -t "Mi nombre de prueba"

Pero lo tengo configurado así en mi package.json

" prueba: unidad ": "broma --verbose"

Uno pensaría que con el indicador --verbose, permitiría que un console.log pasara, pero todavía no puedo hacer que console.log funcione. ¡Muy frustrante!

@ivandosreisandrade ¿cómo se ve su package.json? Estoy tratando de seguir esto:

npm test - --runInBand -t "Mi nombre de prueba"

Pero lo tengo configurado así en mi package.json

" prueba: unidad ": "broma --verbose"

Uno pensaría que con el indicador --verbose, permitiría que un console.log pasara, pero todavía no puedo hacer que console.log funcione. ¡Muy frustrante!

@ u84six este es mi packadge.json

"scripts": {
    "test": "jest test --coverage",
    ... 
},
...
"jest": {
    "verbose": true,
    "testMatch": [
      "**/tests/**/*.js?(x)"
    ],
    "moduleFileExtensions": [
      "js"
    ],
    "moduleDirectories": [
      "node_modules"
    ]
  }

Su testMatch permite archivos .js o .jx o .jsx , y su moduleFileExtensions solo permite .js . Algo parece estar mal ahí.

No es relevante para la causa: man_shrugging:
Eso es solo qué archivo ubicar y ejecutar pruebas contra ellos.

No estoy seguro de por qué se ha cerrado el problema. Así que aquí está mi versión de nodo: 13.12.10, npm -6.14.4
broma -24.9.0

Aquí hay una prueba básica con mock-fs
importar simulacros de 'mock-fs';
importar * como fs desde 'fs';
importar bomba de 'bomba';
importar * como util de 'util';

describe('Test suite for bucket functionality', () => {
    beforeEach(() => {
        mock({
            'sample-file.txt': 'Content of the sample file',
            'sample-upload.txt': ''
        });
    });
    test('test upload', async () => {
        const filePromisy = util.promisify(fs.readFile);
        pump(fs.createReadStream('sample-file.txt'), fs.createWriteStream('sample-upload.txt'));
        filePromisy('sample-upload.txt').then(data => {
                       // when I do a console.log() here I get a warning stating that before I do an expect of data , I get a warning (no longer an error) stating that -_Cannot log after tests are done._

        }).catch(err => {

        });



    });
    test('test download', () => {

    });
});

No estoy seguro de por qué sucede esto. ¿Esto se debe al bucle de eventos donde se hace que el archivo console.log se considere procesado en el nextTick () solo después de la ejecución de las especificaciones de prueba? Disculpas por mencionar esto, pero parece bastante tedioso depurar cada caso de prueba, en lugar de simplemente hacer una operación de consola y verificar los datos requeridos.

Debido a que debe devolver su promesa de filePromisy en broma para que sepa cuándo se realiza la prueba, su problema no tiene nada que ver con este.

Solucioné este problema con fines de depuración simplemente colocando lo que quisiera para iniciar sesión en una declaración expect temporal. Entonces, en lugar de console.log(sketchyVariable) , use expect(sketchyVariable).toEqual(42) .

Lo que funcionó para mí en el nodo 8:
En lugar de usar console.log , use el registro de depuración integrado:

const util = require('util')
const myLogger = util.debuglog('myloggername')
myLogger('foobar')

Y comience bromeando con la bandera del depurador:

NODE_DEBUG=myloggername npm test -t "My Test Name"

Veía que los registros de la consola aparecían esporádicamente cuando veía una sola prueba. A veces veía todos los registros, otras no veía ninguno y otras veía algunos de ellos, pero no todos. Cada vez que se realizaba la prueba, veía algo diferente. 😒

--verbose=false me lo arregló. Me sorprendió esto, porque no estoy configurando verbose en true ninguna parte. Resulta que Jest lo establecerá en true automáticamente si está ejecutando una sola prueba . 🙃

si solo se está ejecutando un archivo de prueba, el valor predeterminado será verdadero.

https://jestjs.io/docs/en/configuration#verbose -boolean

Hilo relacionado de StackOverflow: https://stackoverflow.com/questions/48695717/console-log-statements-output-nothing-at-all-in-jest

jest no maneja bien el registro en varios niveles. debería

  • capturar y mostrar todos los registros capturados para una prueba en caso de falla de forma predeterminada
  • tener la opción de no mostrar ninguno, y
  • tiene una opción para deshabilitar la captura.

Eso es. no es complicado realmente.

Supongo que están capturando los registros de la consola porque están tratando de obtener una salida asincrónica para imprimir en un orden sensato al ejecutar las pruebas. El problema es que si este código de registro no funciona para un usuario, en su entorno, está prácticamente bloqueado.

Dejé de usar broma hace años, porque no podía obtener resultados de consola de manera confiable al depurar pruebas, no importa qué sugerencias seguí en este hilo.

La moraleja de la historia es que no te metas con la consola global. ALGUNA VEZ. Si desea proporcionar un registrador que pueda encenderse o apagarse, genial, hágalo. Lo usaré si quiero. Pero no se debe interferir con la consola global.

Obtenga Outlook para iOS https://aka.ms/o0ukef


De: earonesty [email protected]
Enviado: miércoles 12 de agosto de 2020 12:33:23 p.m.
Para: facebook / jest [email protected]
Cc: Chris Grimes [email protected] ; Mencione menció[email protected]
Asunto: Re: [facebook / jest] console.log no se muestra cuando se ejecutan pruebas (# 2441)

jest no maneja bien el registro en varios niveles. debe capturar registros y mostrarlos en caso de falla de forma predeterminada, tener una opción para mostrar ninguno y tener una opción para mostrar todos. Eso es.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/facebook/jest/issues/2441#issuecomment-673011577 , o cancele la suscripción https://github.com/notifications/unsubscribe-auth/AAFCNBK5MQEA6AJHEC52ZWDSALG6HANCNFSQM4C2VWUX .

@halis He usado Jest de forma

Mi sensación es que el juego principal de Jest es estar feliz de romper el comportamiento esperado y la semántica de vez en cuando si mejora drásticamente la experiencia de prueba. Cosas como la elevación automática de jest.mock(...) significan que las pruebas de Jest no son estrictamente JavaScript (o incluso ECMAScript) en su semántica; Del mismo modo, el paralelismo significa que cualquier método incorporado de retorno vacío como console.log puede y debe tratarse como asíncrono, si puede mejorar el rendimiento.

¿Eso es algo malo? Claramente no necesariamente, ya que Jest tiene un enorme éxito. Pero sí creo que Jest tiene la capacidad de sorprenderte de vez en cuando. Estoy bastante seguro de que el 90% de los usuarios de Jest no tienen idea de que su código está transformado en AST para realizar llamadas simuladas, por ejemplo.

Estoy bastante seguro de que el 90% de los usuarios de Jest no tienen idea de que su código está transformado en AST para realizar llamadas simuladas, por ejemplo.

QUÉ

Intente usar console.debug o console.error

Puedes usar --useStderr en mi caso resolvió el problema porque pasa mensajes directamente

https://nodejs.org/api/process.html#process_a_note_on_process_i_o

He estado luchando con esto nuevamente hoy y la bandera --useStderr me lo arregló. ¡Gracias @diomalta!

Estaba luchando con el mismo problema, los registros no se mostraban cuando fallaba una prueba.

Logré que mi console.log mostrara configurando verbose: true en mi jest.config

¿Fue útil esta página
0 / 5 - 0 calificaciones