Jest: Ocultar el registro de la consola para pasar las pruebas y mostrarlo en caso de fallas

Puede escribir un reportero personalizado. Cc @aaronabramov

Aquí hay un ejemplo de nuestras pruebas: https://github.com/facebook/jest/blob/master/integration_tests/custom_reporters/reporters/test_reporter.js.

Hola, gracias por la información útil.

Sin embargo, intenté escribir un reportero personalizado y encontré algunos inconvenientes:

• No hay una manera fácil de heredar toda la funcionalidad del reportero predeterminado (salida de prueba informativa, etc.) y prefiero no volver a implementarlo todo desde cero.
• Cuando incluyo el reportero predeterminado en mi configuración, paso --silent en la CLI (para que el reportero predeterminado oculte el registro de la consola) y agrego mi reportero personalizado a mi configuración, no veo una forma fácil en mi reportero personalizado para imprimir el registro. Parece que debido a la opción --silent , las clases de reportero ya no tienen acceso a la consola almacenada en búfer.

Debido a esto, me gustaría proponer un parche a Jest que introducirá un valor de configuración para mostrar la consola solo en las pruebas fallidas. ¿Considerarías un parche así?

Esto obviamente necesita pruebas y deberá verificar un valor de configuración, pero aquí está la idea general (que está funcionando):

