Skip to content

Improve Readme 'if a test is broken' section #468

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.

Sign up for GitHub

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

Merged
auto-submit merged 2 commits into from
Oct 21, 2025
Merged

Improve Readme 'if a test is broken' section #468

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
42c697c
Improve 'if a test is broken'
justinmc Aug 12, 2025
5986501
Review
justinmc Oct 21, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 7 additions & 4 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -91,7 +91,7 @@ Use `./scripts/verify_tests_on_main.sh --help` to see more options.
The point of these tests is to make sure we don't break existing code,
while still being able to make improvements to Flutter APIs.

If you find that a PR you have created in flutter/flutter causes one
If you find that a PR you have created in flutter/flutter causes one of
these tests to fail, you have the following options:

1. Change your PR so that the test no longer fails. This is the
Expand All @@ -100,7 +100,7 @@ these tests to fail, you have the following options:
with without the backwards-compatibility constraint? That's good.
Is the resulting API something that, as soon as you see it, you
think "why?" or "that's weird"? That's bad. Consider the advice in
the Style guide:
the style guide:
https://github.com/flutter/flutter/blob/master/docs/contributing/Style-guide-for-Flutter-repo.md

2. Go through the breaking change process, as documented here:
Expand All @@ -110,13 +110,16 @@ these tests to fail, you have the following options:
files), help them fix their code, and update this repository to use
the new version of their tests, in addition to the steps described
on the wiki. You will also need to land your change in two parts,
so that people have time to migrate (a "soft-breaking" change).
so that people have time to migrate (a "soft-breaking" change). See Flutter's
[deprecation policy](https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#deprecations)
for more details.

3. Remove the test in question. This is by far the least ideal
solution. To go down this path, we must first establish that one of
the following is true:

- the people listed as contacts for the test are not responsive (within 72 hours).
- the people listed as contacts for the test are not responsive and a plan
to fix the failure has not been agreed upon within 72 hours.

- the test is poorly written (e.g. it contains a race condition or
relies on assumptions that violate clearly documented API
Expand Down