Anyway, FlutterDriver is pretty frickin limited. Its like Selenium-RC without the XPath. Thank Turing that Simon Stewart and WebDriver came along and did a reverse takeover of Selenium. Selenium on my MacBookAir for perfected build toolchains can zip along at 3-5 tests as second with the browser open and you being able to roughly see what it is doing. Not 3-5 clicks a second, 3-5 tests a second.
FlutterDriver, by contrast is 5x slower. And even then that's only after the APK has been shoved into the emulator which can be minutes on my MBA. It feels to me like the FlutterDriver tests are being added to the APK being sent to the emulator, and then phoning home with minimal output of the run (not withstanding the ability to attach a debugger). There's no doubt that the better solution would be to open a socket to the host OS's test-runner process and chat back and forth about direction of the testing. If needs be, that shitty Selenium-RC COMETalike way , but there's no reason a whole bunch of telemetry couldn't be traded too if a BEEPlike protocol were developed. And the running process shouldn't be constrained to Dart. Some teams will want their test runner logic in another 3GL like Python.
Then there's the lack of reflection. I may agree that production apps may want to explicitly turn off reflection in order to be more efficient. But for test-automation purposes it is great (e.g. Gherkin), and it would be nice of there were some effort to publish patterns and set policy that would allow that way of working to be lasting.
Also, Apple are way ahead with a simulator for iOS and the XCode toolchain that's so much faster for testing considerations. Faster than a reliance on QEMU - at lest on busy 8GB machines. I bought a Mac Mini two days ago, mostly because of Flutter really, but general bloat too.