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: increase test-crypto.js strictness #10784

Closed
wants to merge 4 commits into from
Closed

Conversation

Trott
Copy link
Member

@Trott Trott commented Jan 13, 2017

Confirm that getCiphers() contains no duplicates.

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

test crypto tls

@Trott Trott added crypto Issues and PRs related to the crypto subsystem. test Issues and PRs related to the tests. tls Issues and PRs related to the tls subsystem. labels Jan 13, 2017
}

// Assume that we have at least AES-128-CBC.
assert.notStrictEqual(0, crypto.getCiphers().length);
Copy link
Member

Choose a reason for hiding this comment

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

Any reason for removing this?

Copy link
Contributor

Choose a reason for hiding this comment

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

Without this, getCiphers() could return [], and the test would pass, because the empty set is sorted and unique.

Copy link
Member Author

Choose a reason for hiding this comment

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

Without this, getCiphers() could return [], and the test would pass, because the empty set is sorted and unique.

The test will fail because the very next line requires that the array includes aes-128-cbc as an element. So it can't be length 0. So the zero-length check seems redundant to me.

Although looking more closely, I suppose it's possible that getCiphers() would return different arrays each time called. (That would be a bug, but that's the point of tests.) So I should probably assign the result to a variable before all the asserts. Maybe even throw in another call to getCiphers() at the end and confirm that the array it returns is identical to the one it returned in the first place.

Copy link
Contributor

Choose a reason for hiding this comment

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

That is reasonably compelling, though an extra assert to be explicit about the condition isn't bad. As you wish, I'm OK either way.

Copy link
Member Author

Choose a reason for hiding this comment

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

Eh, well, two people asked "why did you take this out?" and it isn't hurting anything, so maybe best to leave it in after all. I'll put it and the others back.

exports.getCiphers = internalUtil.cachedResult(() => {
return internalUtil.filterDuplicateStrings(binding.getSSLCiphers(), true);
});
exports.getCiphers = internalUtil.cachedResult(
Copy link
Contributor

Choose a reason for hiding this comment

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

Unrelated change. I don't object to cleaning up lib/'s use of rocket functions, but I think they should be standalone commits, ideally a standalone commit per file that makes every use in the file consistent (this might or might not be the only such usage, I can't tell from the diff, and the commit message doesn't even mention that there is any cleanup occuring) or just to the entire lib directory to clean up a specific usage aspect.

I also don't think commits called test: ... should touch lib, unless the lib change really clearly is something needed to support the test code (an example might be exporting an internal so that it can be directly used in a unit test)

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, I'll claim a combination of being tired when I did this, multi-tasking too much, and/or just being lazy. The change originally started in tls.js and morphed into fixing up the test. When the morphing was complete, I shouldn't have included this now-unrelated change. I'll remove it.

assert.deepStrictEqual(list, sorted);
// list is sorted and contains no duplicates
assert(list.every(
(val, index, array) => index === array.length - 1 || val < array[index + 1]
Copy link
Contributor

Choose a reason for hiding this comment

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

While it works as commented, this is a pretty obfuscated way of doing both a sorted test and a uniqueness test in a single statement. I prefer the approach in

function unique(groups) {
return [...new Set(groups)].sort();
}
, though in hind-sight, maybe that unique() function should not also be sorting. Maybe unique() should be in test/common.js?

Copy link
Member Author

Choose a reason for hiding this comment

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

I'll rework it to try to make it a bit more clear what's going on.

}

// Assume that we have at least AES-128-CBC.
assert.notStrictEqual(0, crypto.getCiphers().length);
Copy link
Contributor

Choose a reason for hiding this comment

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

Without this, getCiphers() could return [], and the test would pass, because the empty set is sorted and unique.

}

// Assume that we have at least AES-128-CBC.
assert.notStrictEqual(0, crypto.getCiphers().length);
Copy link
Contributor

Choose a reason for hiding this comment

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

That is reasonably compelling, though an extra assert to be explicit about the condition isn't bad. As you wish, I'm OK either way.

@Trott
Copy link
Member Author

Trott commented Jan 13, 2017

@sam-github I think I've addressed your comments. PTAL.

I'll want to expand this test a bit more as I think I've discovered an unexpected behavior, but one thing at a time...

@jasnell
Copy link
Member

jasnell commented Jan 15, 2017

@italoacasas
Copy link
Contributor

Landed e21126d

italoacasas pushed a commit that referenced this pull request Jan 16, 2017
Confirm that `getCiphers()` contains no duplicates.

PR-URL: #10784
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
italoacasas pushed a commit to italoacasas/node that referenced this pull request Jan 18, 2017
Confirm that `getCiphers()` contains no duplicates.

PR-URL: nodejs#10784
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
italoacasas pushed a commit to italoacasas/node that referenced this pull request Jan 23, 2017
Confirm that `getCiphers()` contains no duplicates.

PR-URL: nodejs#10784
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
italoacasas pushed a commit to italoacasas/node that referenced this pull request Jan 25, 2017
Confirm that `getCiphers()` contains no duplicates.

PR-URL: nodejs#10784
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
italoacasas pushed a commit to italoacasas/node that referenced this pull request Jan 27, 2017
Confirm that `getCiphers()` contains no duplicates.

PR-URL: nodejs#10784
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
@italoacasas italoacasas mentioned this pull request Jan 29, 2017
MylesBorins pushed a commit that referenced this pull request Mar 8, 2017
Confirm that `getCiphers()` contains no duplicates.

PR-URL: #10784
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
MylesBorins pushed a commit that referenced this pull request Mar 9, 2017
Confirm that `getCiphers()` contains no duplicates.

PR-URL: #10784
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
@MylesBorins MylesBorins mentioned this pull request Mar 9, 2017
@Trott Trott deleted the tls branch January 13, 2022 22:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
crypto Issues and PRs related to the crypto subsystem. test Issues and PRs related to the tests. tls Issues and PRs related to the tls subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants