@thymikee ¿ Alguna idea de por qué sucede esto?

No tengo idea, pero intentaría minimizar el ejemplo, por ejemplo, eliminando mecanografiado

Puedo reproducir sin mecanografiado

Puede confirmar que Node 7.4 come registros de la consola, pero funciona en Node 7.5.0, 7.10.0, 8.0.0 y 8.1.2.
Actualice su versión de Node. Clausura

@thymikee ¿Qué pasa con Node 6, que es la versión actual de LTS? (Parece que también estoy haciendo esto, aunque todavía no lo he depurado lo suficiente. Sin embargo, estoy limitado a las versiones LTS por ahora, así que no puedo actualizar).

Probado en v6.11.0, aún muestra console.log s.

Ah, podría estar teniendo algún otro problema. Gracias, @thymikee , volveré a depurarlo un poco más.

Estaba ejecutando Node 7.3.0 sin saberlo (versión incorrecta a través de n) y no estaba registrando. Cambió a 8.1.1 y volvió a iniciar sesión.

@thymikee - ¿No veo cómo esa es la solución? ...No puedo actualizar la versión de mi nodo

Supongo que estoy un poco confundido sobre cómo esto se consideraría un error de Node y no tendría al menos algo que ver con Jest. Usando Node v7.4.0, con Jest v19.0.2, veo el registro de consola de mis pruebas. Simplemente actualizando Jest a v20.0.4 (sin hacer ningún cambio en ninguna otra configuración) hace que el registro de la consola ya no aparezca. ¿Hay algo que me estoy perdiendo?

@thymikee Entonces, actualicé la versión de mi nodo y no veo registros de consola en Node 8.2.1 Winx64 + Jest 20.0.4. Tengo que usar un respaldo por ahora

  console.log = s => {
    process.stdout.write(s + "\n");
  };

y estoy bastante seguro de que debería arreglarse en Jest, ya que las versiones anteriores no tenían este problema.

@nowherenone ¿puede probar si sucede en la última versión alfa jest@test ?

@thymikee Acabo de probar con jest@test en el nodo 8.2.1 pero el mismo resultado. Las declaraciones console.log siempre se tragan.

@thymikee El problema está en el módulo BufferedConsole, donde los parámetros del constructor de la consola no coinciden con los esperados.

Abrí un PR, tal vez ayudaría: https://github.com/facebook/jest/pull/4157

Creo que el problema aquí es que Jest almacena en búfer los mensajes, pero hay algo que hace que se escape (o un bucle infinito, etc.). Deberá usar --verbose para imprimir los mensajes directamente en el flujo de salida.

Esto es ridículo: me provoca la cantidad de respuestas inútiles de @cpojer (en cada número y relaciones públicas a las que voy) y trato de culpar a todos los demás como si de alguna manera no fuéramos lo suficientemente inteligentes.

No uses Jest, esa es mi respuesta si te lo estás preguntando. Encuentre un nuevo marco de prueba.

describe('index', () => {
  it('doesnt print anything', () => {
    console.log('Hellllooo');
    expect(true).toBe(true);
  });
});

$ yarn test -- src/__tests__/index.spec.js --verbose
yarn test v0.27.5
warning package.json: No license field
$ jest "src/__tests__/index.spec.js" "--verbose"
 PASS  src/__tests__/index.spec.js
  Index
    ✓ doesnt print anything (2ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        0.969s, estimated 2s

$ jest "--version"
v20.0.4
$ node --version
v7.4.0

Estoy seguro de que me dirán que instale una versión más nueva de Node Lmao, qué broma 😂 😂 😂

@nf071590 no puede reproducir, funciona en repl.it con exactamente las mismas versiones de Jest y Node: https://repl.it/KYLc/0

Proponga una reproducción seria antes de despotricar sobre los mantenedores del proyecto.
¡Salud!

No estoy seguro de qué hacer al respecto. Literalmente pegué su ejemplo en un archivo y ejecuté Jest, y funciona como se anuncia en mi Mac, con la última versión maestra de Jest desde hace un minuto. Ver:

Lanzando desde que estoy en Windows (nodo 8.4, broma 21.0.0-alpha.2), console.log s están _a veces_ ocultos si no usa --verbose , pero parecen mostrarse constantemente con eso. Feliz de actualizar con los resultados usando el nodo 7 y la broma estable cuando tenga un minuto.

El mismo problema aquí.

describe('index', () => {
  it('doesnt print anything', () => {
    console.log('Hellllooo');
    expect(true).toBe(true);
  });
});

$ node --version
v7.4.0
$ jest "--version"
v21.1.0

Actualmente se encuentra con el mismo problema en el nodo v8.7.0 (npm v5.4.2).

Esto sigue siendo un problema

¿Puede proporcionar una reproducción?

FWIW, terminé aquí porque tenía exactamente el mismo problema. Nodo v7.4.0. Actualicé mi versión de Node, y console.log se imprime como se esperaba ahora, incluso sin --verbose . V7.4.0 puede no ser la única versión que tenga este problema, pero parece estar relacionado con la versión y no es un problema para algunas versiones de Node. Ahora estoy en Node v8.3.0, que parece funcionar.

Dicho esto, antes de la actualización tenía las mismas versiones que @ nf071590 y los mismos problemas. No estoy seguro de por qué no sucede en repl.it, pero no es algo extraño que solo sucede en su computadora.

Puedo reproducir esto con el nodo 8.9.0 y jest 21.2.1, macOS 10.12.6 (16G1036)

@SimenB Podría, pero parece que este tema se ha discutido hasta la saciedad aquí y en otros lugares. La naturaleza de proceso múltiple (hijo) de jest significa que sobrescribirá console.logs , y sin una reescritura masiva eso no va a cambiar. Cualquiera que venga a este hilo y quiera evitar el problema de usar el indicador --verbose que no permite la depuración con console.log , debe usar el indicador --watch . Esto evitará que los procesos de trabajadores secundarios se sobrescriban y le permitirá ver una salida detallada con los registros de la consola. --watch es muy rápido y agrega más valor al enfocar la atención en las pruebas y el código que han cambiado, al ejecutar solo aquellas pruebas que se cambiaron al guardar.

En mi caso, descubrí que los mensajes detallados consumirían algunos, pero no todos, los mensajes console.log . ¡Eliminé la opción detallada y parece funcionar un poco!

Acabo de actualizar mi versión de nodo de v6 a v9 y uno de mis archivos de prueba es consolador.

Llevo semanas batallando con el problema. Me alegro de que funcione ahora

El problema aún persiste con --verbose cuando se combina con --forceExit . Creo que la razón es que console.log genera stdout mientras que Jest escribe en stderr y cuando --forceExit aún puede haber contenido en stdout no se vacíe

Encontré la siguiente solución (sin la necesidad de --verbose ) para corregir que console.log no se muestra y/o console.log se almacena en búfer y no se muestra en vivo

mando
jest .... --forceExit --setupTestFrameworkScriptFile ./src/tests/jestShim.js

contenido de jestShim.js

const { Console } = require('console');
global.console = new Console(process.stderr, process.stderr);

El mismo problema: nunca ver la salida de console.log nunca.

Node 9.80 Jest 22.4.2 Mac OS 10.13.3

Ninguna de las soluciones sugeridas aquí funcionó para mí.

Como siempre, cree una reproducción que podamos desplegar para probar. No me he encontrado con este problema, así que no estoy seguro de cómo comenzar a solucionarlo.

La solución alternativa de @ledbit funcionó para mí
MNP 5.3.0
broma 22.4.3

• Mac OS

Todavía estoy en el punto de necesitar una reproducción.

--forceExit parece algo roto, pero no lo he encontrado cuando no uso esa bandera

[Usando react-scripts bifurcado para usar la última versión de Jest v23.0.0, nodo v8.11.2]

Finalmente conseguí que aparecieran los registros al etiquetar cada uno con una cadena particular de caracteres (por ejemplo @@@ ) y ejecutar:

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

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

Esto sigue siendo un problema. Estoy usando jest v22.4.3 en Node 10.1.0 y solo veo la primera instrucción console.log de mi aplicación, todo el resto se ignora. Cuando configuro mi biblioteca de registro para transmitir a la salida estándar, puedo ver algunos de los registros, pero no aparecen en el orden correcto.

El trabajo de Jest como corredor de pruebas es ayudarnos a depurar y corregir nuestro código. Eso simplemente no se puede lograr sin registros.

@thymikee , vuelve a abrir este problema

@thanpolas siéntase libre de crear un nuevo problema con un repositorio que muestre el error para que podamos investigar :). Además, use Jest 23, ya que es la última.

