-
Notifications
You must be signed in to change notification settings - Fork 50.4k
Update Float tests to check for specific errors #26367
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.
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
Update Float tests to check for specific errors #26367
Conversation
I updated some of the Float tests that intentionally trigger an error to assert on the specific error message, rather than swallow any errors that may or may not happen.
7c79b97 to
7e5fa1b
Compare
kassens
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice
|
Comparing: 93c10df...7e5fa1b Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: (No significant changes) |
| expect(aggregateError.errors.length).toBe(2); | ||
| expect(aggregateError.errors[0].message).toContain( | ||
| 'Invalid insertion of NOSCRIPT', | ||
| ); | ||
| expect(aggregateError.errors[1].message).toContain( | ||
| 'The node to be removed is not a child of this node', | ||
| ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can remove the !DEV gate too now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh I was wondering why the negative flag check wouldn't have caught that and it's because enableFloat is true in all our builds, so the combined gate condition is always true. Can we just clean up the flag now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that this already rolled out at Meta I vote for landing the enableFloat flag and removing the associated gates from all our tests. Can do in a follow up.
|
I wonder if it is worth asserting those DOMException errors. The tests are really concerned with the warnings, not the specific error pathways. But I suppose it doesn't hurt and it might surface if some really strange new error starts to show up. Up to your intuition I think but I would maybe remove |
I usually assert on the message anyway in case an error that we don't expect to happen starts happening. While the test is primarily about the warning, it also implicitly tests the absence of some unknown worse behavior, like "does React fall into an infinite update loop if you pass a |
I updated some of the Float tests that intentionally trigger an error to assert on the specific error message, rather than swallow any errors that may or may not happen.