search

guchenbo / simple-build-tool

Automatically exported from code.google.com/p/simple-build-tool
Other
0 stars 0 forks source link

NoSuchElementException when using a custom TestFramework #133

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem (please be specific)?

I'm working on a new specification framework where the examples can be executed 
concurrently. I don't know where the issue comes from precisely but I observe 
these stacktraces from time to time:

[info] Total for specification ContextSpec
[info] Finished in 1 second, 156 ms
[info] 24 examples, 0 failure, 0 error
[info]
java.util.NoSuchElementException: head of empty list
        at scala.Nil$.head(List.scala:1365)
        at scala.Nil$.head(List.scala:1362)
        at scala.collection.mutable.ListBuffer$$anon$1.next(ListBuffer.scala:274)
        at scala.Iterator$class.foldLeft(Iterator.scala:520)
        at scala.collection.mutable.ListBuffer$$anon$1.foldLeft(ListBuffer.scala:266)
        at scala.Iterable$class.foldLeft(Iterable.scala:321)
        at scala.collection.mutable.ListBuffer.foldLeft(ListBuffer.scala:24)
        at scala.Iterable$class.$div$colon(Iterable.scala:338)
        at scala.collection.mutable.ListBuffer.$div$colon(ListBuffer.scala:24)
        at sbt.TestEvent$.apply(TestReportListener.scala:40)
        at sbt.TestRunner.runTest$1(TestFramework.scala:68)
        at sbt.TestRunner.run(TestFramework.scala:76)
        at sbt.TestFramework$$anonfun$10$$anonfun$apply$11.runTest$2(TestFramework.scala:194)
        at sbt.TestFramework$$anonfun$10$$anonfun$apply$11$$anonfun$apply$12.apply(TestFramework.scala:205)
        at sbt.TestFramework$$anonfun$10$$anonfun$apply$11$$anonfun$apply$12.apply(TestFramework.scala:205)
        at sbt.NamedTestTask.run(TestFramework.scala:92)
        at sbt.ScalaProject$$anonfun$sbt$ScalaProject$$toTask$1.apply(ScalaProject.scala:193)
        at sbt.ScalaProject$$anonfun$sbt$ScalaProject$$toTask$1.apply(ScalaProject.scala:193)
        at sbt.TaskManager$Task.invoke(TaskManager.scala:62)
        at sbt.impl.RunTask.doRun$1(RunTask.scala:77)
        at sbt.impl.RunTask.runTask(RunTask.scala:85)
        at sbt.impl.RunTask.sbt$impl$RunTask$$runIfNotRoot(RunTask.scala:60)
        at sbt.impl.RunTask$$anonfun$runTasksExceptRoot$2.apply(RunTask.scala:48)
        at sbt.impl.RunTask$$anonfun$runTasksExceptRoot$2.apply(RunTask.scala:48)
        at sbt.Distributor$Run$Worker$$anonfun$2.apply(ParallelRunner.scala:131)
        at sbt.Distributor$Run$Worker$$anonfun$2.apply(ParallelRunner.scala:131)
        at sbt.Control$.trapUnit(Control.scala:19)
        at sbt.Distributor$Run$Worker.run(ParallelRunner.scala:131)
[error] Could not run test org.specs2.specification.ContextSpec: 
java.util.NoSuchElementException: head of empty list

What is the expected behavior? 

No stacktrace.

What versions of the following are you using?

Java: 1.6
Scala: 2.8.1
sbt: 0.7.4, 0.7.5.RC0
Operating system: Windows

Please provide any additional information below.

Original issue reported on code.google.com by etorrebo...@gmail.com on 28 Nov 2010 at 11:56

GoogleCodeExporter commented 9 years ago 
https://github.com/harrah/test-interface/blob/master/src/org/scalatools/testing/
Runner2.java

"This Runner should run the suite in the calling (current) thread."

The model is that the client (sbt) handles the parallelization at the 
file/suite-level and the test framework runs things on the thread it is called 
on.  The test interface generally needs finer granularity and needs other work, 
but I don't have the resources to push this forward.

Original comment by dmhar...@gmail.com on 3 Dec 2010 at 3:35

GoogleCodeExporter commented 9 years ago 
Actually, it makes sense that for a given project, some "test classes" will be 
able to be executed concurrently while others cannot (because they access some 
kind of shared resources). This is why I think that it's good to be able to 
execute tests/examples concurrently for a given class. 

In the meantime it might be a good idea just to make the sbt code more robust 
by avoiding this exception to occur?

Original comment by etorrebo...@gmail.com on 7 Dec 2010 at 9:53

GoogleCodeExporter commented 9 years ago 
I found the proper way to avoid this issue by having the specification fully 
executed before being reported.

So I think that you can close this issue.

Original comment by etorrebo...@gmail.com on 15 Feb 2011 at 10:21

GoogleCodeExporter commented 9 years ago

Original comment by dmhar...@gmail.com on 22 Feb 2011 at 12:57