diff --git a/packages/jest-cli/src/reporters/default_reporter.js b/packages/jest-cli/src/reporters/default_reporter.js
index 08d4a9f2..adedbdd3 100644
--- a/packages/jest-cli/src/reporters/default_reporter.js
+++ b/packages/jest-cli/src/reporters/default_reporter.js
@@ -176,7 +176,8 @@ class DefaultReporter extends BaseReporter {
       this.log(getResultHeader(result, config));

       const consoleBuffer = result.console;
-      if (consoleBuffer && consoleBuffer.length) {
+      const testFailed = result.numFailingTests > 0;
+      if (testFailed && consoleBuffer && consoleBuffer.length) {
         this.log(
           '  ' +
             TITLE_BULLET +

De hecho, me gusta esta idea, pero hay muchas cosas que debemos tener en cuenta.

necesitamos agregar algo de información sobre la salida oculta

PASS __tests__/my_test.js (hidden output)

también deberíamos deshabilitarlo al ejecutar algunas pruebas o una sola prueba (supongo que prácticamente solo habilitarlo para una ejecución de prueba completa)

@cpojer , ¿tienes alguna idea sobre esto?

Creo que este comportamiento es confuso y preferiría que Jest sea consistente en lo que genera por prueba, independientemente del estado.

@cpojer para mí, es confuso intentar encontrar mensajes de consola relacionados con mi prueba que falló: / Si puede sugerir mejores formas de lograrlo, hágalo.

Como compromiso, ¿aceptaría un parche que exponga DefaultReporter en jest.js para que pueda extenderlo? De lo contrario, tendría que copiar y pegar el mundo para implementar esta función en un reportero personalizado.

Así es como se ve mi salida de prueba:

No puedo deshacerme de las advertencias debido a https://github.com/facebook/flow/issues/4673 , y afortunadamente solo hay un par de mensajes de registro, pero si quiero agregar más registros, empeorará mucho .

Secundo que recibes muchas advertencias y errores de dependencias, hace que sea mucho más difícil encontrar pruebas fallidas. Sería bueno tener una bandera que pudieras pasar y que solo devolviera la lista de pruebas fallidas.

De acuerdo, tener una bandera para ocultar la salida de la consola para la prueba PASA y dejarla para la prueba FALLIDA sería una gran adición para hacer que la salida de la prueba sea más legible

Yo estaría de acuerdo. Actualmente estoy trabajando en un proyecto con un gran grupo de pruebas y el resultado de pasar las pruebas hace que el flujo de trabajo sea más difícil al depurar.

Se acordó la bandera que oculta la salida de la consola para las pruebas PASS.

PASS __tests__/my_test.js (hidden output)

¿Podemos reconsiderar esta adición por casualidad?

Ahora tenemos una forma de ejecutar pruebas fallidas, que deberían cubrir este caso de uso. Ver # 4886 (disponible en broma 22)

Ahora tenemos una forma de ejecutar pruebas fallidas, que deberían cubrir este caso de uso.

Cubre solo parcialmente el estuche. Por ejemplo, si 5 de cada 100 pruebas fallan en una suite con mucho registro, puede volver a ejecutar solo las pruebas que fallaron para entender la salida de la consola. Sin embargo, si estuviera ocultando el registro para pasar las pruebas todo el tiempo, no habría tenido que volver a ejecutar las pruebas.

Además, volver a ejecutar solo las pruebas fallidas tiene la desventaja de que no detectará ninguna nueva falla de prueba introducida por las ediciones de código.

Si el equipo central no desea implementar esta función, ¿alguien podría considerar mi propuesta de compromiso? Esta propuesta me permitiría escribir más fácilmente un reportero personalizado para implementar el ocultamiento de la consola. Puedo hacer el parche, pero no quiero enviar una solicitud de extracción si no se acepta.

@ kumar303 por favor envíe un PR, parece bastante

@ kumar303 ¿terminaste enviando un PR? Me gustaría tener esto también.

Todavía tengo la intención de enviar uno, pero no he podido encontrar tiempo entre mis otras prioridades laborales. Si alguien más se me adelanta, ¡avíseme para que pueda ayudar a probarlo!

Mi idea era exportar DefaultReporter de jest.js para que un reportero personalizado pudiera extenderlo. Estaba pensando en comenzar cambiando esta línea a algo más como:

const testFailed = result.numFailingTests > 0;
if (testFailed && consoleBuffer && consoleBuffer.length) {
  // Log console output
}

Estoy seguro de que necesitaría más ajustes después de eso.

@ kumar303 ¿Cómo puedo agregar su código a mi configuración de broma?

También me interesa esto. Siguiendo la idea de @ kumar303 pude escribir un reportero personalizado que extiende default_reporter con bastante facilidad (aunque frágil, ya que lo estoy importando directamente desde jest-cli/build/reporters/default_reporter ), y luego transformar result.console como mejor me parezca (en este caso dejo que el usuario establezca un nivel de registro mínimo).

Funciona bien, excepto por una cosa: cuando se ejecuta una sola prueba, los mensajes de la consola no se almacenan en búfer. Esto se menciona aquí: https://github.com/facebook/jest/issues/2080

Entonces, en estos escenarios, no hay capacidad para influir en la salida de la consola desde un reportero personalizado. Así que no creo que la sugerencia original de @thymikee de usar un reportero personalizado para administrar la salida de la consola funcione de manera universal, a menos que también podamos tener alguna forma de forzar a Jest para que siempre almacene la salida de la consola en búfer.

Feliz de exponer a nuestro reportero predeterminado de una manera más limpia.

¿Le importaría abrir un tema aparte sobre forzar el almacenamiento en búfer de console.logs? Debe ser consistente

¿Existe una desventaja significativa de tener una variable de configuración global como showLogsForFailedTests: true ? El valor predeterminado no cambia nada de cómo funciona Jest actualmente y el valor de false haría que leer las pruebas sea mucho más agradable.

¿Este problema está cerrado porque se hizo algo para solucionarlo o está cerrado porque más de 30 personas están imaginando que tienen un problema con Jest que en realidad no tienen?

chico, pensé que esto es más o menos un enfoque estándar para mostrar solo el registro fallido por broma ... ¿sigue siendo un problema?

Necesito esto. Realmente perturba.

Para su información: hemos implementado con éxito la idea de @ kumar303 en un reportero personalizado basado en el reportero predeterminado de Jest aquí: https://github.com/mozilla/addons-frontend/blob/e1606743d79e779b1902399685f35a90aa6b9ab9/tests/jest-reporters/fingers-crossed. js

• Sin este reportero: https://travis-ci.org/mozilla/addons-frontend/jobs/413610593
• Con este reportero: https://travis-ci.org/mozilla/addons-frontend/jobs/413753679

@willdurand Probé con tu reportero. No estoy seguro de qué pude haber hecho mal, ya que todo lo que hice fue seleccionar ese archivo como reportero. Todo lo que hizo fue evitar que esto se mostrara al final de las pruebas:

Test Suites: 48 passed, 48 total
Tests:       78 passed, 78 total
Snapshots:   73 passed, 73 total

Todos los registros durante las pruebas todavía aparecían.

¿Quizás lo ejecutó solo para una prueba? Ver mi comentario anterior y
informe de error asociado. No es posible capturar registros con un reportero
cuando solo se ejecuta una prueba, este es el verdadero punto de fricción.

El miércoles 8 de agosto de 2018 a las 7:08 p. M., Jazoom [email protected] escribió:

@willdurand https://github.com/willdurand Probé con tu reportero. soy
no estoy seguro de qué podría haber hecho mal, ya que todo lo que hice fue seleccionar ese archivo
como el reportero. Todo lo que hizo fue evitar que esto se mostrara al final de la
pruebas:

Suites de pruebas: 48 aprobadas, 48 ​​en total
Pruebas: 78 aprobadas, 78 en total
Instantáneas: 73 aprobadas, 73 en total

Todos los registros durante las pruebas todavía aparecían.

-
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/4156#issuecomment-411582223 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAi-gO9_uEJPO4xnhkpfGore_hEX81fUks5uO29bgaJpZM4OnBQQ
.

@jamietre Lo ejecuté exactamente con el mismo comando que usé para la prueba que ejecutó 48 suites.

Editar: para aclarar, ejecuté el mismo comando dos veces. La única diferencia con el reportero personalizado fue que no imprimió este resumen al final:

Test Suites: 48 passed, 48 total
Tests:       78 passed, 78 total
Snapshots:   73 passed, 73 total

@jazoom el reportero no tendrá ningún efecto si tiene verbose: true en su configuración. Intente configurarlo en false .

@jamietre estoy de acuerdo. Es un comportamiento extraño que una sola ejecución de prueba no capture ni muestre ningún resultado de la consola (https://github.com/facebook/jest/issues/6441).

Tampoco es útil cómo Jest no agrupa la salida de la consola por prueba (https://github.com/facebook/jest/issues/2080). Un reportero personalizado solo puede mostrar el resultado de la suite (es decir, un archivo de prueba), no una prueba específica que falla.

@jazoom también asegúrese de reiniciar completamente Jest después de instalar o cambiar el reporter. Esto puede no ser obvio ya que jest reconocerá los cambios en otros archivos de origen mientras se ejecuta (pero no a los reporteros).

@ kumar303 no está configurado para ser detallado

¿Qué quieres decir con "reiniciar completamente"? Es solo un script que se ejecuta.

¿Qué quieres decir con "reiniciar completamente"?

Quise decir que si estás en el modo de reloj de broma, debes salir.

Bueno. No uso el modo reloj.

ah, sí, de hecho. No me di cuenta de eso, pero por algunas razones, Jest no muestra el resumen final en la parte inferior, una vez que se han ejecutado todas las suites de prueba.

Supongo que es porque extendemos el DefaultReporter y no el SummaryReporter , tal vez ..

@willdurand Probé su configuración que oculta con éxito los registros. Sin embargo, la terminal ya no se borra (registros anteriores) y todos los registros apilan los que están debajo de los demás.

Nota: Con solo exportar la clase DefaultReporter , recurro al registro predeterminado, pero los registros también se apilan

Jugué un poco con FingersCrossedReporter de @ kumar303 / @willdurand
Sin embargo, como señalaron otros, no imprime el resumen de la prueba al final de las pruebas. Esto se debe a (creo) que la configuración predeterminada de Jest usa dos reporteros: DefaultReporter y SummaryReporter.
Ahora no puedo importar directamente el SummaryReporter en mi configuración de broma, ya que se exporta por defecto y eso no parece importable. Lo he solucionado reexportándolo desde otro archivo.

//summary-reporter.js
const SummaryReporter = require('@jest/reporters/build/summary_reporter')
  .default;
module.exports = SummaryReporter;

//log-on-fail-reporter.js
Content: https://gist.github.com/GeeWee/71db0d9911b4a087e4b2486386168b05
Same as reporter above, but with updated import paths for the new jest structure

Configuración de broma

    "reporters": [
      "<rootDir>/src/test-reporters/log-on-fail-reporter.js",
      "<rootDir>/src/test-reporters/summary-reporter.js"
    ],

Editar: Después de jugar un poco con él, veo que esto registra todo el bloque de descripción, si una sola prueba falla.

arreglaremos el soporte para la exportación predeterminada para jest 25.

tu tambien puedes hacer

//summary-reporter.js
const {SummaryReporter} = require('@jest/reporters')
module.exports = SummaryReporter;

Sin embargo, es posible que deseemos agregar archivos @jest/reporters/SummaryReporter etc, por lo que no necesita el archivo js intermediario ... ¿Quiere abrir una solicitud de función separada para eso?

¿Por qué está cerrada esta solicitud de función?
Parece que a muchas personas les parece razonable tener esta función incluida en una broma lista para usar. Al menos como opción de configuración.
¿Puedes @ kumar303 abrirlo de nuevo?

¿Puedes @ kumar303 abrirlo de nuevo?

Je. No, no tengo acceso. Este fue el motivo del cierre: https://github.com/facebook/jest/issues/4156#issuecomment -324638718 Estoy de acuerdo en que es una característica esencial. Me sorprende cómo los desarrolladores de bromas centrales pueden vivir sin él, pero tal vez no escriban código con errores, por lo que no necesitan registros.

Vuelva a abrir. Nosotros también necesitamos esto.

¿Por qué esto no es posible todavía?

Me parece una funcionalidad obvia. La mayoría de nuestras pruebas producen al menos una página de texto de consola cada una, es increíblemente molesto tener que recorrerlas para encontrar las pruebas fallidas.

No conozco otra forma de registrar mi apoyo a este comportamiento que dejar un comentario. Sé que 👍 y similares son menos útiles, así que esto es lo mejor que siento que puedo hacer. ¡Gracias por todo de todos los involucrados! Seguí todos los hilos y espero con ansias esto cada vez que las personas tienen ciclos para conseguirles lo que quieren jajaja.

El hecho de que esta función no se haya implementado durante casi tres años, cuando es tan necesario, es un poco extraño.

Basándome en fragmentos que encontré en Internet, se me ocurrió una configuración global para esto; ver https://stackoverflow.com/questions/58936650/javascript-jest-how-to-show-logs-from-test-case-only-when-test-fails/61909588#61909588

Ojalá esto ayude a alguien.

Es posible que desee echar un vistazo a https://github.com/AtakamaLLC/capio para la captura asíncrona.

Vuelva a abrir e impleméntelo como una configuración opcional.
Lo haría yo mismo si hubiera una posibilidad realista de que se aceptara un PR.
En mi opinión, escribir un reportero personalizado para esta "pequeña" solicitud de función sería una sobrecarga de mantenimiento insostenible.

Aunque esta solicitud de función no es "limpia" ni "coherente", muchas personas la necesitan.