Encourage splitting large test files in testing documentation#181880
Encourage splitting large test files in testing documentation#181880crackedhandle wants to merge 6 commits into
Conversation
There was a problem hiding this comment.
Code Review
This pull request updates the testing documentation to encourage splitting large test files into smaller, more focused ones. The change adds a new section to Running-and-writing-tests.md that explains the benefits of this approach and mentions using dart_test.yaml for better organization. My feedback includes suggestions to add a link to the dart_test.yaml documentation and to expand the list of benefits to include faster test execution, both of which are supported by the repository's style guide.
| - Reviewability for contributors | ||
| - Faster test execution (by enabling better parallelism) | ||
|
|
||
| When appropriate, configure [`dart_test.yaml`](https://github.com/dart-lang/test/blob/master/pkgs/test/doc/configuration.md) to manage test file patterns and improve organization across packages. |
There was a problem hiding this comment.
The line about dart_test.yaml has little to do with writing the actual tests?
|
|
||
| ### Organizing test files | ||
|
|
||
| Avoid creating overly large test files that contain many unrelated test cases. |
There was a problem hiding this comment.
While it is true that sometimes tests end up in the wrong file (see the discoveries from the cross imports issue), most of the time the problem is just that there are a lot of closely related tests in a single file, rather than tests being in the wrong place.
|
Hello @crackedhandle, thanks for the patch! We recently had a Dash Forum - presented by @Piinks - on our style guide that covered the length of test files: flutter.dev/go/flutter-style-updates##heading=h.2annk22r4g84.
@Piinks will be updating Flutter's style guide soon with the guidance from that Dash Forum, which will likely also include similar guidance to split large test files by amending this section. I suspect that update will supersede this pull request and touch other parts of the style guide as well. |
|
Thanks for the feedback! That makes sense — I agree that the dart_test.yaml reference may be out of scope here. I’ll remove that line. Regarding the broader guidance, I understand that upcoming style guide updates may better address this. I’m happy to adjust or close this PR if that change supersedes this addition. |
159c8eb to
800f8cd
Compare
| ### Organizing test files | ||
|
|
||
| Avoid creating overly large test files that contain many unrelated test cases. | ||
| Instead, organize tests into smaller files grouped by feature, widget, or behavior. |
There was a problem hiding this comment.
Can you share some specific examples, such as naming convention?
There was a problem hiding this comment.
Thanks for asking!
For example, instead of keeping everything in a single file like:
button_test.dart
that includes layout, semantics, and interaction tests, it could be split into:
button_layout_test.dartbutton_semantics_test.dartbutton_interaction_test.dart
Or grouping by behavior:
navigator_push_test.dartnavigator_pop_test.dartnavigator_transition_test.dart
The idea is to keep tests focused by feature or behavior so they’re easier to navigate, review, and maintain.
There was a problem hiding this comment.
This is great! Want to add it?
There was a problem hiding this comment.
Thanks! Yes, I can add these examples directly to the documentation to make the guidance clearer.
However, I’m currently managing some academic commitments, so it may take me a little time to incorporate the updates properly. I’ll work on refining the section and push the changes as soon as possible.
Appreciate the suggestion — it definitely improves the clarity of the guidelines.
There was a problem hiding this comment.
Added naming convention examples to clarify the guidance. Please let me know if any further refinement is needed.
Thank you for the review and approval! I’ve sent you a LinkedIn connection request (Divyansh Shah). |
loic-sharma
left a comment
There was a problem hiding this comment.
Thanks for the contribution!
|
auto label is removed for flutter/flutter/181880, Failed to enqueue flutter/flutter/181880 with HTTP 400: GraphQL mutate failed. |
831d41f to
26d4c94
Compare
|
auto label is removed for flutter/flutter/181880, Failed to enqueue flutter/flutter/181880 with HTTP 400: GraphQL mutate failed. |
|
Hey @crackedhandle we're debugging the submit issue. Can you push an empty commit to the PR? |
Pushed an empty commit to retrigger CI. Please let me know if anything else is needed. |
|
auto label is removed for flutter/flutter/181880, Failed to enqueue flutter/flutter/181880 with HTTP 400: GraphQL mutate failed. |
|
I understand this may not be the appropriate place and time to ask, but I truly appreciate the guidance and discussions here. If possible, I would be grateful to connect on LinkedIn, as I have a few questions and would love to learn more from your experience. Thank you for your time and support.@Piinks @loic-sharma |
|
You're trying to merge to |
Thanks @jtmcdole! Can you update the target to master @crackedhandle? Or open a new PR targeting master? We cannot merge to main. |
Thanks for the invite. I personally keep my LinkedIn network to my co-workers, but please feel free to reach out on Discord: https://github.com/flutter/flutter/blob/master/docs/contributing/Chat.md My Discord handle is |
6e66bc2 to
dddce28
Compare
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
|
An existing Git SHA, To re-trigger presubmits after closing or re-opeing a PR, or pushing a HEAD commit (i.e. with |
|
Thank you for the response — I completely understand I appreciate you sharing the Discord details. I’ll join the Flutter Discord and reach out there if needed. Also, I’ve created a new PR targeting Thanks again for your guidance and support! |
|
@loic-sharma whats next anything needed? |
|
Closing as replaced by #182051 |
This PR updates the testing documentation to encourage contributors to split large test files into smaller, feature-focused files.
Smaller test files improve readability, navigation, maintainability, and reviewability.
Fixes #181819