content test: Share example data between parsing tests and widgets tests #511
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thanks, LGTM! I've added a small commit to use ContentExample for quotations, in the model tests, and also to add a corresponding widget smoke test. If I've understood the pattern and it looks good, please merge at will. 🙂 |
gnprice
commented
Feb 12, 2024
test/model/content_test.dart
Outdated
Comment on lines
125
to
127
| '<blockquote>\n<p>words</p>\n</blockquote>', [ | ||
| QuotationNode([ParagraphNode(links: null, nodes: [TextNode('words')])]) | ||
| ]); |
There was a problem hiding this comment.
nit: this should get just one level of indentation
Suggested change
| '<blockquote>\n<p>words</p>\n</blockquote>', [ | |
| QuotationNode([ParagraphNode(links: null, nodes: [TextNode('words')])]) | |
| ]); | |
| '<blockquote>\n<p>words</p>\n</blockquote>', [ | |
| QuotationNode([ParagraphNode(links: null, nodes: [TextNode('words')])]) | |
| ]); |
gnprice
force-pushed
the
pr-content-test
branch
from
98f0be2 to
4554cca
Compare
This was left here by the `flutter create` template, but we've never used it. If we do want to use it in the future, we can always add it back.
To date we've been adding new dependencies to the end of the lists. One consequence is that adding any dependency always has a merge/rebase conflict with adding any other (unless one is a dev dependency and the other isn't), because the lines go in the same place. That's kind of annoying, so let's start keeping these in alphabetical order instead. This way also makes it a bit easier to find a given dependency. Also delete a comment the template left about how to configure lints; we've been successfully doing that when it comes up.
These `.idea/` directories contain the project configuration and state of IntelliJ IDEA and its family of IDEs -- in particular Android Studio, which is what I and Chris use. There's one for opening the repo at its root (for working on any of the Dart code) and another for opening the android/ subfolder (which better elicits the IDE's support for working on Android-specific code). Lots of the files here are local state (right down to the size and location the IDE window last occupied on the screen) that don't make sense to share. But mixed in among those is some project configuration that is best shared; in particular, this file configuring which "inspections" to run, i.e. what to highlight in the editor as problems to be fixed. Start the file off by disabling the spell-check inspection, because it unavoidably has tons of false positives unless one maintains a list of all the words it doesn't know. I've had this configuration locally since early on; adding to version control now partly for its own sake, but also as preparation to add further configuration to this file.
This Flutter app hasn't worked on the web since we started using a SQLite database, if not sooner. That's no loss; our actual deployment targets are (as README.md says) Android and iOS, and even desktop platforms are supported only for occasional development convenience. So just cut out the files that make up the Web support, which were added by `flutter create` from its templates at the beginning and which we've barely touched since (a total of once, to capitalize the name "Zulip").
The only HTML we have in this project is the example fragments of Zulip content HTML (as in Zulip message bodies) in a couple of our test files. The HTML there is almost all real output from a live Zulip server; even apart from false-positive complaints, there's no point critiquing its style because this client's role is to consume this HTML, not emit it. So turn all the HTML inspections off. This clears out a few dozen complaints the various inspections had had in test/model/content_test.dart in particular, so that it's clean of issues, just like the rest of our files. That makes it easier to navigate to genuine lint issues when they arise while developing changes, and easier to spot occurrence highlights in the scrollbar to see where else in the file some identifier appears that one has one's cursor on.
gnprice
force-pushed
the
pr-content-test
branch
from
4554cca to
9fddec2
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The main goal here is to allow us to reuse in the widget tests in
test/widgets/content_test.dartthe example content blobs that we've written down in the parsing tests intest/model/content_test.dart. Currently we basically have to duplicate the examples, which is OK for short examples and gets more annoying as the example HTML gets longer than a line or so.A nice followup would be to convert all our existing parsing tests into the new
ContentExampleform, and then usetestContentSmoketo have smoke widget tests for all of them. (We could even add an "all content examples are tested" meta-test for widget tests, analogous to the one this PR adds for parsing tests.) But the conversions in this PR, focusing on the lengthiest HTML examples, are as much as I have time for at the moment. Meanwhile this provides the framework for future tests to be onContentExamplefrom the start.Along the way this branch takes care of a few housekeeping items:
flutter createtemplate.