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

test: adding tests for fs/promises.js fileHandle methods #19605

Closed

Conversation

willhayslett
Copy link
Contributor

@willhayslett willhayslett commented Mar 26, 2018

Working to increase test code coverage for fs/promises.js.
Added tests for fileHandle.appendFile and fileHandle.chmod.

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines

@nodejs-github-bot nodejs-github-bot added the test Issues and PRs related to the tests. label Mar 26, 2018
@Trott
Copy link
Member

Trott commented Mar 26, 2018

@nodejs/testing @nodejs/fs

@willhayslett willhayslett force-pushed the test-fs-promises-file-handle branch from 3ae097a to a24069b Compare March 28, 2018 07:02
@willhayslett
Copy link
Contributor Author

Hi @Trott. Are the format of these tests okay? Just want to make sure before I try creating more.

@Trott
Copy link
Member

Trott commented Mar 29, 2018

Looks OK to me. Surprised these haven't gotten any reviews. I'm leaving work RIGHT NOW but let's try to ping some folks: @nodejs/collaborators

@willhayslett
Copy link
Contributor Author

Thanks, @Trott!

Copy link
Member

@benjamingr benjamingr left a comment

Choose a reason for hiding this comment

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

Just a question - why do these methods validate fs methods by calling the sync versions and comparing the output? Wouldn't it make more sense to validate the actual output is what we expect?

For example in the writeFile example - wouldn't it be better to compare it to the buffer?

@willhayslett
Copy link
Contributor Author

@benjamingr thanks for the feedback. I may have been overthinking it through trying to validate that the new methods should just behave as the old. I don't necessarily think it's a bad test to have, but it doesn't test the specification directly. I'll update the tests where appropriate tonight.

@willhayslett willhayslett force-pushed the test-fs-promises-file-handle branch 2 times, most recently from d2b9bce to 5f5977a Compare March 30, 2018 03:48
@TimothyGu
Copy link
Member

@willclarktech Could you rebase to get rid of the merge commit in your branch?

@willhayslett
Copy link
Contributor Author

Hi @TimothyGu. Was researching how to do that last night. Will it be okay to just squash all the commits on my branch into one?

@Trott
Copy link
Member

Trott commented Mar 30, 2018

Will it be okay to just squash all the commits on my branch into one?

That should be fine, although you can also just squash out the one merge commit too. Either way.

@willhayslett willhayslett force-pushed the test-fs-promises-file-handle branch from 5f5977a to 6a62939 Compare March 30, 2018 21:25
@willhayslett
Copy link
Contributor Author

Thanks, everyone. I was able to get rid of the merge commit. Not sure what I did to get into that state but the merge commit itself had a lot of the changes I wanted. I ended up rebasing to the parent of the merge and reapplied my changes on top of it in a new commit. Let me know if any other changes are needed.

@willhayslett
Copy link
Contributor Author

Hi @benjamingr; are the changes that were made okay? I'm still learning and very open to any feedback/refactoring requests. Just trying to get better and hopefully provide a healthy contribution.

@Trott
Copy link
Member

Trott commented Apr 3, 2018

@Trott
Copy link
Member

Trott commented Apr 3, 2018

@willhayslett It looks like a new lint rule landed recently and there are a few comments in this PR that need a space after //. Would you mind adding them? Sorry about the delay in getting reviews on this. Otherwise, that probably wouldn't have happened. FWIW, these changes look good to me at a quick glance, but I'd rather get someone who has worked on the fs promises implementation to give it a closer review if possible.

}

