Use case

Espresso/EarlGrey takes care of synchronization within the testing framework, so that test authors do not have to explicitly wait/sleep in their tests. We are working on providing similar synchronization support for Flutter.

Espresso/EarlGrey currently use Driver extension API to talk into Flutter, and it currently exposes one wait API:

• waitUntilNoTransientCallbacks, that wait for no transient callbacks on SchedulerBinding.

And we'd like to expose more waiting conditions on the extension APIs. Not an exhaustive list but some of them are:

• Be able to wait for no pending frames scheduled in SchedulerBinding;
• Be able to wait for no pending async platform messages.

This list will grow as we understand more on the synchronization conditions that we shall wait on.

Proposal

Thanks to @Hixie @tvolkert @goderbauer 's guidance & suggestions (some of them are commented in this PR), this is the final proposal we arrived at:

1. A wait API that can support composable wait conditions; Users of this API will be able to specify the conditions that they care about.
2. For support for platform messages, limit the scope to testing only by creating a ServicesBinding that is used under testing env and provides a BinaryMessenger that can be used to track platform channel/messages.