Skip to content

test: move WPT to its own testing module - #12736

Closed
Trott wants to merge 1 commit into
nodejs:masterfrom
Trott:demonolith-wpt
Closed

test: move WPT to its own testing module#12736
Trott wants to merge 1 commit into
nodejs:masterfrom
Trott:demonolith-wpt

Conversation

@Trott

Copy link
Copy Markdown
Member

This is first in a hoped-for series of moves away from a monolithic
common.js that is loaded for every test and towards a more modular
approach. (In the end, common.js will hopefully contain checks for
variables leaking into the global space and perhaps some of the more
ubiquitous functions like common.mustCall().)

Move the WPT testing code to its own module.

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • documentation is changed or added
  • commit message follows commit guidelines
Affected core subsystem(s)

test url

@TrottTrott added test Issues and PRs related to the tests. whatwg-url Issues and PRs related to the WHATWG URL implementation. labels Apr 29, 2017
@nodejs-github-botnodejs-github-bot added the test Issues and PRs related to the tests. label Apr 29, 2017
@Trott

Copy link
Copy Markdown
MemberAuthor

This is a sort of trial balloon to see if there's support for this sort of change generally. /cc @nodejs/testing @nodejs/url

@Trott

Copy link
Copy Markdown
MemberAuthor

Comment threadtest/README.md Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

## getArrayBufferViews(buf) -> #### getArrayBufferViews(buf) right? (L225)

@targos

Copy link
Copy Markdown
Member

+1 on the initiative, but I wonder if we shouldn't have a test/lib/ directory to put those factored out modules.

@gibfahn

gibfahn commented Apr 29, 2017

Copy link
Copy Markdown
Member

LGTM in this case as common.WPT seems always used separately, so

-const { test, assert_equals } = common.WPT;+const { test, assert_equals } = require('../wpt');

isn't a big deal.

But in general if we're going to split up common and start having:

-const common = require('../common');+require('../common');+const commonx = require('../commonx');+const commony = require('../commony');+const commonz = require('../commonz');

then I'm not sure what the benefit is (or if it outweighs the increased complexity, especially for new contributors).


Same applies to adding a test/lib/ directory. At the moment anyone looking at test/ sees test folders and a common.js file, which I'd hope is pretty intuitive (and a style used by other projects). Of course we do already have test/testpy/, which is non-obvious. Maybe a test/common/ directory would be obvious enough, 🤷‍♀️ .

@targos

Copy link
Copy Markdown
Member

Maybe a test/common/ directory would be obvious enough

Good idea. We could move common.js to test/common/index.js in that case, keeping require('../common') compatibility.

@benjamingrbenjamingr left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I'm +0 on doing this but the changes LGTM

Comment threadtest/README.md Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

If we're editing these, could we move the h* properties so that they're in alphabetical order?

@cjihrig

Copy link
Copy Markdown
Contributor

I like the idea of a test/common/ directory to split up the existing large file.

I don't like losing access to everything I need for testing from require('../common'). What if we lazy loaded less commonly used things?

@mhdawson

Copy link
Copy Markdown
Member

I'm +0 zero on this change. Is it a problem to load it for every test ? If not then if we want to modularize into separate files maybe we can do that but still end up with a single import ?

@Trott

Trott commented May 1, 2017

Copy link
Copy Markdown
MemberAuthor

rebased to resolve conflict and resolve README nits

@Trott

Trott commented May 1, 2017

Copy link
Copy Markdown
MemberAuthor

Even if we don't do this for anything else, I think it makes a lot of sense to split out the WPT stuff because it really is its own thing that gets used its own way. People shouldn't use it without fully understanding where it comes from and why it is the way it is. At the same time, it isn't something people need to bother with in the vast majority of cases.

@Fishrock123

Copy link
Copy Markdown
Contributor

Uhm, what is "WPT"?

@Trott

Trott commented May 1, 2017

Copy link
Copy Markdown
MemberAuthor

@TimothyGu

Copy link
Copy Markdown
Member

I'm indifferent towards splitting out WPT. Its (very specific) use is documented, and I'm of the opinion that people generally won't touch the stuff they don't know about. Though I can see how logically it might not fit with the rest of test/common.js.

On splitting up test/common.js in general, I'm –½. What are the benefits of splitting it up? This might sound snarky, but AFAICT the utilities can all go under one category "miscellaneous."

On splitting up and lazy-loading different utilities, I'm –1. If the time being spent on loading test/common/* is insignificant then lazy-loading would be overkill, and if not I'd advocate for not splitting it at all.

@Trott

Trott commented May 2, 2017

Copy link
Copy Markdown
MemberAuthor

@TimothyGu You make some good points, for sure. The main benefit would be for newcomers looking at the docs. Instead of dozens of properties, many of which won't matter to them, it can just be properties that are easy to understand and whose value is readily apparent. Like, common.isWindows? Sure, I get it. common.mustCall()? Yup, that's useful. Someone can read the common docs and feel like they've understood the module rather than puzzling over when, why, and how to use common.spawnSyncPwd() and common.arrayStream.

