My most recent update to my PowerShell module PSSpeedTest was to split its Pester test files into separate files for each individual public and private function (see this pull request). After all of the tests had been separated as desired, the test for private function
Remove-iPerf3 was throwing a suspicious warning at the end of its execution and the test for
Remove-SpeedTestServer was failing entirely. Enabling debug on the line in the function indicated by the stack trace showed permissions errors when attempting to access paths such as
After wracking my brain for a few hours on this issue, I turned to the PowerShell Virtual User Group on Slack for assistance and the solution was much simpler than I had expected. (Thanks, @StevePJP for the help!)
A test for the function
Install-SpeedTestServer is executed prior to those for both
Remove-SpeedTestServer; this test kicks off
iperf3 as a process that listens for connections. The test for
Remove-iPerf3 naturally attempts to remove the
iperf3 package which fails as it is locked. The test for
Remove-SpeedTestServer first tries to install
iperf3 but fails since it is already installed and running.
Ensuring that the
iperf3 process is stopped before removal allowed the test for
Remove-iPerf to pass and consequently the test for
Remove-SpeedTestServer also passed.
My tests are a bit of a mess right now and will be cleaned up. The reminder that test execution order can have profound impacts on one’s test/build environment was welcome.