System Environment variable PSModulePath shouldn't be updated for unit tests about dscresource.tests HOT 11 CLOSED

@PlagueHO Yes please, we could improve the logic to find module root.

from dscresource.tests.

Aha! I wondered why this was happening. Gradually, it takes longer and longer to start a PowerShell session when autoloading modules - due to the hundreds of entries in the PSModulePath. Good catch :)

from dscresource.tests.

Thanks for logging this @rchaganti - appreciate it!

I totally agree, this is definitely a problem and needs to be fixed ASAP! Thanks for investigating it.

The original test methodolgy was to move the module to the existing PSModulePath folder, but this introduced it's own issues:

1. If the same module already existed on the test machine in the PSModulePath then the existing version(s) would first have to be moved out to a temporary location before being tested. This becomes more complex when multiple different versions exist.
2. If the unit tests were terminated by the user then the content of the PSModulePath would be left in an unknown state.

So reverting to the original process (moving the module toPSModuleRoot) might not be the ideal solution either. I'd say the path detection needs to be fixed primarily - so that in your case c:\Temp is set as the path rather than C:\ .

The existing Unit/Integration test templates are all wrapped in a try/catch/finally block with the finally block calling the Restore-TestEnvironment function. This was intended to preserve the environment no matter what occurred - if it isn't managing this then that needs to be fixed as well.

@tysonjhayes - have you got any thoughts on this one?

from dscresource.tests.

Looking at the code it seems to me that the problem might be that the detection method used to detect the root folder of the module could be at fault. Specifically one of these two lines:
https://github.com/PowerShell/DscResource.Tests/blob/dev/DscResourceTestHelper/TestHelper.psm1#L322
https://github.com/PowerShell/DscResource.Tests/blob/dev/DscResourceTestHelper/TestHelper.psm1#L325

@rchaganti - are you able to specify which Resource module you were testing?

from dscresource.tests.

This happened while I was testing xVMNetworkAdapter resource that I pushed to xHyper-V.

from dscresource.tests.

@PlagueHO why can't we simply rename the target folder if there is a name conflict and copy the new one that we need to run tests on? And, in the clean up code, we can restore the original name.

from dscresource.tests.

This is for the PR I submitted in xHyper-V. The resource is xVMNetworkAdapter.

Get Outlook for Androidhttps://aka.ms/ghei36

On Wed, May 18, 2016 at 1:18 AM -0700, "Daniel Scott-Raynsford" <[email protected]mailto:[email protected]> wrote:

Looking at the code it seems to me that the problem might be that the detection method used to detect the root folder of the module could be at fault. Specifically one of these two lines:
https://github.com/PowerShell/DscResource.Tests/blob/dev/DscResourceTestHelper/TestHelper.psm1#L322
https://github.com/PowerShell/DscResource.Tests/blob/dev/DscResourceTestHelper/TestHelper.psm1#L325

@rchagantihttps://github.com/rchaganti - are you able to specify which Resource module you were testing?

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHubhttps://github.com//issues/55#issuecomment-219957604

from dscresource.tests.

@rchaganti
So your folder structure was
C:\temp\xHyper-v\DscResources\xVMNetworkAdapter ?
If that's the case then indeed we should have added C:\temp to the PSModulePath, not the C:\ ,so the culprit may be what @dcrreynolds pointed at.

Simply renaming the folder in case of the conflict won't work since if you interrupt tests we will be left with the renamed folder - we are already unwinding our changes to PSModulePath in the finally block and looks like it doesn't work the way we expect, that's another area to investigate though.

from dscresource.tests.

@rchaganti - I found the problem. Your Unit tests must be in a sub folder called Unit if you're using the standard test templates.

So you should have a path like this:
/Tests/Unit/MSFT_xVMNetworkAdapter.tests.ps1

See xNetworking for an example.

That said, the code should deal with this situation better and perhaps do a better job at detecting the root of the DSC module, so even if the tests are in a path that is not exepected the root would still be detected. This could be done by simply walking up the tree and looking for the right PSD1 file (because we know the name of the Resource module we're in already).

Also, no matter what happens the test code should always return the environment back to it's original state as @KarolKaczmarek mentioned. The only time it might not if it was terminated unexpectedly via a crash or killing the task. I have confirmed that using CTRL+C will still fire the Finally block and return the environment back to normal.

from dscresource.tests.

@KarolKaczmarek - is it worth me making the change I suggested? E.g. so that we locate the Root of the module by walking up the tree from the test file until we find the Resource Module filename?

I'm not sure what we can do about fixing the problem with the environment being reset though.

from dscresource.tests.

Cool - I'll get onto it.

from dscresource.tests.