Perché scalatest mescola l'output?

Question

corro la mia ScalaTest da SBT, e l'uscita si confonde - stampe ScalaTest tutta la prova di funzionamento, e commenti a loro, e da qualche parte nel mezzo esso stampa le statistiche:

> test 
[info] Compiling 1 Scala source to /home/platon/Tor/scala-dojo-02/target/scala-2.9.1/classes... 
[info] FunsWithListsTests: 
[info] - should return list of labels 
[info] - should return the average rating of games belonging to Zenga 
[info] - should return the total ratings of all games 
[info] - should return the total ratings of EA games *** FAILED *** 
[info] 0 did not equal 170 (FunsWithListsTests.scala:35) 
[error] Failed: : Total 8, Failed 5, Errors 0, Passed 3, Skipped 0 
[info] - should increase all games rating by 10 *** FAILED *** 
[error] Failed tests: 
[error]  dojo.FunsWithListsTests 
[info] List() did not equal List(Game(Activision,40), Game(Zenga,70), Game(Zenga,20), Game(EA,70), Game(EA,120)) (FunsWithListsTests.scala:40) 
[info] - should decrease all Zenga games rating by 10 *** FAILED *** 
[info] List() did not equal List(Game(Activision,30), Game(Zenga,50), Game(Zenga,0), Game(EA,60), Game(EA,110)) (FunsWithListsTests.scala:45) 
[info] - should create function to find Activision games *** FAILED *** 
[info] List(Game(Activision,30), Game(Zenga,60), Game(Zenga,10), Game(EA,60), Game(EA,110)) did not equal List(Game(Activision,30)) (FunsWithListsTests.scala:50) 
[info] - should return a List of tuples consisting of game label and game *** FAILED *** 
[info] List() did not equal List((ACTIVISION,Game(Activision,30)), (ZENGA,Game(Zenga,60)), (ZENGA,Game(Zenga,10)), (EA,Game(EA,60)), (EA,Game(EA,110))) (FunsWithListsTests.scala:56) 
[error] {file:/home/platon/Tor/scala-dojo-02/}default-940f03/test:test: Tests unsuccessful 
[error] Total time: 1 s, completed Mar 20, 2012 9:27:13 AM 

Sembra che se io accumulerebbe un gran numero di test, la ricerca di quelle statistiche e dei test falliti diventerebbe un dolore.

C'è un modo per risolvere questo problema?

Answer 1

Mi sembra che in questo caso SBT esegua di default i test in parallelo, allo stesso modo di maven-surefire-plugin.

Come si è spiegato in ScalaTest wiki, questo può essere risolto:

Disabilita l'esecuzione in parallelo di test Per impostazione predefinita, SBT corre tutte le attività in parallelo. Poiché ogni test è associato a un'attività, i test vengono eseguiti anche in parallelo per impostazione predefinita. Per disabilitare l'esecuzione parallela di prove:

parallelExecution in Test: = false

Answer 2

hanno lo stesso problema e risolto salvando i log in file separati. Non ideale, ma buono per l'IC, specialmente in caso di test di integrazione di lunga durata. Come ho fatto:

1. Creare una directory speciale per i registri (ad esempio, alla fine del build.sbt):

   lazy val logDirectory = taskKey[File]("A directory for logs") 
   logDirectory := { 
       val r = target.value/"logs" 
       IO.createDirectory(r) 
       r 
   } 
   

2. [Eventualmente] specificare un file per fornire informazioni sintetiche in un progetto:

   testOptions in test += Tests.Argument(
       TestFrameworks.ScalaTest, "-fW", (logDirectory.value/"summary.log").toString 
   ) 
   

   W disabilita colori

3. Creare un gruppo per ciascun test. Ogni gruppo deve essere eseguito un test in una JVM biforcuta con argomenti particolari:

   testGrouping in test := testGrouping.value.flatMap { group => 
       group.tests.map { suite => 
       val fileName = { 
        // foo.bar.baz.TestSuite -> f.b.b.TestSuite 
        val parts = suite.name.split('.') 
        (parts.init.map(_.substring(0, 1)) :+ parts.last).mkString(".") 
       } 
   
       val forkOptions = ForkOptions(
        bootJars = Nil, 
        javaHome = javaHome.value, 
        connectInput = connectInput.value, 
        outputStrategy = outputStrategy.value, 
        runJVMOptions = javaOptions.value ++ Seq(
        "-Dour.logging.appender=FILE", 
        s"-Dour.logging.dir=${logDirectory.value/fileName}" 
       ), 
        workingDirectory = Some(baseDirectory.value), 
        envVars = envVars.value 
       ) 
   
       group.copy(
        name = suite.name, 
        runPolicy = Tests.SubProcess(forkOptions), 
        tests = Seq(suite) 
       ) 
       } 
   } 
   

   nota, siamo in grado di dire al logback, dove salviamo i nostri log attraverso our.logging.appender e our.logging.dir

4. Creare una configurazione per l'accesso (test/risorse/logback-test.xml):

   <?xml version="1.0" encoding="UTF-8"?> 
   <configuration> 
       <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> 
        <target>System.out</target> 
        <encoder> 
         <pattern>%date{yyyy-MM-dd HH:mm:ss} %-5level [%thread] %logger{26} - %msg%n</pattern> 
        </encoder> 
       </appender> 
   
       <appender name="FILE" class="ch.qos.logback.core.FileAppender"> 
        <file>${our.logging.dir}/test.log</file> 
        <append>false</append> 
        <encoder> 
         <pattern>%date{yyyy-MM-dd HH:mm:ss.SSS} %-5level [%thread] %logger{26} - %msg%n</pattern> 
        </encoder> 
       </appender> 
   
       <root level="TRACE"> 
        <appender-ref ref="${our.logging.appender}"/> 
       </root> 
   </configuration> 
   

Questo è tutto.