Suggest using Save-Module rather than Install-Module
The current script installs the module to the build slave. This can be troublesome because it requires administrative access and could potentially impact the build slave which is an issue if the same environment is re-used in unit testing. Using Save-Module to the current user profile and then deleting the folder on cleanup would be a nice approach.
Sounds reasonable to me.
Looking at this issue, I see that there is only one place where Install-Module is run in tests, that are meant to be run by a user. All other locations are meant to be run in AppVeyor only, or in a container that is only present for the test run.
One place that Install-Module is used is in the Meta.Tests.ps1. It calls Install-DependentModule which in turn calls Install-Module and installs in the CurrentUser scope. Meta.Tests.ps1 could be run by a user.
https://github.com/PowerShell/DscResource.Tests/blob/a9b9d87e2f056720a964ec93c8a9cb4181487a64/Meta.Tests.ps1#L628-L634
So what we could do is make the Install-DependentModule helper function return the modules and the version that was installed, so we can remove that version, or the entire module, if that was the only version. We can't always remove the entire folder, because the user might have the dependent module installed already.
@PlagueHO what is your opinion on this today? Is this worth solving, and to what extent?
This one goes back quite some time! :grin:
Perhaps we could just install the module to the local scope if they aren't installed (or an older version is installed).
But, we could also look at using a module like PSDepend to start managing these dependencies. Although of course the PSDepend module still needs to be bootstrapped.