Just my initial impression is that this has a lot of waiting/mocking magic that is more akin to an integration test than a unit test.

Maybe instead of assuming we have to use the thread/event queue, we cheat and just refactor DAGScheduler to be easier to test?

E.g. keep DAGScheduler as having an event queue, and all of its public methods post messages to the event queue, but then move the internal implementation into a separate class that could be easily tested. E.g.:

```scala
class DAGScheduler {
  val eventQueue = ...
  val impl = new DAGSchedulerImpl(...)
  def foo() = { eventQueue.adafterSubmitd(new FooCommand) }
    private def run() {
      while (true) {
        val m = eventQueue.poll
        m match {
          case FooCommand => impl.foo()
        }
      }
   }
}
class DAGSchedulerImpl(...) {
   def foo() = { ... }
}
```

Then this DAGSchedulerTest can poke DAGSchedulerImpl directly and not have to worry about waiting around for the command to flush through the event queue and cause affects that can be asserted against.