All AppInstallcerCLIE2ETests fail with the same message: "Access to the registry key ... AppModelUnlock ... is denied."

[kindrowboat]

Hello friends,

I am trying to get my local development environment set up, and while the code compiles and runs, all 67 of the end-to-end tests fail with the same message, similar to this one:

Test Name:	DisplayFeatures
Test FullName:	AppInstallerCLIE2ETests.AppInstallerCLIE2ETests.FeaturesCommand.DisplayFeatures
Test Source:	C:\Users\kindr\Source\Repos\winget-cli\src\AppInstallerCLIE2ETests\FeaturesCommand.cs : line 27
Test Outcome:	Failed
Test Duration:	0:00:00

Test Name:	DisplayFeatures
Test Outcome:	Failed
Result Message:	OneTimeSetUp: System.UnauthorizedAccessException : Access to the registry key 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock' is denied.

The line that's triggering the exception is: src\AppInstallerCLIE2ETests\SetUpFixture.cs(130).

I'm relatively new to Windows development, especially with Visual Studios, so I may be missing something obvious. I have followed all the steps in the README.md under "Building the client>Prerequisites" including enabling Developer Mode. I can also confirm that the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock exists (though I dared not tamper with the permissions.) I'm running the latest build of Windows in the stable channel:

Edition	Windows 10 Pro
Version	20H2
Installed on	‎2021-‎02-‎25
OS build	19042.867
Experience	Windows Feature Experience Pack 120.2212.551.0

Any help is appreciated!

[JohnMcPMS]

These tests are built to run on the build servers, and so expect to set up everything themselves. This requires Admin permissions to do, and in order to run them locally you will need to run VS as Admin. There is a README in the root of the E2E tests directory as well that should help: https://github.com/microsoft/winget-cli/tree/master/src/AppInstallerCLIE2ETests

Alternately, you can be lazy like myself and not bother running them until they fail in the build. They take much longer to run than the unit tests and often have build server specific issues anyway, as well as the difficult setup, so I have optimized for that path. I may be a special case though, being so entrenched in the project. I certainly understand the desire to ensure that things are running smoothly before you start changes on an unfamiliar project.

[kindrowboat]

Thanks for the explaination and pointing me to the readme. When submitting a PR with a new feature, would you expect a new e2e tests or just new unit tests?

[JohnMcPMS]

It depends on the feature, but for zip package handling I would expect new E2E test(s). I do prefer as much testing as possible be done in the unit tests, but having some smoke testing in the E2E is good too. I think it is especially needed to ensure that things are working correctly with regards to where files are placed and registry updates, because of how being inside a package works.