Skip to content
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

tests(i18n): only accept IcuMessages in toBeDisplayString #12487

Merged
merged 1 commit into from
May 14, 2021

Conversation

brendankenny
Copy link
Member

Adds an assertion to expect.toBeDisplayString that the passed-in value is an LH.IcuMessage and not a matching string.

Originally expect.toBeDisplayString was intended to support either string or LH.IcuMessage since most of the localized LHR properties end up being a union of the two. However, since then, it's clear that our tests always know if a tested property is going to be localizable or not so it's better to be specific. Doing it this way also avoids the potential to assert that a value is a certain string once localized, but miss the fact that it's just the english string that won't be localized (luckily we don't appear to have that problem anywhere).

Also fixes a few places where these were incorrectly being asserted, mostly on fallbacks that occur specifically when i18n is failing for that audit and on values outside runner, which have usually already been localized.

@brendankenny brendankenny requested a review from a team as a code owner May 14, 2021 23:05
@brendankenny brendankenny requested review from connorjclark and removed request for a team May 14, 2021 23:05
@google-cla google-cla bot added the cla: yes label May 14, 2021
@@ -167,7 +167,7 @@ describe('PWA: webapp install banner audit', () => {
return InstallableManifestAudit.audit(artifacts, context).then(result => {
assert.strictEqual(result.score, 0);
const items = result.details.items;
expect(items[0].reason).toBeDisplayString(/unexpected arguments/);
expect(items[0].reason).toMatch(/unexpected arguments/);
Copy link
Member Author

@brendankenny brendankenny May 14, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these two are kind of weird because we're putting them in the audit table, but really they're messages to us that the protocol has diverged from what we expect, so it seems better to leave them untranslated (maybe they should be just Sentry errors and test assertions that they don't occur in CI and at least leave out the "unexpected arguments" part for users?)

@@ -84,7 +84,7 @@ describe('Security: HTTPS audit', () => {
// Unknown blocked resolution string is used as fallback.
expect(result.details.items[2]).toMatchObject({
url: 'http://localhost/image2.jpeg',
resolution: expect.toBeDisplayString('MixedContentBlockedLOL'),
resolution: 'MixedContentBlockedLOL',
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is testing that it falls back to just using the protocol-provided string when it's a string that we don't recognize, so of course it's not localized.

@@ -103,8 +102,7 @@ describe('Module Tests', function() {
try {
await lighthouse('file:///a/fake/index.html', {}, {});
} catch (err) {
expect(err.friendlyMessage)
.toBeDisplayString('The URL you have provided appears to be invalid.');
expect(err.friendlyMessage).toBe('The URL you have provided appears to be invalid.');
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

runner localizes these internally (and there's a test for that), so they aren't LH.IcuMessages by the time index.js sees them

@@ -821,7 +821,7 @@ describe('Runner', () => {

// But top-level runtimeError is the pageLoadError.
expect(lhr.runtimeError.code).toEqual(LHError.errors.PAGE_HUNG.code);
expect(lhr.runtimeError.message).toBeDisplayString(/because the page stopped responding/);
expect(lhr.runtimeError.message).toMatch(/because the page stopped responding/);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LHRs are already localized when returned from Runner.run, so can just match the strings directly

@devtools-bot devtools-bot merged commit c2e0e0b into master May 14, 2021
@devtools-bot devtools-bot deleted the stricter-tobedisplaystring branch May 14, 2021 23:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants