Honestly, that's not the behavior I'd have expected...

Buffer.from() is not defined by documentation for any ArrayBufferView except for Uint8Array and Buffer.

I agree that it's not what anyone would expect. There were related bugs in node and undici, and who knows how many similar bugs in ecosystem.

Not sure if this test was intentional or not, so probably it shouldn't be removed for now, just marked with a comment.
I'll add uint8-based test in case this is what was intended.

This test looks like it might be using Uint16Array intentionally. There are a couple of ways to work around this issue (for example, use buf.toString() instead of Buffer.from(buf).toString('hex') or use Buffer.from(buf.buffer)), but it seems to me that this test is performing the exact same test as the loop above for ctor === Uint16Array. So I'd suggest removing this block (line 50 to 56) entirely.

I'm not sure if I understand a potential intention here. Using Uint16Array in context of this method makes sense in terms of generating random utf16 strings (i.e. String.fromCharCode(...crypto.getRandomValues(new Uint16Array(charLength)))) but it's probably not worth testing explicitly.

Technically, this test was worse than ctor === Uint16Array above, as it tested only 10 bytes out of 20 generated. :)

I agree that at this point it doesn't serve any purpose. Documentation allows to use instances of Buffer and the test for it was lacking, so I guess Buffer.alloc(10) will make it useful.