scala - react - ¿Cómo suprimir el registro de chispas en las pruebas unitarias?

pruebas unitarias react

Question

Así que gracias a los blogs fácilmente googleables probé:

import org.specs2.mutable.Specification

class SparkEngineSpecs extends Specification {
  sequential

  def setLogLevels(level: Level, loggers: Seq[String]): Map[String, Level] = loggers.map(loggerName => {
    val logger = Logger.getLogger(loggerName)
    val prevLevel = logger.getLevel
    logger.setLevel(level)
    loggerName -> prevLevel
  }).toMap

  setLogLevels(Level.WARN, Seq("spark", "org.eclipse.jetty", "akka"))

  val sc = new SparkContext(new SparkConf().setMaster("local").setAppName("Test Spark Engine"))

  // ... my unit tests

Pero desafortunadamente no funciona, aún obtengo mucha chispa, por ejemplo:

14/12/02 12:01:56 INFO MemoryStore: Block broadcast_4 of size 4184 dropped from memory (free 583461216)
14/12/02 12:01:56 INFO ContextCleaner: Cleaned broadcast 4
14/12/02 12:01:56 INFO ContextCleaner: Cleaned shuffle 4
14/12/02 12:01:56 INFO ShuffleBlockManager: Deleted all files for shuffle 4

Answer 1

Puede usar una configuración de Logback separada para las pruebas. Dependiendo de su entorno, es posible que solo necesite crear conf/logback-test.xml con algo que oculte los registros. Creo que esto debería hacer eso:

<configuration>
  <root level="debug">
  </root>
</configuration>

Según lo entiendo, esto captura todos los registros ( debug nivel y superior) y no les asigna ningún registrador, por lo que se descartan. Una mejor opción es configurar un registrador de archivos para ellos, por lo que aún puede acceder a los registros si lo desea.

Consulte http://logback.qos.ch/manual/configuration.html para obtener la documentación detallada.

Answer 2

Agregue el siguiente código en el archivo log4j.properties dentro del log4j.properties src/test/resources , cree el archivo / dir si no existe

# Change this to set Spark log level
log4j.logger.org.apache.spark=WARN

# Silence akka remoting
log4j.logger.Remoting=WARN

# Ignore messages below warning level from Jetty, because it''s a bit verbose
log4j.logger.org.eclipse.jetty=WARN

Cuando ejecuto mis pruebas de unidad (estoy usando JUnit y Maven), solo recibo registros de nivel WARN, en otras palabras, no hay más desorden con los registros de nivel INFO (aunque pueden ser útiles a veces para la depuración).

Espero que esto ayude.

Answer 3

Un poco tarde para la fiesta pero encontré esto en el código de ejemplo de la chispa :

def setStreamingLogLevels() {
    val log4jInitialized = Logger.getRootLogger.getAllAppenders.hasMoreElements
    if (!log4jInitialized) {
        // We first log something to initialize Spark''s default logging, then we override the
        // logging level.
        logInfo("Setting log level to [WARN] for streaming example." +
        " To override add a custom log4j.properties to the classpath.")
        Logger.getRootLogger.setLevel(Level.WARN)
    }
}

También encontré que con su código si llama a setLogLevels como a continuación, corta mucho fuera de mí.

setLogLevels(Level.WARN, Seq("spark", "org", "akka"))

Answer 4

Después de un tiempo de luchar con la salida del registro de Spark también, encontré una publicación de blog con una solución que me gustó especialmente.

Si usa slf4j, simplemente puede intercambiar la implementación de registro subyacente. Un buen canidate para el alcance de la prueba es slf4j-nop, que cuidadosamente toma la salida de registro y la coloca donde el sol nunca brilla.

Al usar Maven, puede agregar lo siguiente a la parte superior de su lista de dependencias:

<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-api</artifactId>
  <version>1.7.12</version>
  <scope>provided</scope>
</dependency>

<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-nop</artifactId>
  <version>1.7.12</version>
  <scope>test</scope>
</dependency>

Tenga en cuenta que puede ser importante tenerlo al principio de la lista de dependencias para asegurarse de que se usan las implementaciones dadas en lugar de las que pueden venir con otros paquetes (y que puede considerar excluir para mantener ordenada la ruta de su clase) y evitar conflictos inesperados).

Answer 5

En mi caso, una de mis propias bibliotecas incluyó logback-classic en la mezcla. Esto se materializó en una advertencia al comienzo:

SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/home/alex/.ivy2/cache/ch.qos.logback/logback-classic/jars/logback-classic-1.1.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/home/alex/.ivy2/cache/org.slf4j/slf4j-log4j12/jars/slf4j-log4j12-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]

Lo resolví excluyéndolo de la dependencia:

"com.mystuff" % "mylib" % "1.0.0" exclude("ch.qos.logback", "logback-classic")

Ahora podría agregar un archivo log4j.properties en test/resources que ahora Spark usa.