test: modernize JS in some test-fs-*.js #23031

jy95 · 2018-09-22T21:00:57Z

Checklist

make -j4 test (UNIX), or vcbuild test (Windows) passes
tests and/or benchmarks are included
documentation is changed or added
commit message follows commit guidelines

Description

Replaced several variable initialization with spread / forEach / Object.assign(...Object.entries(obj).map()) .

Trott

Hi, @jy95! Welcome and thanks for the pull request.

Most of these changes are 👍 but I'm not sure about the .map() usages for assigning constants because:

It makes the code less readable/maintainable. (Example: The use of .map() in test-fs-access.js makes that code more difficult to understand and maintain for no discernible benefit.)
It makes it more difficult to introduce block scoping of these constants for individual test cases. (Example: test-fs-append-file-sync.js changes. I'd much rather see each variable block scoped to just the test case that needs it but using .map() to assign them all at the outset prevents that.)

Would you consider removing those or at least moving them to a separate pull request so that they can be considered/discussed separately and the more straightforward changes (like introducing the ternary in test-fs-open-mode-mask.js to make it possible to make mode a constant) can be merged separately?

jy95 · 2018-09-23T09:24:29Z

I removed them : I only keep the ternary way because I think it is more clear in that way ^^

tniessen · 2018-09-23T09:40:46Z

test/parallel/test-fs-access.js

@@ -13,10 +13,12 @@ const { internalBinding } = require('internal/test/binding');
 const { UV_ENOENT } = internalBinding('uv');

 const tmpdir = require('../common/tmpdir');
+


Nit: Unrelated whitespace change.

Oups : fixed

tniessen · 2018-09-23T09:40:52Z

test/parallel/test-fs-access.js

 const doesNotExist = path.join(tmpdir.path, '__this_should_not_exist');
 const readOnlyFile = path.join(tmpdir.path, 'read_only_file');
 const readWriteFile = path.join(tmpdir.path, 'read_write_file');

+


Oups : fixed

tniessen · 2018-09-23T09:42:31Z

test/parallel/test-fs-open-mode-mask.js

@@ -7,13 +7,8 @@ const assert = require('assert');
 const path = require('path');
 const fs = require('fs');

-let mode;
+const mode = (common.isWindows) ? 0o444 : 0o644;


Nit: Parentheses unnecessary.

I know that they are not necessary for simple case (like this one). ESLint didn't remove them

Trott · 2018-09-23T15:32:00Z

Thanks! One other thing: Can you also leave the fiilename2 etc. declarations where they are in that one file? By moving them to the top,it makes block-scoping less obvious.

devsnek · 2018-09-23T15:35:47Z

test/parallel/test-fs-open-flags.js

-const O_TRUNC = fs.constants.O_TRUNC || 0;
-const O_WRONLY = fs.constants.O_WRONLY || 0;
+// 0 if not found in fs.constants
+const { O_APPEND = 0, O_CREAT = 0, O_EXCL = 0, O_RDONLY = 0, O_RDWR = 0,


Can you keep these each on separate lines?

const { O_APPEND = 0, O_CREAT = 0, ... } = fs.constants;

Ok for readability : I will change

devsnek · 2018-09-23T15:36:01Z

test/parallel/test-fs-stat-bigint.js

-        bigintStats.isSymbolicLink(),
-        numStats.isSymbolicLink()
-      );
+      ['isBlockDevice', 'isCharacterDevice', 'isDirectory', 'isFIFO', 'isFile',


separate lines

You mean one line for each item of the array ? Sure if you want

devsnek · 2018-09-23T15:36:10Z

test/parallel/test-fs-copyfile.js

-assert.strictEqual(typeof UV_FS_COPYFILE_FICLONE, 'number');
-assert.strictEqual(typeof UV_FS_COPYFILE_FICLONE_FORCE, 'number');
+[COPYFILE_EXCL, COPYFILE_FICLONE, COPYFILE_FICLONE_FORCE, UV_FS_COPYFILE_EXCL,
+ UV_FS_COPYFILE_FICLONE, UV_FS_COPYFILE_FICLONE_FORCE]


separate lines

Same that above : I will change

jy95 · 2018-09-23T15:42:43Z

@Trott You mean : put them in their original place ? Sorry but I don't see the problem with the current block-scoping ... I will still change it as someone agreed with you :)

Hope I succeed my first commit squashing after these changes ^^

Trott · 2018-09-23T16:01:13Z

@jy95 What I mean is that if we want to add block scoping for the individual test cases inside the file (and we do), then the declarations will have to be in separate blocks. The declarations will have to be where they are now, basically. So we'll just end up moving them back.

Trott · 2018-09-23T16:01:49Z

(By the way, if you want to block scope each of the test cases in that file, go for it.)

jy95 · 2018-09-23T16:38:36Z

I don't think it will be useful for this file ...

BridgeAR

I am not convinced about these changes as they decrease the readability in an error case when changing the individual assertions to an array.

Each assertion will currently show the line in the stack trace but when changing it to an array, we have to add extra information to the output to know what entry actually failed.

BridgeAR · 2018-09-23T20:53:48Z

@jy95 thanks a lot for the PR! There is definitely a lot of code that needs cleanup, I am just not sure that all of these changes will actually lead to the better. I do like the destructuring though :)

jy95 · 2018-09-23T21:21:27Z

It is also possible to add a custom message using the forEach parameter index ;

[fs.F_OK, fs.R_OK, fs.W_OK, fs.X_OK].forEach(
  (cons) => assert.strictEqual(typeof cons, 'number', 
                   `The foreach test for fs constants for index: ${index}`)
);

or using Object.entries :

Object.entries(
    { 'fs.F_OK'  : fs.F_OK , 'fs.R_OK': fs.R_OK, 'fs.W_OK': fs.W_OK, 'fs.X_OK': fs.X_OK  }
).forEach(
   ([varName,val]) => assert.strictEqual(typeof val, 'number', `Test failed for fs.${varName}`)
)

Notice : There is maybe a way to create the object automatically if there exist a function to get javascript variable name ...

BridgeAR · 2018-09-23T21:38:38Z

@jy95 I am aware that it's possible to add a message property and if the test would have done that originally, I would have signed off on it (in case it would not only contain the index but also the actual difference of the assertion). Changing it now does not seem to improve anything as the actual code is more difficult to read and not a lot of code lines are reduced this way.

jy95 · 2018-09-24T17:56:06Z

For the moment, I only verified +/- 20 test files but what I saw, generic function(s) could improve at least readability / maintenance. For example , using a structure like this (first draft : surely there are things that must evolue ) :

{
   // the name you want to see in console log if there is assert error(s) 
   testCaseName: 'Testing Fs constants'
   // The default assert fct that would be invoked
   defaultAssertFct: assert.strictEqual,
   // defaultMessage (hidden param) : it will be an AssertionError with default message
   // '${testCaseName} - The test N°${index} failed' , other parameters will be the same one
   tests: [
       // actual and expected are required , you can override the default message
       {actual : typeof fs.F_OK, expected: 'number', message: 'F_OK failed'},
       // possibility to change assert function (optional, default to defaultAssertFct)
       {actual : 1, expected: 2, assertFct: assert.notDeepStrictEqual},
       // ... other idea can improve this basic design
   ] 
}

Of couse, it is completely up to you to choose how you initialize the tests array following the circumstances ^^ For example , I prefer to write on the readability field :

{
  testCaseName: 'Testing Fs constants',
  defaultAssertFct: assert.strictEqual,
  tests: [fs.F_OK, fs.R_OK, fs.W_OK, fs.X_OK].map( 
     (cons) => {actual: typeof cons, expected: 'number' } 
  )
}

instead of

[fs.F_OK, fs.R_OK, fs.W_OK, fs.X_OK].forEach( 
      (cons) => assert.strictEqual(typeof cons, 'number') 
);

tniessen · 2018-09-25T09:53:41Z

The original version (four separate assertions) seems much more readable than both of these. I'd prefer to use for .... of if we want to iterate, but that's personal preference.

BridgeAR · 2018-09-25T09:57:35Z

I agree with @tniessen and I think it would be best to just revert the assertion changes.

jy95 · 2018-09-25T11:14:21Z

Maybe I will ask review about the feature request (last message) I would like to add inside the assert into a another issue .
After review of your opinion , I will revert the assertion changes in test/parallel/test-fs-copyfile.js and test/parallel/test-fs-access.js.

For the one in test/parallel/test-fs-stat-bigint.js , I disagree about the original : it is quite unreadable in my opinion and from what I saw in the docs , these getters are here from a long time ( v0.1.10) without parameters ...

Trott · 2018-11-22T11:26:42Z

For the one in test/parallel/test-fs-stat-bigint.js , I disagree about the original : it is quite unreadable in my opinion and from what I saw in the docs , these getters are here from a long time ( v0.1.10) without parameters ...

I agree with @tniessen and @BridgeAR that the current version is a bit better from a DAMP-not-DRY perspective.

More concretely, the refactor makes the assertions less useful. In the current test, if an assertion fails, you know exactly why because it's right there in the line of code that failed:

AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:

false !== true

    at verifyStats (/Users/trott/io.js/test/parallel/test-fs-stat-bigint.js:53:14)

Line 53-56 is:

     assert.strictEqual(
        bigintStats.isSocket(),
        numStats.isSocket()
      );

If we instead go with what's in this PR, we won't know that it's the isSocket() check that's failing. We'll just know that one of the properties in the array. We won't know which one.

That can be solved by adding a third argument to assert.strictEqual() that indicates which property is being tested.

I'd greatly prefer those changes be moved to their on PR and we land the improvements here in the other two files.

map() change was removed

jy95 · 2018-11-22T14:05:55Z

Ok : feel free to change it if you prefer that way ...

Trott · 2018-11-28T06:17:14Z

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

Trott · 2018-12-04T12:49:12Z

Resume Build CI: https://ci.nodejs.org/job/node-test-pull-request/19196/

Trott · 2018-12-04T15:48:28Z

Landed in 841caef.

Thanks for the contribution! 🎉

Update test-fs-open-flags to take advantage of destructuring and default values. Update test-fs-open-mode-mask to use a ternary to make use of a constant possible. PR-URL: nodejs#23031 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>

Update test-fs-open-flags to take advantage of destructuring and default values. Update test-fs-open-mode-mask to use a ternary to make use of a constant possible. PR-URL: #23031 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>

Update test-fs-open-flags to take advantage of destructuring and default values. Update test-fs-open-mode-mask to use a ternary to make use of a constant possible. PR-URL: nodejs#23031 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>

Update test-fs-open-flags to take advantage of destructuring and default values. Update test-fs-open-mode-mask to use a ternary to make use of a constant possible. PR-URL: #23031 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>

jy95 added 7 commits September 22, 2018 21:13

test: use ES2017 syntax in test-fs-access

b3adea2

test: use ES2017 syntax in test-fs-append-file-sync

c91bacd

test: use ES2017 syntax in test-fs-copyfile

a8826dc

test: use ES2017 syntax in test-fs-open-flags

3b3f2bf

test: use ES2017 syntax in test-fs-open-mask

52efdf3

test: updated syntax in test-fs-stat-bigint

90d5f02

test: fix missing typeof in test-fs-access

1721b43

nodejs-github-bot added the test Issues and PRs related to the tests. label Sep 22, 2018

Trott previously requested changes Sep 23, 2018

View reviewed changes

test: remove .map variable for initialization variables

29ba8b5

tniessen reviewed Sep 23, 2018

View reviewed changes

test: remove whitespace

be96501

devsnek reviewed Sep 23, 2018

View reviewed changes

jy95 added 2 commits September 23, 2018 17:48

test: separate lines

f45ead2

test: reset test-fs-append-file-sync to previous version

3b9a133

BridgeAR reviewed Sep 23, 2018

View reviewed changes

test: revert assertion changes

7e2ee7b

test: revert changes in test-fs-stat-bigint.js

7f6555e

Trott approved these changes Nov 28, 2018

View reviewed changes

jasnell approved these changes Nov 30, 2018

View reviewed changes

Trott added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Dec 4, 2018

Trott closed this Dec 4, 2018

BridgeAR mentioned this pull request Dec 5, 2018

v11.4.0 proposal #24854

Merged

4 tasks

BethGriggs mentioned this pull request Feb 12, 2019

v10.15.3 proposal #26063

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

test: modernize JS in some test-fs-*.js #23031

test: modernize JS in some test-fs-*.js #23031

jy95 commented Sep 22, 2018

Trott left a comment

jy95 commented Sep 23, 2018

tniessen Sep 23, 2018

jy95 Sep 23, 2018

tniessen Sep 23, 2018

jy95 Sep 23, 2018

tniessen Sep 23, 2018

jy95 Sep 23, 2018 •

edited

Loading

Trott commented Sep 23, 2018

devsnek Sep 23, 2018

jy95 Sep 23, 2018

devsnek Sep 23, 2018

jy95 Sep 23, 2018

devsnek Sep 23, 2018

jy95 Sep 23, 2018

jy95 commented Sep 23, 2018 •

edited

Loading

Trott commented Sep 23, 2018

Trott commented Sep 23, 2018

jy95 commented Sep 23, 2018 •

edited

Loading

BridgeAR left a comment

BridgeAR commented Sep 23, 2018

jy95 commented Sep 23, 2018 •

edited

Loading

BridgeAR commented Sep 23, 2018

jy95 commented Sep 24, 2018 •

edited

Loading

tniessen commented Sep 25, 2018

BridgeAR commented Sep 25, 2018

jy95 commented Sep 25, 2018

Trott commented Nov 22, 2018

jy95 commented Nov 22, 2018

Trott commented Nov 28, 2018

Trott commented Dec 4, 2018

Trott commented Dec 4, 2018 •

edited

Loading

		@@ -13,10 +13,12 @@ const { internalBinding } = require('internal/test/binding');
		const { UV_ENOENT } = internalBinding('uv');

		const tmpdir = require('../common/tmpdir');

test: modernize JS in some test-fs-*.js #23031

test: modernize JS in some test-fs-*.js #23031

Conversation

jy95 commented Sep 22, 2018

Checklist

Description

Trott left a comment

Choose a reason for hiding this comment

jy95 commented Sep 23, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jy95 Sep 23, 2018 • edited Loading

Choose a reason for hiding this comment

Trott commented Sep 23, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jy95 commented Sep 23, 2018 • edited Loading

Trott commented Sep 23, 2018

Trott commented Sep 23, 2018

jy95 commented Sep 23, 2018 • edited Loading

BridgeAR left a comment

Choose a reason for hiding this comment

BridgeAR commented Sep 23, 2018

jy95 commented Sep 23, 2018 • edited Loading

BridgeAR commented Sep 23, 2018

jy95 commented Sep 24, 2018 • edited Loading

tniessen commented Sep 25, 2018

BridgeAR commented Sep 25, 2018

jy95 commented Sep 25, 2018

Trott commented Nov 22, 2018

jy95 commented Nov 22, 2018

Trott commented Nov 28, 2018

Trott commented Dec 4, 2018

Trott commented Dec 4, 2018 • edited Loading

jy95 Sep 23, 2018 •

edited

Loading

jy95 commented Sep 23, 2018 •

edited

Loading

jy95 commented Sep 23, 2018 •

edited

Loading

jy95 commented Sep 23, 2018 •

edited

Loading

jy95 commented Sep 24, 2018 •

edited

Loading

Trott commented Dec 4, 2018 •

edited

Loading