(On the other hand, looking at common, most of the things fall into the "ubiquitous, simple, and useful" category. But for the things that don't...)

@Trott

Trott commented May 2, 2017

Copy link
Copy Markdown
MemberAuthor

I really like the common/ directory idea so I went ahead and did that....

@Trott

Trott commented May 2, 2017

Copy link
Copy Markdown
MemberAuthor

Comment threadtest/README.md Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Should this be common/wpt?

Comment threadtest/README.md Outdated

@richardlaurichardlauMay 2, 2017

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Are we still calling the module common.js after the refactor? How about just common?

@Trott

Trott commented May 2, 2017

Copy link
Copy Markdown
MemberAuthor

Pushed fixes for README nits.

Probably want to move the docs for the common module etc. into test/common/README.md and provide a link in test/README.md?

@Trott

Trott commented May 2, 2017

Copy link
Copy Markdown
MemberAuthor

Split out into separate READMEs and force-pushed.

@Trott

Trott commented May 2, 2017

Copy link
Copy Markdown
MemberAuthor

@Trott

Trott commented May 3, 2017

Copy link
Copy Markdown
MemberAuthor

Rebased to resolve conflict.

CI: https://ci.nodejs.org/job/node-test-pull-request/7818/

@richardlau

Copy link
Copy Markdown
Member

Probably want to move the docs for the common module etc. into test/common/README.md and provide a link in test/README.md?

The link is missing. Probably should add an entry for common under the test directories table.

@Trott

Trott commented May 3, 2017

Copy link
Copy Markdown
MemberAuthor

The link is missing. Probably should add an entry for common under the test directories table.

Heh! Also: Should add an entry for the common directory in the main README and put the link there (either in addition or instead).

@Trott

Trott commented May 3, 2017

Copy link
Copy Markdown
MemberAuthor

Entry for common directory and link to that directory's README.md added to main test directory's README.

@Trott

Trott commented May 3, 2017

Copy link
Copy Markdown
MemberAuthor

Comment threadtest/README.md Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

fixtures and testpy leave this column empty.

@richardlaurichardlau left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Minor nit otherwise LGTM.

This is first in a hoped-for series of moves away from a monolithic
common.js that is loaded for every test and towards a more modular
approach. (In the end, common.js will hopefully contain checks for
variables leaking into the global space and perhaps some of the more
ubiquitous functions like common.mustCall().)
Move the WPT testing code to its own module.
@Trott

Trott commented May 3, 2017

Copy link
Copy Markdown
MemberAuthor

@Trott

Trott commented May 4, 2017

Copy link
Copy Markdown
MemberAuthor

Landed in ff001c1

Trott added a commit to Trott/io.js that referenced this pull request May 4, 2017
This is first in a hoped-for series of moves away from a monolithic
common.js that is loaded for every test and towards a more modular
approach. (In the end, common.js will hopefully contain checks for
variables leaking into the global space and perhaps some of the more
ubiquitous functions like common.mustCall().)
Move the WPT testing code to its own module.
PR-URL: nodejs#12736
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
@TrottTrott closed this May 4, 2017
anchnk pushed a commit to anchnk/node that referenced this pull request May 6, 2017
This is first in a hoped-for series of moves away from a monolithic
common.js that is loaded for every test and towards a more modular
approach. (In the end, common.js will hopefully contain checks for
variables leaking into the global space and perhaps some of the more
ubiquitous functions like common.mustCall().)
Move the WPT testing code to its own module.
PR-URL: nodejs#12736
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
@jasnelljasnell mentioned this pull request May 11, 2017
@gibfahngibfahn mentioned this pull request Jun 15, 2017
3 tasks
@gibfahn

Copy link
Copy Markdown
Member

@Trott could you backport this to v6.x-staging? It'd be good to get this backported as otherwise this is going to cause a lot of conflicts.

If yes please follow the guide and raise a backport PR, if no let me know or add the dont-land-on label.

Trott added a commit to Trott/io.js that referenced this pull request Jun 19, 2017
This is first in a hoped-for series of moves away from a monolithic
common.js that is loaded for every test and towards a more modular
approach. (In the end, common.js will hopefully contain checks for
variables leaking into the global space and perhaps some of the more
ubiquitous functions like common.mustCall().)
Move the WPT testing code to its own module.
PR-URL: nodejs#12736
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
@Trott

Copy link
Copy Markdown
MemberAuthor

@gibfahn backport in #13775

gibfahn pushed a commit that referenced this pull request Jun 20, 2017
This is first in a hoped-for series of moves away from a monolithic
common.js that is loaded for every test and towards a more modular
approach. (In the end, common.js will hopefully contain checks for
variables leaking into the global space and perhaps some of the more
ubiquitous functions like common.mustCall().)
Move the WPT testing code to its own module.
PR-URL: #12736
Backport-PR-URL: #13775
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
MylesBorins pushed a commit that referenced this pull request Jul 11, 2017
This is first in a hoped-for series of moves away from a monolithic
common.js that is loaded for every test and towards a more modular
approach. (In the end, common.js will hopefully contain checks for
variables leaking into the global space and perhaps some of the more
ubiquitous functions like common.mustCall().)
Move the WPT testing code to its own module.
PR-URL: #12736
Backport-PR-URL: #13775
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
@MylesBorinsMylesBorins mentioned this pull request Jul 18, 2017
@Trott
Trott deleted the demonolith-wpt branch January 13, 2022 22:45
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

testIssues and PRs related to the tests.whatwg-urlIssues and PRs related to the WHATWG URL implementation.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

10 participants

@Trott@targos@gibfahn@cjihrig@mhdawson@Fishrock123@TimothyGu@richardlau@benjamingr@nodejs-github-bot