The changes look good, but we have to make sure that there's at least another test that checks that listening on a specific port on a tls.Server object works. If that's the case LGTM, otherwise we will have to keep this test so we have this specific code path covered. See this text from the writing_tests guide:

If the test doesn't depend on a specific port number then always use 0 instead of an arbitrary value, as it allows tests to be run in parallel safely, as the operating system will assign a random port. If the test requires a specific port, for example if the test checks that assigning a specific port works as expected, then it is ok to assign a specific port number.

we have to make sure that there's at least another test that checks that listening on a specific port on a tls.Server object works.

I think that test-net-server-bind.js seems to be an appropriate one. It checks 3 static ports incrementally. We can mark it as a test of static ports in the comment.

I think that test-net-server-bind.js seems to be an appropriate one. It checks 3 static ports incrementally. We can mark it as a test of static ports in the comment.

I'm fine with that but I wonder if having a test that actually covers a tls.Server instance calling listen on a specific port makes also sense. Or considering that tls.Server inherits from net.Server test-net-server-bind is enough. If the latter, LGTM.

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

Landed in 31d1a3f. Thank you!