2e2042ff8e
This PR makes no _behavioral_ changes to executed code, and instead focuses on organization and naming: 1. Almost[^1] anything named `external_ui` is renamed `external_textures` 1. Extended the README to explain the intent of the test, as well as how to run it 1. Renamed `main.dart` and `main_test.dart` to `frame_rate_main.dart` and `frame_rate_test.dart` (we'll add more) 1. Did some refactoring of the test to make it more obvious what is being asserted (i.e. `widgetBuilds` and friends) Given how complex (and in-flux) this directory is, I'm also requesting either John, Jonah or I review any changes. [^1]: Except the name of the `.ci.yaml` task, i.e. `name: Linux_pixel_7pro external_ui_integration_test` because I'm apparently not able to change that without creating a new task as `bringup: true` and playing a bit of a dance. Maybe that's worth doing though (in future PRs)?
2.0 KiB
external_textures
Tests external texture rendering between a native1 platform and Flutter.
Part of Flutter's API for plugins includes passing external textures, or textures
created outside of Flutter, to Flutter, typically using the Texture
widget. This is useful for plugins that render video, or for plugins that
interact with the camera.
For example:
Because external textures are created outside of Flutter, there is often subtle translation that needs to happen between the native platform and Flutter, which is hard to observe. These integration tests are designed to help catch these subtle translation issues.
How it works
- Each
lib/*_main.dartfile is a Flutter app instrumenting a test case. - There is a cooresponding
test_driver/*_test.dartthat runs assertions.
To run the test cases locally, use flutter drive2:
flutter drive lib/frame_rate_main.dart --driver test_driver/frame_rate_test.dart
Tip
On CI, the test cases are run within our device lab.
See
devicelab/lib/tasks/integration_tests.dartand search forcreateExternalTexturesIntegrationTest.The actual tests are run by task runners: