I think that's going too far. The VNC and VNC_Vncconnect cases are very different codepaths.
I think it'd be okay to merge VNC and VNC_Password and just require the testing to include use of a password.
OK, at least merging these two seems like a no-brainer to me. I'll leave the password optional, because that way both options get tested eventually.
But Vncconnect should remain separate. We could consider dropping it from being a blocking test, though. I'm not sure we actually need to block release on the vnc connect functionality, though there may be some reason to. Is anyone aware of the use cases for the vncconnect functionality and how critical they are?
I think the main use case is if you want to install a machine behind a firewall, and you have a public IP. Whether that is critical enough to block the release or not, I do not know.
Anyone else has an opinion on that?