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(smoke): convert core tests to single-expectations format #12819

Merged
merged 4 commits into from
Jul 23, 2021

Conversation

brendankenny
Copy link
Member

@brendankenny brendankenny commented Jul 21, 2021

part 2/2 of #11950. PR currently based on top of #12818

This splits up our core tests so there's a separate testDefn and ID for every smoke expectation. The splitting up is done here and tentative IDs are chosen, but I wanted some bike shedding input before I tried to put everything in the same format.

For reviewers:

  • this is much, much easier to review with ?w=1. Lots of indentation changes.
  • Most important file is core-tests.js, as that's where the test IDs are set.
    (I'll be honest: there are a lot of these, and about halfway through this I stopped trying very hard with the names if the tests weren't super obvious how they were different from each other. I'm looking at you redirects and csp :P Please suggest better IDs than I have here)
  • expectations are functionally all the same, but feel free to pick a smoke file you care about and double check it's still good and offer opinions on the changes in them.

For bikeshedders:

  • IDs!
  • smoketests proposal: one test file per url #11950 suggested a file per expectation, but in some cases there are shared properties between expectations, and multiple named exports could maybe work ok. Do we want to go all the way and still do a file per expectation (and import shared stuff), or have a mixture of single and multiples, or...? Splitting into different files should be easy now, so I'm happy to go either way.
  • We have grouped IDs where e.g. the old errors becomes errors-infinite-loop, errors-expired-ssl etc. Handy for running with just yarn smoke errors, but:
    • do we want to formalize a category-specific naming format?
    • are one-off tests ok? e.g. there's only one oopif tests, so it's still just called oopif. Is that ok or should we preemptively call it oopif-requests just in case one day we have oopif-some-other-thing?

@brendankenny brendankenny requested a review from a team as a code owner July 21, 2021 23:43
@brendankenny brendankenny requested review from patrickhulce and removed request for a team July 21, 2021 23:43
@google-cla google-cla bot added the cla: yes label Jul 21, 2021
@@ -0,0 +1,42 @@
/**
Copy link
Member Author

Choose a reason for hiding this comment

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

moved from dbw-expectations.js as dbw is kind of its own thing and issues are worthy of their own smoke tests

Copy link
Collaborator

@patrickhulce patrickhulce left a comment

Choose a reason for hiding this comment

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

names mostly seem fine to me! 🎉

thanks for trudging through this super mechanical drudgery :D

/**
* @type {Smokehouse.ExpectedRunnerResult}
*/
const ricShort = {
Copy link
Collaborator

Choose a reason for hiding this comment

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

idleCallbackShort?

ric lowercase is harder to remember what it is than rIC, probably should've done that with the ric-shim filename originally 😊

/**
* @type {Smokehouse.ExpectedRunnerResult}
*/
const ricLong = {
Copy link
Collaborator

Choose a reason for hiding this comment

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

same

Comment on lines 129 to 135
// TODO: what's the describable difference between this and the above? Also, better names.
/**
* @type {Smokehouse.ExpectedRunnerResult}
* Expected Lighthouse audit values for a site with a client-side redirect (2s + 5s),
* paints at 2s, then a server-side redirect (1s).
*/
const clientPaintServer2 = {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
// TODO: what's the describable difference between this and the above? Also, better names.
/**
* @type {Smokehouse.ExpectedRunnerResult}
* Expected Lighthouse audit values for a site with a client-side redirect (2s + 5s),
* paints at 2s, then a server-side redirect (1s).
*/
const clientPaintServer2 = {
/**
* @type {Smokehouse.ExpectedRunnerResult}
* Expected Lighthouse audit values for a site with a client-side redirect (2s + 5s),
* paints at 2s, then a server-side redirect (1s), followed by a history.pushState to an unrelated URL.
*/
const historyPushState = {

Copy link
Collaborator

Choose a reason for hiding this comment

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

NOTE: will require a few other historyPushState renames as well

config: require('./seo/seo-config.js'),
}, {
id: 'offline',
expectations: require('./offline-local/offline-expectations.js'),
id: 'seo-tap-target',
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
id: 'seo-tap-target',
id: 'seo-tap-targets',

expectations: redirects.singleClient,
config: require('./redirects/redirects-config.js'),
}, {
id: 'redirects-client-paint-server-2',
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
id: 'redirects-client-paint-server-2',
id: 'redirects-history-pushstate',

Base automatically changed from single-smoke to master July 22, 2021 21:45
@paulirish
Copy link
Member

yay death to pwa2 and pwa3! :)

Do we want to go all the way and still do a file per expectation (and import shared stuff)

yeah. i think doing that allows us to fix the file/folder structure of test-definitions which i'm really excited about. i think it makes sense as a follow up PR; the scope of this one is great.

do we want to formalize a category-specific naming format?

eh, nah.

are one-off tests ok? e.g. there's only one oopif tests, so it's still just called oopif. Is that ok or should we preemptively call it oopif-requests just in case one day we have oopif-some-other-thing?

yeah lets leave it alone. shorter is better, so lets only elongate when we have to.

i'm happy with these slugs (except for csp-base which should be csp-basics or something)

woo!

@brendankenny
Copy link
Member Author

SG. We'll go with these (except for the CSP ones, @adamraine is about to take a look) but we have a second chance to discuss them in the next PR.

requestedUrl: 'http://localhost:10200/csp.html',
finalUrl: 'http://localhost:10200/csp.html',
audits: {},
const base = {
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
const base = {
const noCsp = {

Copy link
Member

Choose a reason for hiding this comment

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

Alternative: allowAll

/**
* @type {Smokehouse.ExpectedRunnerResult}
*/
const exceptInline = {
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
const exceptInline = {
const blockAllM91 = {

This CSP blocks everything, with a special exception for one inline script that has a source map.

We will probably remove this once M91 hits stable, so I would add the version suffix to this one.

/**
* @type {Smokehouse.ExpectedRunnerResult}
*/
const exceptInlineM92 = {
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
const exceptInlineM92 = {
const blockAll = {

@brendankenny
Copy link
Member Author

looks great. Thanks!

id: 'issues-mixed-content',
expectations: require('./issues/mixed-content.js'),
}, {
id: 'redirects-single-server',
Copy link
Collaborator

@connorjclark connorjclark Jul 22, 2021

Choose a reason for hiding this comment

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

how about going one step further and moving this entire object to what expectations.js exports? there is overhead in separating "this is what the test does" and "this is the id we give it and the config it uses"

then core-tests.js is just bringing it all together as an array.

(separate PR would be best)

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, it's a little silly to have filenames for separate files and then IDs for them in a different file. That'll be in the above-mentioned (but undescribed, sorry) next PR.

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.

6 participants