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.
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: smoke request count assertion #12325
tests: smoke request count assertion #12325
Changes from 4 commits
abf7245
b4ddf5a
3fd2d05
5e71ba8
f42b2f4
e578427
f1b4ab3
46ea590
1096452
9bb6c76
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
it seems like this should be run outside of the assert module and the result passed in, like the other parts of
actual
.smokehouse.js
is a natural place to do that, but that wouldn't work for the bundled version run for smokerider (which doesn't usestatic-server
). Almost needs to be part ofSmokehouseOptions
, similar to thelighthouseRunner
callback?(I don't love that idea, but I'm not sure of a better one)
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'd be good to exercise the actual assertions within the PR.
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 added some expectations to perf.
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.
dbw might be one of the best to add expectations to since the page tries to be bad at everything and the smoke test runs the full default config. It's also just the one smoke test, so shouldn't be much work to add.
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.
dbw is two smoke tests run in parallel, one smoke test is an external URL.
The smoke test should still work if we adjust our requirement from "Tests run synchronously" to "Only one test using the static server at a time". Definitely doable, but it might add a bit of complexity.
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.
Ah, yeah, I meant just the first one anyways. Agreed it's not worth the complexity (at least for now) to add
networkRequests
to the second oneThere 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.
That is unfortunately still a problem. Under the current implementation, the expectation would be pruned/throw because dbw is run in parallel. We need to change the definition (adding complexity) for the expectation to be actually be asserted.
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.
Oh, I see, you're talking about
runSerially
so we've been talking about slightly different things this whole time, sorry :/You have the
isSync
value based onconcurrency
, which is the combination ofrunSerially
with the--jobs
flag/option:lighthouse/lighthouse-cli/test/smokehouse/smokehouse.js
Lines 55 to 56 in 802947d
so it'll be pruned in a the usual local runs, but in CI we run with
-j=1
for vm performance reasons (and maybe still coverage collection issues?) soconcurrency
will still be 1 and it shouldn't be pruned there.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.
Now that I write that, maybe it'll be annoying when editing dbw to only find out about failures in CI unless you happen to run with
-j=1
🤷If ever there was a smoke test perfect for #11506 it would be dbw, though. Should we just
runSerially: true
it and take the hit on slower smoke tests but keep things simpler?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.
That's what I'm thinking, it shouldn't be too bad because there are only two tests.
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.
Just added dbw.
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 still want to be able to run in parallel locally, at least. Maybe move this check to
pruneExpectations()
inreport-assert.js
and removeexpectation.networkRequests
if!process.env.CI && concurrency > 1
(to enforce doing the extra checks in CI), otherwise throw this error?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.
Is there a way to know
concurrency
inpruneExpectations
?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.
no, it would have to be passed down in
reportOptions
(either directly or as ashouldTestNetworkRequests
or whatever)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.
the big question here...what do we actually want to assert about these? :)
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.
From the issue, it sounds like the best thing to assert is the number of requests.
If we just did
networkRequestCount
or something, there would be no way to add a_minChromiumVersion
for specific network request assertions.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.
ah, got it. Maybe
networkRequests?: Array<unknown>
then to make it clearer but we won't have to bother typing the requests saved fromstatic-server
?Or could do
networkRequests?: {length: number}
if we wanted to be explicit about what we expect from test authors right now.Both options would be forward compatible if for some reason we wanted to move to specific object shapes later (
networkRequest?: Array<{url: string}>
or whatever).