-
Notifications
You must be signed in to change notification settings - Fork 28.6k
[pigeon] Add end-to-end integration_test
tests for all generators
#111505
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
This sets up initial proof-of-concept integration tests using the new shared native test harness: - Integration tests on the Dart side for void->void and Everything->Everything calls. - macOS implementations in the test plugin on the native side. - A new test target in the test script to drive them via `flutter test`. - A minimal change to the example app so that `flutter run`-ing it will test that the void->void call is wired up. Since this simple initial test hit flutter/flutter#111083, which caused the test to fail, this includes a fix for that. Short-term future work (by me): - Add integration test native setup and script targets for the other generators. This includes one just to keep the initial review scope smaller. - Update flutter#2816 to include the integration test since it's still blocked until I can address the CI issues. Medium-term future work (not all by me): - Remove the legacy iOS e2e test scaffold that is currently disabled. - Add significantly more integration test coverage (likely including flutter/flutter#115168 to reduce redundant API setup), including Flutter API integration tests rather than just host API tests. Part of flutter/flutter#111505 Fixes flutter/flutter#111083
* [pigeon] Initial integration test setup This sets up initial proof-of-concept integration tests using the new shared native test harness: - Integration tests on the Dart side for void->void and Everything->Everything calls. - macOS implementations in the test plugin on the native side. - A new test target in the test script to drive them via `flutter test`. - A minimal change to the example app so that `flutter run`-ing it will test that the void->void call is wired up. Since this simple initial test hit flutter/flutter#111083, which caused the test to fail, this includes a fix for that. Short-term future work (by me): - Add integration test native setup and script targets for the other generators. This includes one just to keep the initial review scope smaller. - Update #2816 to include the integration test since it's still blocked until I can address the CI issues. Medium-term future work (not all by me): - Remove the legacy iOS e2e test scaffold that is currently disabled. - Add significantly more integration test coverage (likely including flutter/flutter#115168 to reduce redundant API setup), including Flutter API integration tests rather than just host API tests. Part of flutter/flutter#111505 Fixes flutter/flutter#111083 * Version bump for bugfix * Check in generated files needed for analysis * Add the actual integration test file, which was left out * Address review comments * Fix incorrect Swift unit test for void call fix * Analysis ignore * Autoformat
Adds a new test target to run the new shared integration tests on Kotlin, and adds the necessary native-side plumbing. This is not run by default because it requires a device or emulator to be present, and we don't have that set up for CI yet (and we don't yet have a different script entrypoint for manual vs CI tests). Enabling this in CI is tracked in flutter/flutter#111505, but landing it now allows for better manual testing of generator changes during development. Part of flutter/flutter#111505
Enables the new shared integration tests for the Windows C++ generator, adding the new corresponding test script target and running it by default in CI. Part of flutter/flutter#111505
Enables the new shared integration tests for the Windows C++ generator, adding the new corresponding test script target and running it by default in CI. Part of flutter/flutter#111505
* [pigeon] Add local-only Kotlin integration tests Adds a new test target to run the new shared integration tests on Kotlin, and adds the necessary native-side plumbing. This is not run by default because it requires a device or emulator to be present, and we don't have that set up for CI yet (and we don't yet have a different script entrypoint for manual vs CI tests). Enabling this in CI is tracked in flutter/flutter#111505, but landing it now allows for better manual testing of generator changes during development. Part of flutter/flutter#111505 * Add copyright
This issue is marked P1 but has had no recent status updates. The P1 label indicates high-priority issues that are at the top of the work list. This is the highest priority level a bug can have if it isn't affecting a top-tier customer or breaking the build. Bugs marked P1 are generally actively being worked on unless the assignee is dealing with a P0 bug (or another P1 bug). Issues at this level should be resolved in a matter of months and should have monthly updates on GitHub. |
This is blocked on emulator support in CI, but we're now close to having that. |
Enables the new emulator support for the Linux custom package test targets, and enables the emulator-based Android integration tests for Pigeon. Drops the cores from the high-core config (32) to the default (8) since the emulator requires KVM, and there are currently no 32-core KVM machines in the pool. In practice, it appears that this doesn't have much affect on the runtime. Fixes flutter/flutter#111505
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of |
Uh oh!
There was an error while loading. Please reload this page.
Currently the Pigeon testing is using unit tests on the Dart and native sides; this is useful, but leaves open the potential for unit tests on each side to pass, but for the protocol being unit tested to mis-align slightly such that the end-to-end call doesn't actually work. #111083 is an example of a case that should have been trivially caught by basic integration tests, but has to be more explicitly tested correctly with unit tests based on details of the serialization format on each end. (We also don't have that unit test on the Swift side, which is a problem, but a simple test would be even better.)
I would suggest that we rework the
platform_tests
directory so that instead of having a combination (depending on language) of bespoke tests and per-language dummy plugins, we just have one singletest_plugin
plugin that supports every platform/language (or I guess, two plugins: one for ObjC and Java, and one for everything else, since they can't really co-exist with their alternate languages in the same plugin). That plugin would have:integration_test
tests that would drive full end-to-end calls for a variety of core use cases.(Eventually I would like to revisit using the plugin repo tooling to drive all of this; I temporarily abandoned that when setting up Windows because it would involve more tool changes than I had time to make, but it would make things more sustainable long term that maintaining lots of
run_tests.{dart,sh}
logic. Using this structure would have the added benefit of setting ourselves up for that being easier to add later.)/cc @gaaclarke @tarrinneal
Checklist:
e2e_tests
directory to the new structure, and eliminatee2e_tests
.The text was updated successfully, but these errors were encountered: