9d96df2364
WIP Commits separated as follows: - Update lints in analysis_options files - Run `dart fix --apply` - Clean up leftover analysis issues - Run `dart format .` in the right places. Local analysis and testing passes. Checking CI now. Part of https://github.com/flutter/flutter/issues/178827 - Adoption of flutter_lints in examples/api coming in a separate change (cc @loic-sharma) ## Pre-launch Checklist - [ ] I read the [Contributor Guide] and followed the process outlined there for submitting PRs. - [ ] I read the [Tree Hygiene] wiki page, which explains my responsibilities. - [ ] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement]. - [ ] I signed the [CLA]. - [ ] I listed at least one issue that this PR fixes in the description above. - [ ] I updated/added relevant documentation (doc comments with `///`). - [ ] I added new tests to check the change I am making, or this PR is [test-exempt]. - [ ] I followed the [breaking change policy] and added [Data Driven Fixes] where supported. - [ ] All existing and new tests are passing. If you need help, consider asking for advice on the #hackers-new channel on [Discord]. **Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). Comments from the `gemini-code-assist` bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed. <!-- Links --> [Contributor Guide]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview [Tree Hygiene]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md [test-exempt]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#tests [Flutter Style Guide]: https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md [Features we expect every widget to implement]: https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement [CLA]: https://cla.developers.google.com/ [flutter/tests]: https://github.com/flutter/tests [breaking change policy]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#handling-breaking-changes [Discord]: https://github.com/flutter/flutter/blob/main/docs/contributing/Chat.md [Data Driven Fixes]: https://github.com/flutter/flutter/blob/main/docs/contributing/Data-driven-Fixes.md
Private Test Runner
These are tests of private interfaces that can't easily happen in the regular flutter tests due to problems with test and implementation interdependence.
This gets around the problem of parts existing in more than one library by making a copy of the code under test.
The test script bin/test_private.dart tests private interfaces by copying the
code under test into a temporary workspace. The test is then free to make the
copied flutter source into a "part" of its own library by declaring a library
and using the part directive with a relative path to include the parts. This
way the test and the private interface are part of the same library, and the
private interface can be accessed by the test.
The tests are run like so:
dart run bin/test_private.dart
One limitation is that the copied private API needs to be separable enough to be copied, so it needs to be in its own separate files.
To add a private test, add a manifest file of the form (assuming "my_private_test" is the name of the test) to the test subdir:
{
"tests": [
"my_private_test.dart"
],
"pubspec": "my_private_test.pubspec.yaml",
"deps": [
"lib/src/subpackage/my_private_implementation.dart",
]
}
It will copy the files in deps relative to the packages/flutter directory
into a similar relative path structure in the test temporary directory tree. It
will copy the pubspec file into pubspec.yaml in the test temporary
directory, and copy all of the tests into the top of the test temporary
directory tree.
Each test gets its own temporary directory tree under a generated temporary
directory in the system temp dir that is removed at the end of the run, or under
the path given to --temp-dir on the command line. If a temporary directory is
given explicitly, it will not be deleted at the end of the run.