async function validateAppendString() {
//don't refresh the directory
Copy link
Member

Choose a reason for hiding this comment

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

Linter now requires a space after //.


const filePath = path.resolve(tmpDir, 'tmp-chmod.txt');
const fileHandle = await open(filePath, 'w+', 0o644);
//file created with r/w 644
Copy link
Member

Choose a reason for hiding this comment

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

Same here.

//file created with r/w 644
const statsBeforeMod = fs.statSync(filePath);
assert.deepStrictEqual(statsBeforeMod.mode & 0o644, 0o644);
//change the permissions to 765
Copy link
Member

Choose a reason for hiding this comment

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

And here.


const filePathForHandle = path.resolve(tmpDir, 'tmp-write-file.txt');
const fileHandle = await open(filePathForHandle, 'w+');
const buffer = Buffer.from(''); //empty buffer
Copy link
Member

Choose a reason for hiding this comment

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

And here too, probably.

@willhayslett willhayslett force-pushed the test-fs-promises-file-handle branch from 6a62939 to f8daeb9 Compare April 3, 2018 05:55
@willhayslett
Copy link
Contributor Author

Thanks for the feedback, @Trott. I've updated the tests to conform to the new rules.

@Trott
Copy link
Member

Trott commented Apr 3, 2018

@Trott
Copy link
Member

Trott commented Apr 3, 2018

@willhayslett CI failures! Might require some digging to figure these out. Could be fun! Or frustrating! Let's see...

These tests are failing consistently on two platforms: Windows and Raspberry Pi

So, here's the test failing on a Raspberry Pi:

https://ci.nodejs.org/job/node-test-binary-arm/114/RUN_SUBSET=1,label=pi1-docker/console

10:44:41 not ok 81 parallel/test-fs-promises-file-handle-read
10:44:41   ---
10:44:41   duration_ms: 3.72
10:44:41   severity: fail
10:44:41   stack: |-
10:44:41     (node:28170) ExperimentalWarning: The fs/promises API is experimental
10:44:41     /home/iojs/build/workspace/node-test-binary-arm/test/common/index.js:785
10:44:41                  (err) => process.nextTick(() => { throw err; }));
10:44:41                                                    ^
10:44:41     
10:44:41     Error: ENOTEMPTY: directory not empty, rmdir '/home/iojs/tmp/.tmp.0'
10:44:42         at Object.fs.rmdirSync (fs.js:788:3)
10:44:42         at rmdirSync (/home/iojs/build/workspace/node-test-binary-arm/test/common/tmpdir.js:48:10)
10:44:42         at rimrafSync (/home/iojs/build/workspace/node-test-binary-arm/test/common/tmpdir.js:18:7)
10:44:42         at Object.exports.refresh (/home/iojs/build/workspace/node-test-binary-arm/test/common/tmpdir.js:65:3)
10:44:42         at validateEmptyRead (/home/iojs/build/workspace/node-test-binary-arm/test/parallel/test-fs-promises-file-handle-read.js:32:10)
10:44:42   ...

The oddity with Raspberry Pi is that (I think) the tmp directory is NFS mounted. In general, we don't call tmpdir.refresh() twice in one test (AFAIK). We should be able to, though.

Windows failure looks like this:

https://ci.nodejs.org/job/node-test-binary-windows/16187/COMPILED_BY=vs2017,RUNNER=win2008r2-vs2017,RUN_SUBSET=0/console

not ok 141 parallel/test-fs-promises-file-handle-chmod
  ---
  duration_ms: 0.323
  severity: fail
  stack: |-
    (node:2892) ExperimentalWarning: The fs/promises API is experimental
    c:\workspace\node-test-binary-windows\test\common\index.js:785
                 (err) => process.nextTick(() => { throw err; }));
                                                   ^
    
    AssertionError [ERR_ASSERTION]: 436 deepStrictEqual 501
        at validateFilePermission (c:\workspace\node-test-binary-windows\test\parallel\test-fs-promises-file-handle-chmod.js:27:10)
  ...

I haven't looked closely. This may be an OS limitation, or it may be an actual bug in the fs/promises.js implementation, or something else...

Copy link
Member

@Trott Trott left a comment

Choose a reason for hiding this comment

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

I'm leaving a "Request changes" just to make sure that no one lands this before the CI issues are fixed.

@Trott
Copy link
Member

Trott commented Apr 3, 2018

@willhayslett One thing you can do, if you want, is submit each new test in a separate pull request. Then, any that pass can land. And any that fail can be worked on individually. Or if you'd rather keep them as one bundle, that's fine too. Either way. Whatever works for you.

@Trott
Copy link
Member

Trott commented Apr 3, 2018

Windows fix is probably to use common.isWindows to check the platform and assign the expected value appropriately in (or right before) this line.

@Trott
Copy link
Member

Trott commented Apr 3, 2018

Windows fix is probably to use common.isWindows to check the platform and assign the expected value appropriately in (or right before) this line.

Although I'm not sure that it makes sense that the mode wouldn't come back the same as it does on POSIX. @nodejs/platform-windows @nodejs/fs @nodejs/testing

@willhayslett
Copy link
Contributor Author

On it @Trott!

@willhayslett willhayslett force-pushed the test-fs-promises-file-handle branch from f8daeb9 to b461f0a Compare April 4, 2018 06:24
@willhayslett
Copy link
Contributor Author

Hi @Trott, when you can, please run the CI tests again.

Also, is there a way I can execute them on my end, or otherwise test against each of the supported platforms?

Thanks!

}

async function validateAppendString() {
// don't refresh the directory
Copy link
Member

Choose a reason for hiding this comment

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

As is, this gives me mild pause. Can you:

  • Remove this comment
  • Move the tmpdir.refresh() in validateAppendBuffer() outside of that function (as it now is initialization for the whole test file, not just that one test case)
  • Maybe change the name of the file on line 32 to file-append-file-string to match this function's name and also so that the two tests do not affect each other.
  • Oh, while at it, it seems that common.crashOnUnhandledRejection() should only be called once for the whole test file so move that outside of the individual test functions too?

Copy link
Member

Choose a reason for hiding this comment

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

Also, you'll need to make similar changes to test/parallel/test-fs-promises-file-handle-read.js as it was failing the same way in CI as test/parallel/test-fs-promises-file-handle-append-file.js was. I provided test/parallel/test-fs-promises-file-handle-append-file.js as an example.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Got it. I didn't realize those common methods were to only be used once per file. I placed their calls outside of the functions. Also updated test/parallel/test-fs-promises-file-handle-append-file.js so the validateAppendString test is cleaner. Let me know if any additional changes are needed.

Working to increase test code coverage for fs/promises.js.
Added tests for fileHandle.appendFile and fileHandle.chmod.
Updated and added tests for fs/promises fileHandle. Changes
include updates to chmod and appendFile. New tests were created
for the read, readFile, write, and writeFile methods.
Updated fs/promises fileHandle tests. Removed indirect assertions
that compared data between the old fs methods and those being tested
in favor of more direct comparisons between the tested methods'
output and the file input data.
Tests were updated to conform to the new linting rules
that were landed.
Updated fs/promises fileHandle tests to resolve CI build test
errors being returned from Windows and Rasberry Pi.
Updated tests to ensure common.crashOnUnhandledRejection()
and the common/tmpdir refresh method and are only being called
once per file.
@willhayslett willhayslett force-pushed the test-fs-promises-file-handle branch from b461f0a to 5310f92 Compare April 4, 2018 12:01
@Trott
Copy link
Member

Trott commented Apr 4, 2018

@willhayslett
Copy link
Contributor Author

CI test failures again. Looks like it's from another piece of code though I'm not entirely sure.

/home/iojs/build/workspace/node-test-commit-aix/nodes/aix61-ppc64/test.tap:
not ok 717 parallel/test-http-client-timeout-agent```

@Trott
Copy link
Member

Trott commented Apr 4, 2018

@willhayslett Yes, that looks unrelated. I've opened an issue (#19804) and will re-run for this PR.

Re-run: https://ci.nodejs.org/job/node-test-commit-aix/13902/

@Trott
Copy link
Member

Trott commented Apr 5, 2018

Landed in 126b03e. Thanks, @willhayslett!

Trott pushed a commit to Trott/io.js that referenced this pull request Apr 5, 2018
Working to increase test code coverage for fs/promises.js.
Added tests for fileHandle.appendFile and fileHandle.chmod.

PR-URL: nodejs#19605
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Rich Trott <[email protected]>
@Trott Trott closed this Apr 5, 2018
@willhayslett
Copy link
Contributor Author

Great! Thank you, @Trott!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
test Issues and PRs related to the tests.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants