0

I have a Scala Play application and one of the controllers fires a Future which does some logging. I have a simple call back function which executes when the Future completes.

I have written a test to check whether this logging happens. The rough logic is as follows:

feature{

  scenario{
    Given()
      // set up the call
    When()
      // make a FakeRequest via reverse routing - logging will done in a separate thread via a Future
    Then()
      Thread.sleep(50) // sleep to allow logging to finish
      // check if the logging has been done

The issue is the Thread.sleep. I have added that call in to block the main testing thread in order to give enough time to elapse for the Future which does the logging in a separate thread to complete before actually doing the checks to see if the logging has been done.

My question is whether there is a better way to do this? In reality if my application is running and the logging is taking an inordinate amount of time, then the main thread which governs the application will not terminate until the Future that does the logging in a separate thread finishes. So I don't see a problem of putting in the Thread call above to simulate that. But I just want to confirm if this is correct.

For me, there is absolutely no other way than to do this. If I try to replicate how the app behaves in reality with my test, then the main thread for the test should complete and terminate even though the future for the logging is still going on; there is no call back in the test and neither should there be.

  • I dropped my answer. Taking into account how you've commented it, I would suggest to: either make link available in tests or update some global variable about future results (for ex. amount of log messages published). – vvg Jan 08 '16 at 15:08
  • Can you use [CallingThreadDispatcher](http://doc.akka.io/docs/akka/snapshot/scala/testing.html#scala-callingthreaddispatcher) to make your tests synchronous? – jkinkead Jan 08 '16 at 15:11
  • @jkinkead, making the test synchronous would not be replicating how the application behaves (which is asynchronous). For me testing should not deviate from how the app should be behave in reality. –  Jan 08 '16 at 15:14
  • @rumoku, no I cannot use global variables etc... –  Jan 08 '16 at 15:14
  • Possible duplicate of [ScalaTest: Assert exceptions in failed futures (non-blocking)](http://stackoverflow.com/questions/20925352/scalatest-assert-exceptions-in-failed-futures-non-blocking) – Kevin Meredith Jan 08 '16 at 15:58

1 Answers1

2

Assuming you're using ScalaTest ; you can use whenReady construct ; which periodically inspects the passed future, until it is either ready or the configured timeout has been surpassed; see http://www.artima.com/docs-scalatest-2.0.M5/org/scalatest/concurrent/Futures.html

http://doc.scalatest.org/2.0/index.html#org.scalatest.concurrent.ScalaFutures

Vikas Pandya
  • 1,998
  • 1
  • 15
  • 32
  • 1
    No, I cannot. I do not have a handle on the future that does the logging. –  Jan 08 '16 at 15:18