-
Notifications
You must be signed in to change notification settings - Fork 921
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
Improve remaining build tests #1828
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,18 +1,26 @@ | ||
const fs = require('fs'); | ||
const path = require('path'); | ||
const cheerio = require('cheerio'); | ||
const {setupBuildTest, readFiles} = require('../../test-utils'); | ||
|
||
const html = fs.readFileSync(path.join(__dirname, 'build', 'index.html'), 'utf8'); | ||
const cwd = path.join(__dirname, 'build'); | ||
|
||
const $ = cheerio.load(html); | ||
let files = {}; | ||
|
||
describe('packageManifest.homepage', () => { | ||
beforeAll(() => { | ||
setupBuildTest(__dirname); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This one line does have to be added to the beginning of every test, however, it can be omitted if a different setup is required. Hopefully it‘s the best of both worlds! And it keeps the functionality where if you only want to run a single test locally, only that one test will build. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yea I like this! However, using the synchronous In either case, you can return a promise here, so strong +1 for using the async There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That‘s a good point about running in parallel. I usually try not to pre-emptively optimize something but it does make more sense to flow with how the tests are running. Will change |
||
|
||
files = readFiles(['index.html'], {cwd}); | ||
}); | ||
|
||
it('baseUrl works for <link>', () => { | ||
const $ = cheerio.load(files['/index.html']); | ||
expect($('link[rel="icon"]').attr('href').startsWith('/static/')).toBe(true); | ||
expect($('link[rel="stylesheet"]').attr('href').startsWith('/static/')).toBe(true); | ||
}); | ||
|
||
it('baseUrl works for <script>', () => { | ||
const $ = cheerio.load(files['/index.html']); | ||
expect($('script').attr('src').startsWith('/static/')).toBe(true); | ||
}); | ||
}); |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,15 +1,20 @@ | ||
const fs = require('fs'); | ||
const path = require('path'); | ||
const cheerio = require('cheerio'); | ||
const {setupBuildTest, readFiles} = require('../../test-utils'); | ||
|
||
const cwd = path.join(__dirname, 'build'); | ||
|
||
const html = fs.readFileSync(path.join(cwd, 'index.html'), 'utf8'); | ||
const indexJS = fs.readFileSync(path.join(cwd, 'index.js'), 'utf-8'); | ||
const distJS = fs.readFileSync(path.join(cwd, '_dist_', 'index.js'), 'utf-8'); | ||
const $ = cheerio.load(html); | ||
let files = {}; | ||
let $; | ||
|
||
describe('buildOptions.baseUrl', () => { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. also, top-level There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I’m game for renaming the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Whoops, looks like I misunderstood. |
||
beforeAll(() => { | ||
setupBuildTest(__dirname); | ||
|
||
files = readFiles(['index.html', 'index.js', '_dist_/index.js'], {cwd}); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. also, comment as I'm writing my first test: do we need to maintain an allowlist like this? I'm seeing some unnecessary overhead managing this array and the different A better interface imo would be
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You‘re right that the initialization is awkward. But reading file contents is the bulk of these tests, and most tests can‘t have an inline In writing tests I found myself even getting confused by having to name every file in a project (how do I name Re-reading files isn‘t really a big deal; I’m mostly concerned about the DX. But that said, WDYT about a glob pattern? e.g. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not ready to give up on the idea of solving this with a getter function idea that easily :) Mainly because the objective overhead cost of having to maintain that duplicate file allowlist always matching the files referenced in the individual tests doesn't beat out the subjective "easier variable naming" problem. I think your issue is addressable here. For example, I'd be happy with either of these: // 1.
const fileToTest = await getFile('/index.js');
expect(fileToTest).toInclude(`import __SNOWPACK_ENV__ from './__snowpack__/env.js';`);
expect(fileToTest).toInclude(`import.meta.env = __SNOWPACK_ENV__;`);
// 2. (with the result memoized so that only one lookup is actually used)
expect(await getFile('/index.js')).toInclude(`import __SNOWPACK_ENV__ from './__snowpack__/env.js';`);
expect(await getFile('/index.js')).toInclude(`import.meta.env = __SNOWPACK_ENV__;`); BUT... if you're still on board with moving towards running these tests through the JS Build API as a part of our v3 release, then I'm fine with the existing There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Ah yeah I’d be down for that! I think that’d be a great replacement for the current
Maybe I didn’t explain clearly… the current situation is more like imagine if #1 had 20+ files to keep track of, and needed to be referenced between tests. #2 could work, but in order to be memoized we’d really need to beef it up and I’d rather just discard it in favor of the Node API later on. See https://github.com/snowpackjs/snowpack/pull/1861/files#diff-5097166b779657484196ba597acf4521937f197da2c8803d52480c87d1fb8c75R13 for a reference on the changes… for now I changed it so that it just reads a directory. |
||
$ = cheerio.load(files['/index.html']); | ||
}); | ||
|
||
it('baseUrl works for <link>', () => { | ||
expect($('link[rel="icon"]').attr('href').startsWith('/static/')).toBe(true); | ||
expect($('link[rel="stylesheet"]').attr('href').startsWith('/static/')).toBe(true); | ||
|
@@ -21,15 +26,19 @@ describe('buildOptions.baseUrl', () => { | |
|
||
it('import.meta.env works', () => { | ||
// env is present in index.js | ||
expect(indexJS).toEqual( | ||
expect(files['/index.js']).toEqual( | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a totally-optional test helper for reading files. You pass in any array of files to You’ll notice may tests just skip this helper, especially if the test is simple to begin with. Again, it‘s optional to use but I find it to be easier to read. |
||
expect.stringContaining(`import __SNOWPACK_ENV__ from './__snowpack__/env.js';`), | ||
); | ||
expect(indexJS).toEqual(expect.stringContaining(`import.meta.env = __SNOWPACK_ENV__;`)); | ||
expect(files['/index.js']).toEqual( | ||
expect.stringContaining(`import.meta.env = __SNOWPACK_ENV__;`), | ||
); | ||
|
||
// env is present in _dist_/index.js too | ||
expect(distJS).toEqual( | ||
expect(files['/_dist_/index.js']).toEqual( | ||
expect.stringContaining(`import __SNOWPACK_ENV__ from '../__snowpack__/env.js';`), | ||
); | ||
expect(distJS).toEqual(expect.stringContaining(`import.meta.env = __SNOWPACK_ENV__;`)); | ||
expect(files['/_dist_/index.js']).toEqual( | ||
expect.stringContaining(`import.meta.env = __SNOWPACK_ENV__;`), | ||
); | ||
}); | ||
}); |
This file was deleted.
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.
But with that setup script comes a caveat: none of these files exist when the test loads, so you‘ll have to read files in
beforeAll(() => …
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 actually prefer this, touching globally shared test values is just asking for one test to modify them and then create unexpected behavior.
As we move to use the programatic interface & more "one fixture per test" tests, a separate
files
object would most likely be created for each test, so this is a good step in that direction.