Yes it does. This pattern was there from before so I've not really looked into switching it heaps. Not sure how much we care about blocking calls in the tests though (vs clarity of expression when describing things to test)?

Initial research suggests it isn't much nicer to use the scalatest Futures trait if that's what you mean? The trait is more verbose in your test code but I guess gives you better messages. I was thinking a nice way would be to model it on scalatest's OptionValues trait:

    implicit class RichFuture[T](f: Future[T]) {
        def value(implicit patience: Duration): T = // get the T or throw a nice test failed error
    }

Makes it very simple in the tests - you can just ask for the value of the Future. Either set a default timeout for the scope with an implicit, or pass a duration if you want to time it as part of the test. Would still be blocking though if done that way.

Be interested to hear your thoughts so let's catch up IRL.