TestProbe could break unit tests

[hoangong]

Hi,

it seems that TestProbe can only be called 5 times. after that it breaks the test. I have a unit test like this:

class DatasetViewTest extends TestKit(ActorSystem("test")) with FlatSpecLike with Matchers {

  trait TestContext {
    val controller = TestProbe()
  }

  it should "1" in new TestContext  {}
  it should "2" in new TestContext  {}
  it should "3" in new TestContext  {}
  it should "4" in new TestContext  {}
  it should "5" in new TestContext  {}
  it should "6" in new TestContext  {}
  it should "7" in new TestContext  {}
  it should "8" in new TestContext  {}
  it should "9" in new TestContext  {}
  it should "10" in new TestContext {}
}

Only test 1-5 could run. then it stops with this error:

[error] (management / Test / testOnly) org.scalajs.testcommon.RPCCore$ClosedException: org.scalajs.jsenv.ComJSEnv$ComClosedException: JSCom has been closed

I could put val controller = TestProbe() outsite scope of TestContext as a workaround, but some cases I have to redeclare it.

Thanks.

[andreaTP]

Thanks for the report! Not sure what is going on but I will try to reproduce and understand. TestProbe is hacked around, and I guess that the internally used ManagedEventLoop is polluting user's tests: https://github.com/akka-js/akka.js/blob/master/akka-js-typed-testkit/js/src/main/scala/akka/actor/testkit/typed/internal/TestProbeImpl.scala#L197

We need to find a solution that doesn't depend on it, not sure how though ...

[tarsa]

What about some asynchronous TestProbe version (compiled for both Scala and Scala.js for tests portability)? ScalaTest 3 has support for asynchronous tests https://www.scalatest.org/release_notes/3.0.0 so one can write tests using Futures and no blocking at all. New Scala revisions have built-in support for async/await syntax https://github.com/scala/scala/pull/8816 so writing portable tests (full of Futures) should be reasonably convenient.

[andreaTP]

The problem here is that most tests are cross-compiled, so one would need to port to async tests the Akka codebase first, in order to benefit from them here, and, well, is going to be quite some work I believe

[tarsa]

Getting Akka team to make all the tests (i.e. in Akka test suite) non-blocking would be tough, indeed. Too bad Akka.js doesn't get much love from Akka team. However, I'm talking more about Akka.js users than Akka.js itself. Akka (or Akka.js) users don't depend on Akka test suite in their apps, instead they depend on Akka (or Akka.js) testkits and production (i.e. non test related) code of Akka. With async test probes (typed and untyped) one could completely avoid messing with JavaScript event loop and therefore rule out such interferences from debugging investigations. Is that correct?

[andreaTP]

Yes, is entirely possible to write TestProbes in userland and get them working in async ScalaTest suites.