Will add a test in a few mins.

@vors @lzybkr From reading the code, I feel it's fine to swap the order of calling DoPrepare and assigning myInfo.ExpectingInput, but I would need to run all tests to verify. If you know something that will obviously be broken by this change, please let me know.

stty may not be on the Travis CI build. I will come up with a more robust test. Never mind, my typos caused the test failures. I will run all tests in both Linux and Windows to verify if swapping the order breaks anything.

I have ran all tests on Linux, there were 2 failures, and they are related to Get-PackageProvider and Register-PackageSource. This was because I didn't specify -PSModuleRestore when building and thus I don't have PackageManagement and PowerShellGet modules installed.

So Linux test run was good.

OK, finally finished running all tests on windows and analyzing the failures. There are 8 test failures:

1. SSH Remoting API Tests.SSHConnectionInfo should throw file not found exception for invalid key file path -- ssh.exe is not available on my test machine
2. 4 failures in Get-ComputerInfo tests for properties: DeviceGuardAvailableSecurityProperties, DeviceGuardRequiredSecurityProperties, DeviceGuardSecurityServicesConfigured, DeviceGuardSecurityServicesRunning -- somehow there is no value for them on my test VM, which is WS2016.
3. "Set-Date should be able to set the date in an elevated context" -- Set-Date fails even in elevated session because NativeMethods.SetLocalTime(ref systemTime) fails in SetDateCommand.ProcessRecord. It may be due to the test machine is a VM. Set-Date doesn't work well with VMs.
4. Register-PackageSource and Get-PackageProvider cannot be found -- PackageManagement related.

None of the failures is related to swapping the order of DoPrepare and assigning myInfo.ExpectingInput. So Windows test run was good.