test: improve code coverage for streams/duplexify

[ErickWendel]

Improve code coverage for streams duplexify.js

Refs:

• Ensure that isDuplexNodeStream was called
• Ensure that Duplexify works for blobs
• Ensure that given a promise rejection it emits an error
• Ensure that given a promise rejection on an async function it emits an error
• Ensure that Duplexify throws an Invalid return value when the function is void
• Ensure data if a subobject has a readable stream it's duplexified
• Ensure data if a subobject has a writable stream it's duplexified
• Ensure data if a subobject has a writable and readable stream it's duplexified
• Ensure that given readable stream that throws an error it calls destroy
• Ensure that given writable stream that throws an error it calls destroy

I would add that those lines are unreachable:

• duplexify.js.html#L71: We already validated all types of streams it'll never call the isNodeStream function
• duplexify.js.html#L199: all data types were checked on the previous statements. The only values that could throw here would be primitive values but the assert won't let it run.
• duplexify.js.html#L161: it'll never be undefined as the statement checks if typeof body?.readable === 'object'
• duplexify.js.html#L166: it'll never be undefined as the statement checks if typeof body?.writable === 'object'

In those cases, what could I do to cover it?

[Trott]

If we have to use --expose-internals then that's fine, but it would be preferable if there was a way to cover the lines using public APIs.

[Trott]

If we have to use --expose-internals then that's fine, but it would be preferable if there was a way to cover the lines using public APIs.

(We can also land this and try to refactor things later to use public APIs where possible.)

[Trott]

In those cases, what could I do to cover it?

If could is unreachable, you can delete it. If you want to be cautious, you can replace it with an internal assertion. (https://github.com/nodejs/node/blob/e46c680bf2b211bbd52cf959ca17ee98c7f657f5/lib/internal/cluster/shared_handle.js is an example of something that uses the internal assertion.)

[ErickWendel]

If we have to use --expose-internals then that's fine, but it would be preferable if there was a way to cover the lines using public APIs.

Just updated it using Public APIs

[ErickWendel]

In those cases, what could I do to cover it?

If could is unreachable, you can delete it. If you want to be cautious, you can replace it with an internal assertion. (https://github.com/nodejs/node/blob/e46c680bf2b211bbd52cf959ca17ee98c7f657f5/lib/internal/cluster/shared_handle.js is an example of something that uses the internal assertion.)

Perfect, I'll create another PR to land this, ok?

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[nodejs-github-bot]

Landed in 0185464

[danielleadams]

@ErickWendel this breaks tests when landing in v16.x-staging. Do you mind creating a backport PR for the v16.x line? Thank you

[ErickWendel]

@ErickWendel this breaks tests when landing in v16.x-staging. Do you mind creating a backport PR for the v16.x line? Thank you

Heyy. Sure! Do you have an example of how to do it? I'm not sure if it's just to make it works on the v16.x