Descubrí mi problema, el registro estaba ocurriendo a través de un registrador que estaba transmitiendo a stdout, cuando se redirigió a console.log, olvidé invocar la devolución de llamada del escritor de flujo, por lo que el flujo dejó de enviar registros.

Por lo que vale, he visto diferencias entre Terminal e iTerm2.

Creo que una opción para indicarle a jest que no haga magia en la salida estándar y la consola sería muy beneficiosa para todos.

Aquí hay una instancia del error que logré reproducir. Sin embargo, no estoy seguro de si hay varias fuentes:

https://github.com/spion/jest-logging-repro

yarn install; yarn repro

Configuración: Jest está en modo de observación, con el indicador detallado activado, con al menos dos archivos de prueba ejecutándose.

Teoría: la salida de uno de los trabajadores mueve el cursor de la consola al lugar equivocado sobrescribiendo el contenido incorrecto.

Observación en consola:

 RUNS  tests2/other-tests.js
 RUNS  lib/example.spec.js
 PASS  tests2/other-tests.js
  bar
    ✓ always is true (17ms)

 PASS  lib/example.spec.js
  foo
    ✓ adds 5 (5ms)

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

Watch Usage: Press w to show more.

Si elimino el registro de la consola, visualmente "RUNS" se sobrescribe como se esperaba:

 PASS  lib/example.spec.js
  foo
    ✓ adds 5 (5ms)

 PASS  tests2/other-tests.js
  bar
    ✓ always is true (5ms)

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

Watch Usage: Press w to show more.

Si agrego 3 registros de consola:

 PASS  lib/example.spec.js
  foo
    ✓ adds 5 (5ms)


 RUNS  tests2/other-tests.js

Test Suites: 1 passed, 1 of 2 total
Tests:       1 passed, 1 total
Snapshots:   0 total
  console.log tests2/other-tests.js:5
    JEST

 PASS  tests2/other-tests.jsests.js:6
  bar
    ✓ always is true (19ms)

Test Suites: 2 passed, 2 total
Tests:       2 passed, 2 total
Snapshots:   0 totalTime:        1.788sRan all test suites.

Watch Usage: Press w to show more.

Versión de nodo:

30656 % node --version
v8.11.2

Creo que @spion se está concentrando en eso. Buena reproducción fácil.

Puedo confirmar que esto sucede en Node v8.11.1 LTS y solo sucede en el modo watch y watchAll . sin modos de reloj, está bien.

Tengo el mismo problema con Node v10.6.0 y Jest 23.4.1

Sí yo también. Acabo de descubrir que -w 1 hace que el registro vuelva a funcionar, lo que encaja con la hipótesis de @spion .

nodo 8.11.3
broma 23.4.0

Estoy encontrando este problema, o al menos un problema similar, cuando enciendo la coincidencia de expresiones regulares de archivo (presionando p en el modo watch ). Con all activado, los registros se imprimen como se esperaba. Tenga en cuenta que --verbose no está aquí.

Muestra 1

it.only(`should display a ErrorMessage component if state.validated is 'error'`, () => {
    const fV = shallow(<FormValidator/>);
    console.log('r1');
    console.error('r2');
    console.error('r3');
    ...

Con all viendo (imprime tanto log s como error s:

 PASS  src/components/__tests__/FormValidator.js
  ● Console

    console.log src/components/__tests__/FormValidator.js:56
      r1
    console.error src/components/__tests__/FormValidator.js:57
      r2
    console.error src/components/__tests__/FormValidator.js:58
      r3

En modo file regex (solo imprime los primeros log y no los error ):

Test Suites: 0 of 1 total
Tests:       0 total
Snapshots:   0 total
  console.log src/components/__tests__/FormValidator.js:56
    r1

 PASS  src/components/__tests__/FormValidator.jsidator.js:57
  FormValidator
    ○ skipped 3 tests
  FormValidator.displayMessage
    ✓ should display a ErrorMessage component if state.validated is 'error' (32ms)
    ○ skipped 5 tests
  FormValidator.render
    ○ skipped 1 test

Muestra 2

it.only(`should display a ErrorMessage component if state.validated is 'error'`, () => {
    const fV = shallow(<FormValidator/>);
    console.log('r1');
    console.error('r3');
    ...

all (imprime tanto log como error como se esperaba):

 PASS  src/components/__tests__/FormValidator.js
  ● Console

    console.log src/components/__tests__/FormValidator.js:56
      r1
    console.error src/components/__tests__/FormValidator.js:59
      r3

watch (no se imprime nada con el código anterior):

Snapshots:   0 total
 PASS  src/components/__tests__/FormValidator.jsator.js:56
  FormValidator
    ○ skipped 3 tests
  FormValidator.displayMessage
    ✓ should display a ErrorMessage component if state.validated is 'error' (20ms)
    ○ skipped 5 tests
  FormValidator.render
    ○ skipped 1 test

Test Suites: 1 passed, 1 total

Muestra 3

it.only(`should display a ErrorMessage component if state.validated is 'error'`, () => {
    const fV = shallow(<FormValidator/>);
    console.log('r1');
    console.log('r2');
    console.log('r3');
    console.log('r4');
    ...

all (imprime los cuatro log esperados):

 PASS  src/components/__tests__/FormValidator.js
  ● Console

    console.log src/components/__tests__/FormValidator.js:56
      r1
    console.log src/components/__tests__/FormValidator.js:57
      r2
    console.log src/components/__tests__/FormValidator.js:58
      r3
    console.log src/components/__tests__/FormValidator.js:59
      r4

watch (solo los dos primeros log se imprimen con el código anterior):

Snapshots:   0 total
  console.log src/components/__tests__/FormValidator.js:56
    r1

  console.log src/components/__tests__/FormValidator.js:57
    r2

 PASS  src/components/__tests__/FormValidator.jsator.js:58
  FormValidator
    ○ skipped 3 tests
  FormValidator.displayMessage
    ✓ should display a ErrorMessage component if state.validated is 'error' (31ms)
    ○ skipped 5 tests
  FormValidator.render
    ○ skipped 1 test

Test Suites: 1 passed, 1 total

No estoy seguro de lo que hice, pero creo que el orden de configuración es importante. Creo que algunas configuraciones pueden sobrescribirse entre sí. Obtengo tanto la prueba como la salida del registro.

node -v v8.11.2
jest -v 23.4.0

A continuación se muestra mi configuración de broma en mi paquete.json

```
"broma": {
"transformarIgnorarPatrones": [
"/node_modules/"
],
"archivos de configuración": [
"/src/setupTests.js"
],
"entorno de prueba": "jsdom",
"verboso": cierto,
"proyectos": [
{
"displayName": " COMPONENTES ",
"archivos de configuración": [
"/src/setupTests.js"
],
"modulePaths": ["/origen/"],
"coincidencia de prueba": ["/src/components/__tests__/ / .test.js"]},{"displayName": " REDUCTORES ","archivos de configuración": ["/src/setupTests.js"],"modulePaths": ["/origen/"],"coincidencia de prueba": ["/src/reductores/__pruebas__/ /.prueba.js"]
},
{
"displayName": " ACCIONES ",
"archivos de configuración": [
"/src/setupTests.js"
],
"modulePaths": ["/origen/"],
"coincidencia de prueba": ["/src/actions/__tests__/ */ .test.js"]
}
]
},

Here are my dependencies

"dependencias": {
"núcleo de babel": "^6.26.3",
"babel-jest": "^23.4.0",
"cargador de babel": "^7.1.5",
"babel-preset-env": "^1.7.0",
"babel-preset-react": "^6.24.1",
"dotenv": "^6.0.0",
"expreso": "^4.16.3",
"broma": "^23.4.0",
"reaccionar": "^16.4.1",
"reaccionar-dom": "^16.4.1",
"reaccionar-redux": "^5.0.7",
"guiones de reacción": "1.1.4",
"redux": "^4.0.0",
"tiempo de ejecución del regenerador": "^0.12.0"
},

output from just running jest

APROBAR REDUCTORES src/reducers/__tests__/comments/index.test.js
✓ maneja acciones del tipo SAVE_COMMENT (4ms)
✓ maneja la acción con tipo desconocido

PASAR ACCIONES src/actions/__tests__/index.test.js
guardarComentario
✓ tiene el tipo correcto (1ms)
✓ tiene la carga útil correcta (1ms)

APROBAR COMPONENTES src/components/__tests__/App/index.test.js
✓ Debería mostrar una lista de comentarios (5 ms)
✓ Debería mostrar un cuadro de comentarios (1 ms)

APROBAR COMPONENTES src/components/__tests__/CommentBox/index.test.js
✓ tiene un área de texto (23ms)
✓ tiene un botón (3ms)
el área de texto
✓ tiene un área de texto que los usuarios pueden escribir (9ms)
✓ cuando se envía el formulario, el área de texto se vacía (5 ms)

APROBAR COMPONENTES src/components/__tests__/CommentList/index.test.js
✓ crea un LI por comentario (32ms)

Conjuntos de pruebas: 5 aprobados, 5 en total
Pruebas: 11 aprobadas, 11 en total
Instantáneas: 0 en total
Tiempo: 3.79s
Ejecuté todas las suites de prueba en 3 proyectos.
consola.log src/components/__tests__/CommentList/index.test.js:26
0

consola.log src/components/__tests__/CommentList/index.test.js:27
Prueba

```

Este problema debe reabrirse, la salida de la consola también se tragó en broma, mi entorno es:

→ nodo --versión
v8.11.3

→ npx broma --versión
23.4.1

Probé con una configuración limpia y todo funciona bien.

// console.test.js
describe('jest should console output', () => {
  test('should console.log output be print', () => {
    console.log('console.log')
    expect(1).toBe(1)
  })

  test('should console.error output be print', () => {
    console.error('console.error')
    expect(1).toBe(1)
  })

  test('should console.info output be print', () => {
    console.info('console.info')
    expect(1).toBe(1)
  })
})

producción:

Entonces pensé que el problema podría estar relacionado con mi configuración de broma:

{
  "globals": {
    "API_SERVER_PLACEHOLDER": "SOME_API_ADDRESS"
  },
  "moduleFileExtensions": [
    "js",
    "jsx"
  ],
  "transform": {
    "^.+\\.jsx?$": "babel-jest"
  },
  "moduleNameMapper": {
    "\\.(css|less|sass|scss|png)$": "<rootDir>/__mocks__/styleMock.js",
    "\\.(gif|ttf|eot|svg|png)$": "<rootDir>/__mocks__/fileMock.js"
  }
}

Mi instinto me dijo que verificara verbose y después de eliminarlo todo está bien.

resumen

La versión 23.4.1 de jest con la configuración verbose establecida en true haría que la salida de la consola se absorbiera.

proponga cambiar el flujo de salida predeterminado a stdout : https://github.com/noscripter/jest/pull/1

¡¿Se ha vuelto a romper?! ¿Por qué esto sigue rompiéndose?

He trabajado alrededor de esto con:

expect(str).toBe("not this");

😬

Si tiene verbose: true en su paquete.json, o está ejecutando una broma con el indicador --verbose (¿o ambos?), intente eliminarlos.

No importa, eso ya no ayuda.

A menudo puedo ver la salida del registro durante una fracción de segundo _antes_ de que se imprima el resumen completo de la prueba en la consola. Tengo que console.log alrededor de 4-5 veces seguidas para que se muestre el resultado, e incluso entonces el último registro se cortará a la mitad (por ejemplo, al imprimir un objeto grande, solo la primera mitad se cortará). ser visible en el último registro impreso).

También es muy difícil de predecir. A veces uno o dos console.log serán suficientes, mientras que otras veces tengo que poner de tres a cinco seguidos. Tampoco importa si mis registros están en el código que estoy probando o en los propios casos de prueba.

Parece que broma está imprimiendo los registros, luego borrando la salida antes de imprimir el resumen completo de la prueba, cuando en realidad debería retener esos registros.

He aceptado en este punto que tengo que copiar y pegar los registros varias veces para verlos en la consola.

console.log funciona solo si ejecuta un archivo de prueba específico

yarn test <your-test-file-name>

p.ej
yarn test FormValidator

Para su información, ejecuto mi reproducción con el siguiente comando:

script -qfc 'yarn repro' /dev/null > raw.log

Eso es zsh: es posible que desee script -qfce en bash

y luego vi el registro con cat -vet raw.log . Aquí están los resultados:

^[[2K^[[1G^[[1myarn run v1.7.0^[[22m^M$
^[[2K^[[1G^[[2m$ jest --watch^[[22m^M$
^[[2J^[[3J^[[H^[[1m^[[2mDetermining test suites to run...^[[1m^[[22m^[[999D^[[K^M$
^M$
^[[1mTest Suites: ^[[22m0 of 2 total^M$
^[[1mTests:       ^[[22m0 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        0s, estimated 1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mlib/^[[22m^[[1mexample.spec.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m0 of 2 total^M$
^[[1mTests:       ^[[22m0 total^M$^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        0s, estimated 1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^[[0m^[[7m^[[1m^[[32m PASS ^[[39m^[[22m^[[27m^[[0m ^[[2mlib/^[[22m^[[1mexample.spec.js^[[22m^M$
^M$^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mlib/^[[22m^[[1mexample.spec.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m0 of 2 total^M$
^[[1mTests:       ^[[22m0 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        0s, estimated 1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A  foo^M$
^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mlib/^[[22m^[[1mexample.spec.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m0 of 2 total^M$
^[[1mTests:       ^[[22m0 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        0s, estimated 1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A    ^[[32mM-bM-^\M-^S^[[39m ^[[2madds 5 (4ms)^[[22m^M$
^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mlib/^[[22m^[[1mexample.spec.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m0 of 2 total^M$
^[[1mTests:       ^[[22m0 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        0s, estimated 1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M$
^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mlib/^[[22m^[[1mexample.spec.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m0 of 2 total^M$
^[[1mTests:       ^[[22m0 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        0s, estimated 1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mlib/^[[22m^[[1mexample.spec.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m0 of 2 total^M$
^[[1mTests:       ^[[22m0 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        0s, estimated 1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 of 2 total^M$
^[[1mTests:       ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        1s^[[999D^[[K  ^[[2mconsole.log^[[22m ^[[2mtests2/other-tests.js:5^[[22m^M$
    JEST^M$
^M$
^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^[[0m^[[7m^[[1m^[[32m PASS ^[[39m^[[22m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 of 2 total^M$
^[[1mTests:       ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A  bar^M$
^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 of 2 total^M$
^[[1mTests:       ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A    ^[[32mM-bM-^\M-^S^[[39m ^[[2malways is true (15ms)^[[22m^M$
^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 of 2 total^M$
^[[1mTests:       ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M$
^M$
^[[0m^[[7m^[[33m^[[1m RUNS ^[[22m^[[39m^[[27m^[[0m ^[[2mtests2/^[[22m^[[1mother-tests.js^[[22m^M$
^M$
^[[1mTest Suites: ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 of 2 total^M$
^[[1mTests:       ^[[22m^[[1m^[[32m1 passed^[[39m^[[22m, 1 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        1s^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^M^[[K^M^[[1A^[[999D^[[K^[[1mTest Suites: ^[[22m^[[1m^[[32m2 passed^[[39m^[[22m, 2 total^M$
^[[1mTests:       ^[[22m^[[1m^[[32m2 passed^[[39m^[[22m, 2 total^M$
^[[1mSnapshots:   ^[[22m0 total^M$
^[[1mTime:^[[22m        1.128s^M$
^[[2mRan all test suites^[[22m^[[2m related to changed files^[[22m^[[2m.^[[22m^M$
^M$
^[[1mWatch Usage^[[22m^M$
^[[2m M-bM-^@M-: Press ^[[22ma^[[2m to run all tests.^[[22m^M$
^[[2m M-bM-^@M-: Press ^[[22mf^[[2m to run only failed tests.^[[22m^M$
^[[2m M-bM-^@M-: Press^[[22m p ^[[2mto filter by a filename regex pattern.^[[22m^M$
^[[2m M-bM-^@M-: Press^[[22m t ^[[2mto filter by a test name regex pattern.^[[22m^M$
^[[2m M-bM-^@M-: Press^[[22m q ^[[2mto quit watch mode.^[[22m^M$
^[[2m M-bM-^@M-: Press ^[[22mEnter^[[2m to trigger a test run.^[[22m^M$

Espero que esto ayude. Parece que hay un error de conteo de códigos de control en un punto determinado.

El resultado final se ve así:

 PASS  lib/example.spec.js
  foo
    ✓ adds 5 (4ms)


 RUNS  tests2/other-tests.js

 PASS  tests2/other-tests.js2 total
  bar
    ✓ always is true (15ms)

Test Suites: 2 passed, 2 total
Tests:       2 passed, 2 total
Snapshots:   0 total
Time:        1.128s
Ran all test suites related to changed files.

Watch Usage
 › Press a to run all tests.
 › Press f to run only failed tests.
 › Press p to filter by a filename regex pattern.
 › Press t to filter by a test name regex pattern.
 › Press q to quit watch mode.
 › Press Enter to trigger a test run.

Falta la línea de la consola y el paso está escrito dos líneas demasiado abajo, probablemente debido a que no se tiene en cuenta el entrelazado con el archivo console.log cuando se sube para mostrar el "PASS".

editar: se agregó este resumen en esencia para facilitar la búsqueda y la manipulación: https://gist.github.com/spion/bbb34c5abc1230a37ad5f4f01336b8df

pd Para reproducir esto con el maestro actual, es posible que necesite algo de coerción. Cuando ingrese al modo de reloj, mantenga presionada la tecla "a" durante un tiempo; los registros de la consola comenzarán a salirse de control en algún momento (aparecerán en lugares y momentos inesperados)

También lo olvidé: estoy en ubuntu bionic, si eso hace alguna diferencia en el comportamiento del terminal WRT:

% lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.1 LTS
Release:    18.04
Codename:   bionic

Yo también. @spion ha clavado lo que estoy viendo. Solo lo descubrí porque tengo pruebas en código asíncrono lento. Veo la salida de la consola, luego se sobrescribe con el resumen de resultados de la prueba.

Por si sirve de algo, volví a [email protected] y al hacerlo se resuelven los problemas que tenía con la salida del resumen de la prueba que se escribía sobre la salida de la consola en [email protected] .

Actualización: creo que encontré un parche mínimo que hace algunos progresos, pero me tomó un tiempo comprender la interacción entre los reporteros de Jest y el generador de estado.

Jest monkey parchea los métodos de escritura de los flujos stderr y stdout del proceso con su propio escritor. Ese escritor escribe la salida de jest-cli Status.js, que contiene cosas como la cantidad de pruebas en curso, una barra de progreso, el tiempo transcurrido, etc.

Cada vez que hay una instrucción de escritura en ese flujo, esa instrucción se reemplaza con una instrucción de "eliminación" para el estado (aumentando usando códigos de control ANSI), la escritura original y una instrucción de "escribir el estado nuevamente". De ahí la ilusión de que el estado siempre está en la parte inferior de la pantalla, mientras que el texto se desplaza por encima.

(Por supuesto, es un poco más inteligente que eso: las escrituras se almacenan en el búfer y los datos almacenados en el búfer solo se escriben realmente una vez cada 100 ms junto con el estado)

Sin embargo, el ejecutor de pruebas en paralelo (usado en el modo de observación, que establece runInBand en falso) ejecuta a otros trabajadores. Esos trabajadores están configurados para "heredar" el flujo de stdio del proceso original. Desafortunadamente, eso no significa que hereden la versión parcheada que actualiza el estado. Si esas escrituras suceden, serán

1. agregado después del estado (el estado no se borra)
2. se borrará en el próximo borrado de estado (haciendo que el estado anterior también sea parcialmente visible, ya que el borrado no avanza lo suficiente como para borrar tanto la salida de la consola como la actualización de estado anterior)

Para asegurarse de que la versión parcheada reciba esas escrituras de tty, es necesario cambiar los flujos de procesos secundarios del modo "heredar" al modo "tubería". De esta forma, las salidas del proceso están disponibles como flujos en el proceso secundario en lugar de ir directamente a la salida estándar/stderr principal. También necesitamos canalizar manualmente los flujos:

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

La canalización manual de los flujos garantiza que el nodo llame a la escritura con parches de mono.

Esto rompe muchas pruebas de integración, sin embargo, se rompen principalmente debido a la falta de color. Haciendo

diff --git a/packages/jest-worker/src/worker.js b/packages/jest-worker/src/worker.js
index 5eee64af..5e5126eb 100644
--- a/packages/jest-worker/src/worker.js
+++ b/packages/jest-worker/src/worker.js
@@ -94,6 +94,8 @@ export default class {
         {
           cwd: process.cwd(),
           env: Object.assign({}, process.env, {
+            // $FlowFixMe: Does not know about isTTY
+            FORCE_COLOR: process.stdout.isTTY,
             JEST_WORKER_ID: this._options.workerId,
           }),
           // Suppress --debug / --inspect flags while preserving others (like --harmony).

reduce ese número significativamente, pero sigue siendo bastante alto:

Test Suites: 51 failed, 232 passed, 283 total
Tests:       149 failed, 7 skipped, 2706 passed, 2862 total
Snapshots:   19 failed, 17 obsolete, 996 passed, 1015 total

No creo que haya una forma de evitar esto: la salida cambia drásticamente, ya que muchas más escrituras terminan agregando la actualización de estado ahora.

editar: también existe el problema de que el nodo descarga el flujo de salida demasiado tarde en ciertas situaciones, mucho después de que el proceso secundario envió un mensaje de éxito al padre.

por favor corrija, esto realmente perjudica la productividad con broma

Bajar de categoría a [email protected] recupera la salida del registro de la consola. Sin embargo, tuve que configurar --env node para que funcionara. Por favor arregla esto.

Actualmente, parece que la única forma en que puedo hacer que el registro de la consola sea confiable es registrar lo mismo 3 o 4 veces seguidas. Jest solo bloqueará un cierto número de ellos. Todavía muy molesto.

¿Hay alguna actualización sobre esto? Estoy ejecutando jest 23.4.1 y el nodo 9.11.1 y, a veces, obtengo resultados de registro de la consola y otras veces no.

Dos años sin registros de consola me hicieron un mejor desarrollador. ¡Gracias equipo Jest!

No puedo creer que esto siga siendo un problema. ¿Por qué se cierra el tema?

Quiero decir, ¿quién querría depurar sus pruebas fallidas, verdad?

Como mencionó @jonogilmour , si registro algo una vez que no se muestra, pero al registrar cosas dos veces, obtendré uno de ellos para mostrar.

FWIW, la solución --verbose=false funciona para mí. En mi package.json :

"scripts": {
...
    "test": "react-scripts test --env=jsdom --verbose=false",

Algunas otras observaciones:

• Eliminar --env=jsdom (no es una opción para mi aplicación real) hizo que funcionara sin --verbose=false.
• Ejecutar la prueba directamente con broma (no a través de scripts de reacción) también hizo que funcionara.
• Cuando falla una aserción y obtiene mucho más resultado de broma, también se sobrescriben muchos más registros de la consola.

Hola chicos/chicas,
También me encontré con el famoso problema de registro de la consola jest al ejecutar pruebas en modo --watch.
La solución fue usar --watchAll en lugar de --watch. El resumen de las pruebas se volvió más feo, pero los registros se mostraron como se esperaba.

macOS Alta Sierra
nodo v8.11.3
broma: 23.6.0
ts-broma: 23.10.4

Para mi esta en beforeAll

  console.log = s => {
    process.stdout.write(s + "\n");
  };

y esto en el shell hizo el trabajo:

yarn test > test.log

Para mí, cambiar a mocha resolvió el problema. Es muy trivial cambiar, ya que el DSL es muy similar. Incluso puede seguir usando la biblioteca de expectativas de JEST: https://www.npmjs.com/package/expect

Es casi tan fácil como quitar jest e instalar mocha .

Editar: Spam o no, es la solución más fácil aquí.

Este problema es realmente doloroso, desearía que los mantenedores pudieran solucionarlo lo antes posible, porque Jest está destinado a aumentar la productividad, no al revés, ¿verdad?

De todos modos, lo siguiente es lo que estoy usando escribir ahora:

export const log = (s: any) => {
    console.log(s);
    console.log(s);
    console.log(s);
    process.stdout.write(s + "\n");
};

Tienes que enviar spam para salir.

Confirmado que --verbose=false soluciona el problema.

--verbose=false no me funciona con la versión 23.6.0

Dios mío, esto es un dolor: / noviembre de 2018

Vuelve a abrir este problema.

intente poner silent: false en jest.config.js ... en mi caso me sirvio

Ninguna de las soluciones funciona.
NodoJS: v8.12.0
Broma: v23.4.1

He estado usando Jest durante meses y es excelente y, aunque este error es _super molesto_, la solución alternativa que siempre he usado es hacer una afirmación no deseada, ya que se registrará en la consola cada vez.

Ejemplo, al intentar cerrar sesión en una llamada simulada:

expect('hello').toEqual(childFunc.mock.calls[0]) imprime:

No es ideal, pero hace el trabajo y me permite terminar de escribir mis pruebas.

Ejecutando Jest con una bandera --watch.
Broma versión 23.5.0
Versión de nodo 8.11.3

Este es un ejemplo decente de "demasiada magia" debajo del capó, y las consecuencias de eso cuando algo sale mal. No estoy convencido de que agrupar la salida de console.log valga un año y medio de las declaraciones de console.log que faltan. 😕

De acuerdo con lo anterior: esto no es del todo espectacular, pero hace que Jest sea doloroso de una manera que es completamente innecesaria.

Mi "solución alternativa" es que gran parte de la lógica usa log4js , por lo que estoy bien para donde inclino Jest al código del lado del servidor. Lamentablemente, tengo una gran cantidad de código del lado del cliente en el que normalmente copio y pego cuatro copias de cada console.log ya que finalmente aparece uno de ellos.

Usar expect para registrar información es una buena solución si está iniciando sesión desde dentro de una prueba (especialmente porque puede crear un fragmento con una palabra clave como logjest en su editor), pero eso se queda corto cada vez que necesita profundizar y registrar desde dentro de las funciones reales que están llamando sus pruebas.

¿Qué tal CI=true yarn run test ?

Perdón por lo que dije antes, pero funciona bien sin el título de los casos de prueba, es decir, sin la opción "--verbose", creo que --verbose hace algún tipo de formateo y reemplaza el flujo estándar.
Entonces, para mí llevo como 2 meses y todo está funcionando bien.
Y si alguien quiere usar esa opción, solo agréguela a sus comandos npm así: npm run test:integration -- --watchAll --verbose --coverage --etc

¿Pueden las personas con el problema probar [email protected] ? Incluye #6871

@ jamesta696 Hola, creo que necesita publicar ese tipo de preguntas en StackOverflow usando la etiqueta "broma" aquí porque las discusiones aquí son sobre "problemas", sin embargo, sé que alguien podría ayudarlo, pero el problema aquí podría cerrarse porque el tema principal no se está discutiendo.
Y por ahora, no puedo darte una respuesta a esa pregunta porque no estoy desarrollando algo para reaccionar y el frontend, tampoco soy miembro de jest, pero tratemos de seguir las reglas.

@SimenB Actualicé broma (a su versión mencionada) e intenté colocar algunas declaraciones de console.log en mi proyecto que tenía el problema. Hasta ahora, parece estar solucionado: aparecen todos console.log . Continuaré usándolo y te avisaré si me encuentro con el problema nuevamente.

FYI: Estaba (y todavía estoy) usando jest --watchAll

@tobyhinloopen Es genial ver una prueba del progreso que mencionó @SimenB .

eso es increíble @tobyhinloopen!

También puedo confirmar que [email protected] funciona bien y puede ver todos los registros de la consola sin --verbose=false.

También puedo confirmar que [email protected] funciona bien y puede ver todos los registros de la consola sin --verbose=false.

+1. también puede confirmar. Me alegra ver que esto está funcionando. ¡Buen trabajo, amigos de broma! 😄

Puedo confirmar también! Es como la Navidad. 🎅

😃

simplemente no necesita esperar hasta las actualizaciones de crear-reaccionar-aplicación

Estoy ejecutando la versión de broma 24.0.0 , pero todavía no puedo ver console.log o console.error . Me pregunto qué podría estar haciendo mal.

Asegúrate de que no se burlen

Esto es muy extraño. Parece que hay un problema con el manejo asíncrono. No consigo que se muestren los errores. Incluso si se ajusta a try/catch bloques, no puedo ver el error.

El parámetro generator es correcto con seguridad. Si elimino la llamada a la función asíncrona, entonces se registra correctamente. También devuelve la cadena correcta cuando está fuera del bucle for.

La versión Jest es 24.0.0 , el nodo es 10.5

@tiborsaas Su prueba probablemente habrá terminado antes de que se ejecute console.log .
Si desea esperar la iteración sobre changedGenerators , necesitará algo como

await Promise.all(changedGenerators.map(async (generator) => {/* ... */}))

Gracias por la respuesta, pero no es realmente el caso, algún error impide que se muestre el console.log . Hay otra función asíncrona que funciona bien con console.log si la llamo en la devolución de llamada forEach .

Editar: en realidad, mediante la depuración línea por línea, sé que el problema está en

const archives = await fs.readdir(archiveDir);

Sin embargo, este problema de broma se trata de registrar cosas. No quiero descarrilar la conversación.

Es posible que aún experimente un error, solo quería señalar (sin conocer su código exacto) que generalmente es una mala idea en general bifurcar un montón de promesas como esta sin esperarlas, porque podrían rechazarse después de que su prueba haya terminado: )

Estoy de acuerdo, pero quiero ejecutar las llamadas expect en forEach porque no sé por adelantado con cuántos cambios tengo que lidiar.

Desafortunadamente, el enfoque Promise.all no solucionó nada.

¿Utilizó map en lugar de forEach ? El punto es devolver una serie de promesas a Promise.all

@SimenB sí, lo sé.

Si hay un error, no puedo verlo.

@tiborsaas No está esperando que se complete Promise.all : use await Promise.all(...)

Hice eso también, mismo resultado. :(

¿Qué sucede si agrega await new Promise((resolve) => setTimeout(resolve, 1000)) debajo de su promise.all ?

¿Puedes abrir un nuevo número con una reproducción? Creo que el problema informado por el OP se solucionó mientras ve uno diferente (no importa si maneja la sincronización correctamente o no, aún debería ver la declaración de registro)

Sí, es realmente extraño, algo así como

test('stuff', () => {
    setTimeout(() => console.log('hi', 500));
})

por lo general todavía se imprime de alguna manera

Está usando una función de devolución de llamada como segundo argumento de Promise.all([...], callback) . Debería usar Promise.all([...]).then(callback) . Tal vez eso resuelva su problema, creo que el segundo argumento de .all se ignora y nunca se ejecuta (por lo que sus registros nunca se ejecutarán). @tiborsaas

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all

Sí, eso está mal, pero las declaraciones de registro aún deberían aparecer

@SimenB No, se ignora el segundo argumento.

> Promise.all([Promise.resolve(true)], () => console.log("hi")).then(console.log, console.error);
Promise {
  <pending>,
  domain: 
   Domain {
     domain: null,
     _events: { error: [Function: debugDomainError] },
     _eventsCount: 1,
     _maxListeners: undefined,
     members: [] } }
// output:
// [ true ]

Sí, me confundí con eso, lo siento. Gracias @tobyhinloopen

const lol = await Promise.all(versions); funcionó como se esperaba.

En ese caso, las declaraciones de registro pueden perderse ya que nunca se llama a la función, pero aún debería ver las declaraciones de registro en el caso original forEach ya que el nodo esperará a que se completen las promesas antes de salir del proceso. Entonces sigue siendo un error, aunque es un error del usuario.

PR: # 7731

Uso https://www.npmjs.com/package/debug para iniciar sesión. ¿Funcionaría eso con Jest?

No, no hasta que hagamos #6524.

Recomiendo burlarse debug en sus pruebas y usar console.log si quiere verlos

Como referencia, los mensajes de la consola pueden perderse si se imprimen después de que se hayan completado las pruebas, consulte los comentarios al final de #7731. Este podría ser el motivo de algunos, pero probablemente no de todos los mensajes de consola faltantes que se informan aquí.

El --verbose funcionó para mí. Antes de usar --verbose, algunos mensajes, pero no todos, se perdían. Estoy usando el nodo v10.15.3 y jest v21.2.1

Sigue siendo un problema para mí, los registros de la consola no se muestran en Jest

a pesar del último anuncio en el blog de que el problema finalmente se resolvió, el problema aún existe, los registros de mi consola a veces no vuelven a aparecer, estoy usando jest v24.8.0 .

Y mis trabajos muy bien 🤷‍♂️. Por favor, publique una reproducción que podamos investigar. No somos magos, no podemos ver su código que falla al registrar la salida.

en realidad, después de la investigación, los registros relacionados con las pruebas de API (como supertest) no funcionan. previsto :/

@thymikee Esto sucede de manera inconsistente, por lo que es muy difícil reproducirlo. ejemplo:
siguientes ejecuciones seleccionando un solo archivo de las pruebas (opción p)

• console.log('pantz') (funciona)
• cambiar console.log(myObject) (no funciona)
• cámbialo para que encaje (no funciona)
• cambiar a console.log('pantz') (no funciona)
• cambiar el ajuste a él (no funciona)
• reiniciar broma (no funciona)
• cambiarlo para que encaje (funcionando)

Ahora traté de replicar los mismos pasos y el resultado es inconsistente.

Proporcione un repositorio de muestra donde no funciona para que los muchachos de JEST puedan ayudar a depurar esto. @kresli

También hay muchas posibilidades de error de usuario, en su mayoría faltan await o console.log asíncronos.

Intentaré encontrar un momento para reproducir esto entonces. Hasta entonces, descubrí que mis registros se comen por los resultados, como puede ver a continuación. Antes de que aparezca FAIL, puede ver mis 2 registros allí. Y también vale la pena mencionar que solo se eliminan 2 registros. Si agrego 10 registros uno debajo del otro, se mostrarían 8. Creo que es un buen comienzo :)

Mientras tanto, si necesita una solución general que simplemente funcione, puede usar algo como winston para iniciar sesión tanto en el archivo como en la consola. Incluso si los mensajes de su consola no se muestran, se escriben en un archivo.

Con winston puede configurar lo que desea que se registre dónde y admite múltiples transportes y transportes que puede implementar usted mismo.

const logger = winston.createLogger({
  level: "verbose",
  format: winston.format.json(),
  defaultMeta: {},
  transports: [
    new winston.transports.Console(),
    new winston.transports.File({ filename: "combined.log" }),
  ],
});

logger.error(stuff)

Tal vez incluso puedas hacer algo sucio como anular console.* globalmente al registrador de winston.

@kresli ¿qué versión es tu broma? Eso parece un comportamiento v23

Esto me sigue pasando con jest v^24.6.0 y node v10.14.2 . ¿Alguna idea de por qué?

@yaelz Este es un problema obstinado que comúnmente es causado por un error del usuario, pero también tiene un historial de errores difíciles de reproducir.

Creo que realmente ayudaría a los contribuyentes a proporcionar un caso reproducible al proporcionar un repositorio de ejemplo o proporcionar otra forma de reproducir el problema.

¡Gracias por la rápida respuesta!
Eso será difícil porque el repositorio actual es privado en mi organización... Te avisaré si lo consigo :)

Esto me sigue pasando con jest v^24.6.0 y node v10.14.2 . ¿Alguna idea de por qué?

Recientemente actualicé algunas dependencias en un proyecto y no tengo ningún problema, lo enfrenté hace meses, pero creo que se resolvió en versiones más nuevas ...

¿Puedes compartir las versiones que estás usando ahora, cuando se resuelva?

El lunes 5 de agosto de 2019 a las 12:43 p. m. Norman Enmanuel [email protected]
escribió:

¡Gracias por la rápida respuesta!
Eso será difícil porque el repositorio actual es privado en mi organización... Dejaré
ya sabes si llego :)

Recientemente actualicé algunas dependencias en un proyecto y no tengo ninguna
Problema, me enfrenté a esto hace meses, pero se resolvió en versiones más nuevas.
creer...

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/facebook/jest/issues/3853?email_source=notifications&email_token=AB6F4PAE3CHUMEBP7IYXRPLQC7Y2DA5CNFSM4DPZ3JSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3RI3PY#issue,comentario-63-90381
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AB6F4PFXDSRHBW5CMTT2DKDQC7Y2DANCNFSM4DPZ3JSA
.

¿Puedes compartir las versiones que estás usando ahora, cuando se resuelva?

Por supuesto:

broma

^24.8.0

nodo -v

v10.16.0

Y estos son algunos scripts npm que utilizo para ejecutar tanto, e2e, integración, unidad y aceptación:

"scripts": {
  "test": "NODE_ENV=test npm run test:unit && npm run test:integration:both",
  "test:unit": "NODE_ENV=test jest --config test/jest.config.unit.js --detectOpenHandles",
  "test:integration": "NODE_ENV=test MOCK=false jest --config test/jest.config.integration.js --runInBand --detectOpenHandles",
  "test:integration:mock": "NODE_ENV=test MOCK=true jest --config test/jest.config.integration.js --runInBand --detectOpenHandles",
  "test:integration:both": "NODE_ENV=test npm run test:integration:mock -- --coverage; npm run db:migration:test; npm run test:integration -- --coverage;",
  "test:report": "open docs/test/report/index.html",
  "test:report:coverage": "open docs/test/coverage/lcov-report/index.html"
}

Y este es el jest.config:

"use strict";

module.exports = {
  "bail": true,
  "verbose": false,
  "collectCoverage": false,
  "expand": true,
  "testURL": "http://localhost:3000/",
  "coverageDirectory": "./docs/test/coverage",
  "testEnvironment": "node",
  "rootDir": "../",
  "setupFilesAfterEnv": [
    "./test/jest.setup.js"
  ],
  "jest.showCoverageOnLoad": true,
  "watchPathIgnorePatterns": ["node_modules"],
  "transform": {
    "^.+\\.js$": "babel-jest",
    '^.+\\.tsx?$': 'ts-jest',
  },
  "reporters": [
    "default",
    ["./node_modules/jest-html-reporter", {
      "pageTitle": "...",
      "outputPath": "./docs/test/report/index.html",
      "includeFailureMsg": true,
      "sort": "titleAsc",
      "dateFormat": "yyyy-mm-dd HH:MM:ss"
    }]
  ]
};

Espero eso ayude.

Intentaré encontrar un momento para reproducir esto entonces. Hasta entonces, descubrí que mis registros se comen por los resultados, como puede ver a continuación. Antes de que aparezca FAIL, puede ver mis 2 registros allí. Y también vale la pena mencionar que solo se eliminan 2 registros. Si agrego 10 registros uno debajo del otro, se mostrarían 8. Creo que es un buen comienzo :)

@kresli ¿Cuál es la barra de estado y la salida de tiempo que tiene aquí? Cuando ejecuto mi conjunto de pruebas, veo _RUN HARNESS test-harness/index.js_ y nada más hasta que todo se ejecuta. Luego veo mi mensaje console.log al final y la línea con _RUN HARNESS..._ cambia a _APROVECHAR...._

Actualización: ignore, resultó ser un problema en mi código

Todavía me enfrento a esto con el nodo v12.16.1, broma 25.5.4, mecanografiado 3.8.3 en MacOS. Probé las recomendaciones de usar --runInBand, deshabilitar/habilitar detallado, usar --silent=true, no ayudó.