-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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: add heading key tests #10746
tests: add heading key tests #10746
Conversation
lighthouse-core/audits/audit.js
Outdated
// If there are no items, there's nothing to check. | ||
if (!items.length) return; | ||
// Only do this in tests for now. | ||
if (typeof describe === 'undefined' && !process.env.CI) return; |
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 don't really like this. I'd prefer to do something like process.env.LIGHTHOUSE_UNDER_TEST
like I've done in other projects if others are open to it?
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 don't really like this. I'd prefer to do something like
process.env.LIGHTHOUSE_UNDER_TEST
like I've done in other projects if others are open to it?
I'm not wild about setting a precedent and seeing that spread, though :) And it's kind of a bummer to only catch it in CI and not through local testing (I guess yarn unit:core
could set the flag but yarn jest my-audit
wouldn't).
I think it's probably good without the CI check, actually. It might be different if we were constructing table columns dynamically, but AFAIK all headers are hardcoded in their audits (and our general design approach and i18n means we'll likely continue doing that), so if a LH dev runs their audit and gets any kind of table output from it (unit, smoke, or sample_v2) it should hit this and get corrected before it could ever throw for an end user.
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 it's probably good without the CI check, actually
Are you suggesting removing the && !process.env.CI
bit or the entire if?
I'm a little hesitant for removing the entire if
if we currently have cases where rows are conditionally one type or another and a key might be validly missing in some situations. I don't think that's the case, but with 100+ audits I'm not sure and the failure mode is tanking the entire audit's results.
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'm a little hesitant for removing the entire
if
if we currently have cases where rows are conditionally one type or another and a key might be validly missing in some situations. I don't think that's the case, but with 100+ audits I'm not sure and the failure mode is tanking the entire audit's results.
Yeah, I didn't think about the fact that a row value can be set to undefined to have an empty cell, and it's perfectly possible for a table to end up with rows that all happen to have an empty cell there. That would happen with performance-budgets
, for instance, if either the number of requests or size went over budget but not both, but it would pass this test because they're explicitly set to undefined
.
Since in theory this assertion will force audit authors to set explicit undefined
to avoid false negatives anyways (if it's possible to have a table like that you should probably have a test for it, at which point you have to set an explicit undefined
so this check passes in CI) it would be better to just be a requirement, rather than a requirement for any code paths that happen to run in tests.
If the blocker is going through the existing audits with tables, that's not insurmountable. We could divide them up pretty easily (I see 40 makeTableDetails
and 5 makeOpportunityDetails
calls)
@@ -215,7 +215,7 @@ class DuplicatedJavascript extends ByteEfficiencyAudit { | |||
const headings = [ | |||
/* eslint-disable max-len */ | |||
{key: 'source', valueType: 'code', subRows: {key: 'urls', valueType: 'url'}, label: str_(i18n.UIStrings.columnSource)}, | |||
{key: '_', valueType: 'bytes', subRows: {key: 'sourceBytes'}, granularity: 0.05, label: str_(i18n.UIStrings.columnSize)}, | |||
{key: null, valueType: 'bytes', subRows: {key: 'sourceBytes'}, granularity: 0.05, label: str_(i18n.UIStrings.columnSize)}, |
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.
this is the only other fix it found once #10743 landed
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.
yikes
@@ -81,6 +81,26 @@ class Audit { | |||
return clampTo2Decimals(percentile); | |||
} | |||
|
|||
/** | |||
* @param {LH.Audit.Details.Table['headings']|LH.Audit.Details.Opportunity['headings']} headings |
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.
:/
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.
:/
face was to the param type we're stuck with forever, not this function, btw :)
After discussion today:
|
wow did not expect this but...
(from https://jestjs.io/docs/en/getting-started#using-babel under Making your Babel config jest-aware) tested it out and indeed that's the case. handy |
*/ | ||
'use strict'; | ||
|
||
module.exports = { |
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.
@brendankenny you have the great honor of naming this file anything you'd like :)
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.
@brendankenny does this work for you?
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.
naming this file anything you'd like
lighthouse-core/utilities/utils/utils.util.js
pls
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.
(LGTM)
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.
LGTM, just the jsdoc and CI
question
*/ | ||
'use strict'; | ||
|
||
module.exports = { |
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.
naming this file anything you'd like
lighthouse-core/utilities/utils/utils.util.js
pls
*/ | ||
'use strict'; | ||
|
||
module.exports = { |
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.
(LGTM)
module.exports = { | ||
// NODE_ENV is set to test by jest and by smokehouse CLI runner | ||
// CI as a catchall for everything we do in Travis/GitHub Actions | ||
isUnderTest: !!process.env.CI || process.env.NODE_ENV === 'test', |
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.
!!process.env.CI
I thought we wanted it to work in local testing too?
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.
We do and this does.
NODE_ENV is set to test by jest and by smokehouse CLI runner
Do you not like the idea that there's possibly something in CI that we test we don't catch locally without NODE_ENV
?
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.
We do and this does.
oh, lol, ||
. Ignore me :)
@@ -81,6 +81,26 @@ class Audit { | |||
return clampTo2Decimals(percentile); | |||
} | |||
|
|||
/** | |||
* @param {LH.Audit.Details.Table['headings']|LH.Audit.Details.Opportunity['headings']} headings |
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.
:/
face was to the param type we're stuck with forever, not this function, btw :)
Summary
Adds a basic test to ensure all the keys that the headings are referring to a key that actually exists in items. I think this is safe, but there might be legit cases where we conditionally define something so I've left it enabled only in test-like scenarios for now.
Related Issues/PRs
would have caught #10743