7

Experimenting with concurrent execution I was wondering how to actually test it. The execution flow is of a side-effect nature and futures are created to wrap independent executions/processing.

Been searching for some good examples on how to properly unit test the following scenarios (foo and bar are the methods I wish to test):

scenario #1

def foo : Unit = {
    Future { doSomething }
    Future { doSomethingElse }
}

private def doSomething : Unit = serviceCall1
private def doSomethingElse : Unit = serviceCall2

Scenario motivation

foo immediately returns but invokes 2 futures which perform separate tasks (e.g. save analytics and store record to DB). These service calls can be mocked, but what I'm trying to test is that both these services are called once I wrap them in Futures

scenario #2

def bar : Unit = {
    val futureX = doAsyncX
    val futureY = doAsyncY
    for {
        x <- futureX
        y <- futureY
    } yield {
        noOp(x, y)
    }
}

Scenario motivation

Start with long running computations that can be executed concurrently (e.g. get the number of total visitors and get the frequently used User-Agent header to our web site). Combine the result in some other operation (which in this case Unit method that simply throws the values)

Note I'm familiar with actors and testing actors, but given the above code I wonder what should be the most suitable approach (refactoring included)

EDIT What I'm doing at the moment

implicit value context = ExecutionContext.fromExecutor(testExecutor)

def testExecutor = {
    new Executor {
        def execute(runnable : Runnable) = runnable.run
    }
}

This ExecutionContext implementation will not run the Future as a separate thread and the entire execution will be done in sequence. This kinda feels like a hack but based on Electric Monk answer, it seems like the other solution is more of the same.

Bivas
  • 1,484
  • 1
  • 11
  • 17
  • I deleted my answer, since it wasn't on topic, but you should really explain your problem more clearly. – Gabriele Petronella Aug 06 '14 at 21:34
  • @GabrielePetronella Thanks for the answer, and for the comment. I've edited my answer to (hopefully) better reflect my intentions. – Bivas Aug 06 '14 at 21:48
  • the only thing needed to be tested is that foo makes a call on the 2 methods doSomething and doSomethingElse ? you are looking for a proof that they are called and dont care what they do ? – Nimrod007 Aug 07 '14 at 20:15
  • @Nimrod007 correct. Scenario #1 tests that both services are called. Scenario #2 is more complex but `noOp` can be a mocked services that I wish to test if it was invoked as expected – Bivas Aug 07 '14 at 20:18
  • doSomething and doSomethingElse have to be private methods ? – Nimrod007 Aug 07 '14 at 20:23
  • @Nimrod007 They don't have to exist at all. It could also be `Future { serviceCall1 }` – Bivas Aug 07 '14 at 20:30
  • To make sure I understand it correctly: the fundamental issue here is that there's nothing (future, wait handle etc.) you can actually wait on? In other words, you can mock the actual "service calls" but there's nowhere to stick the verification test? – Tomer Gabel Aug 12 '14 at 11:10
  • @TomerGabel right, and I wouldn't like to use Thread.sleep() just to (falsely) wait for the futures and run the mock validation. What I'm doing now still feels wrong. – Bivas Aug 13 '14 at 12:13
  • 1
    Other than switching to actually returning Futures (probably the better option), the only alternatives I see are to use a sequential executor (as you've done), or to hack your mock services mark a condition you can await in the test code. – Tomer Gabel Aug 13 '14 at 13:00

3 Answers3

2

One solution would be to use a DeterministicExecutor. Not a scalaesque solution, but should so the trick.

Electric Monk
  • 2,192
  • 2
  • 23
  • 33
  • I've added the solution I'm currently testing with. Which looks like the same approach as `DeterministicExecutor`. Isn't there a more cleaner way to test async execution? – Bivas Aug 10 '14 at 19:03
  • How does this differ from calling `ExecutorService.shutdown` followed by `ExecutorService.awaitTermination`? – Tomer Gabel Aug 12 '14 at 11:12
1

If you are using ScalaTest, take a look at: http://doc.scalatest.org/2.0/index.html#org.scalatest.concurrent.Futures

Specs2 also has support for testing Futures: http://etorreborre.github.io/specs2/guide/org.specs2.guide.Matchers.html

Sudheer Aedama
  • 2,116
  • 2
  • 21
  • 39
  • I'm not testing `Future`s but async (concurrent) execution. Note that both these methods are `Unit` and don't return `Future` – Bivas Aug 06 '14 at 21:34
  • 3
    However, `Future { doSomething }` does return a `Future`. That is the point of Venkat's response. – Bob Dalgleish Aug 06 '14 at 21:40
  • @BobDalgleish but the method returns nothing (It can return `Future[Unit]` ) – Bivas Aug 06 '14 at 21:47
  • Okay, I'm starting to catch on now. In Scenario 1, you don't unit test `foo`, since it is essentially a shim or placeholder. Do you have unit tests for `doSomething` and `doSomethingElse`? If so, you can use the scalatest `Futures` to test `Future { doSomething }`, etc. – Bob Dalgleish Aug 06 '14 at 22:06
  • @BobDalgleish I wish to test `foo` and `bar`. `doSomething`, `doSomethingElse`, `doAsyncX`, `doAsyncY` and `noOp` have their own unit tests (which is easy to test with ScalaTest and Specs2) – Bivas Aug 06 '14 at 22:13
  • Again, you don't unit test `foo` as it is just a shim. If you are desperate to test it, you will need to isolate it from the definitions of `doSomething` and `doSomethingElse` so that you can mock them. Similarly for `bar`: create mocks of the procedures being called. – Bob Dalgleish Aug 06 '14 at 22:19
  • Think of them as service calls. Now that I mock them, the future is still wrapping a Unit call. FooTest should simply test that both are invoked (order is irrelevant) – Bivas Aug 07 '14 at 07:17
  • @Bivas: You cannot expect a method that returns Unit to return you Strings or Floats or Booleans if you wrap it in a Future. Your doSth returns Unit. If you want another type A, your doSth should return A to have Future[A] – Sudheer Aedama Aug 07 '14 at 15:53
  • @venkat who said I'm returning anything? I'm simply invoking 2 Unit method and wrap them in futures. If it they were services, I could simply mock them. But how do I replicate the test scenario now that I have futures wrapping every call. – Bivas Aug 07 '14 at 17:23
  • 1
    @Bivas Did you have a solution about your problem ? I would like to write integration tests on async method which return Unit. – Guillaume Aug 26 '15 at 07:40
  • @Guillaume I went with the hack between my solution and Electric Monk suggestion. See my edit to the original answer. – Bivas Aug 27 '15 at 10:15
0

ScalaTest 3.x supports asynchronous non-blocking testing.

Epicurist
  • 903
  • 11
  • 17