-
Notifications
You must be signed in to change notification settings - Fork 49
System Environment variable PSModulePath shouldn't be updated for unit tests #55
Comments
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 :) |
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:
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 @tysonjhayes - have you got any thoughts on this one? |
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: @rchaganti - are you able to specify which Resource module you were testing? |
This happened while I was testing xVMNetworkAdapter resource that I pushed to xHyper-V. |
@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. |
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" <notifications@github.commailto:notifications@github.com> 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: @rchagantihttps://github.com/rchaganti - are you able to specify which Resource module you were testing? You are receiving this because you were mentioned. |
@rchaganti 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. |
@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: 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. |
@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. |
@PlagueHO Yes please, we could improve the logic to find module root. |
Cool - I'll get onto it. |
…l-For-Unit-Tests Only integration tests will change the Machine PSModulePath - Fixes #55
The current resource test template updates the PSModulePath system variable for LCM to load the resource modules during integration tests. For unit tests, this is not necessary. Doing so and terminating a test without the test environment restore causes ISE to hang (while opening) when the added module path contains a folder that has multiple subfolders. For example, in of my tests, I had the resource modules for unit tests in C:\temp. The test preparation functions added C:\ to the PSModulePath system variable that caused ISE to scan the entire drive for modules.
For integration tests too, this need not be done. Instead, the modules can be copied over the existing module path and cleaned up later.
The text was updated successfully, but these errors were encountered: