[tool][material_ui] Only run test files containing the package's tag with dart-test --package-tags (currently just material_ui web tests) - #13536

Workaround for flutter/flutter#195700
Part of flutter/flutter#192308

Note: This PR reverts #13537, re-enabling the material_ui web unit tests.

When a package has an entry in --package-tags (currently just material_ui, for the web unit tests), dart-test now passes flutter test (or dart test) only the *_test.dart files that contain the tag, instead of the whole test/ directory. Before, every test file was compiled and loaded just to find out whether it had any tagged tests. Now only the files that mention the tag are compiled and loaded.

This matters most on master, where flutter/flutter#193485 roughly doubled how long each web test suite takes to load. That pushed the shard running the material_ui web tests past its 90-minute timeout.

With this change, material_ui loads 52 test files on web instead of 540, and its web tests are about 13× faster.

Caveats

1. The tag must appear literally in the test file

Test files are chosen by searching their text for the tag name. So the tag must be written out in each test file that uses it.

// in my_web_test.dart
testWidgets('My web test', (WidgetTester tester) {
   expect(somethingWebby(), isTrue);
 }, tags: 'reduced-web-test-set');

// in shared_web_utils.dart
const webTestTag = 'reduced-web-test-set';

// in my_web_test.dart
testWidgets('My web test', (WidgetTester tester) {
  expect(somethingWebby(), isTrue);
}, tags: webTestTag);

To catch this, dart-test now fails a tagged package if the tag appears in any non-test Dart file in its lib/ or test/ directories, and lists the offending files.

2. Falls back to old behavior (load/compile all test files) if it's not safe to only load/compile the tagged files

In certain cases, a simple string search isn't sufficient to find all tagged tests. In that case, we fallback to loading and compiling all test files. This happens when:

• the tag isn't a single tag name (e.g. !slow, a || b);
• dart_test.yaml contains any of add_tags, paths, filename or include keys.

Finally, a tagged package with no test files containing the tag is now skipped with "No test files contain the requested tag." instead of starting flutter test. For example, material_ui/test_apps/a11y_assessments used to load 45 suites and run 0 tests.

Pre-Review Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities, or I am not using AI tools.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter.
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I followed the version and CHANGELOG instructions, using semantic versioning and the repository CHANGELOG style, or I have commented below to indicate which documented exception this PR falls under¹.
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PR falls under¹.
• 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. 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.