-
Notifications
You must be signed in to change notification settings - Fork 6k
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow this is awesome for two reasons:
- Expanding our integration test coverage.
- It's so well-documented, I learned a bunch from reading through it.
fx serve | ||
``` | ||
|
||
Start the Fuchsia emulator in a graphical environment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just curious, any reason not to have run_integration-test.sh handle this by dropping --skip-fuchsia-emu
from the next command?
More generally should we point this section at https://github.com/flutter/engine/blob/main/shell/platform/fuchsia/flutter/tests/integration/README.md to avoid maintaining these instructions in two places?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The script defaults to launching a --headless
emulator, which causes the test to fail.. I can add a flag to launch a graphical emulator (if this is what you meant by having the script handle it)
Good point on the documentation, I can update the README
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh shoot, I forgot about that. The Fuchsia tools tend to be graphical by default and support passing --headless
for headless environments, so it's poor design that I didn't do the same.
We can also detect if we're in a headless environment with [[ -z $DISPLAY ]]
I believe and use that to configure the emulator appropriately, but it might be better to be more explicit (graphical by default, pass --headless
for non-graphics). We can handle this in a follow-up PR though.
This PR adds a
touch-input-view
for use in thetouch-input-test
to validate touch input. The view will be attached to the test, and a touch event will be injected. The test asserts that a correct response is sent back from the view (the location of the touch as well as the name of the view).