* Stifle progress output in build.psm1 for some operations
Modify test failure presentation to use platform available XML methods
* Add timeout support for returning runtime parsing errors
Some of the language/parser tests have been hanging in a non-reproducable manner which
causes the CI system to invalidate the entire run. This change adds support for timeout
which will fail a test if it runs to long, rather than invalidate the entire run.
current behavior is still supported, and is not done in a new session:
PS> get-runtimeerror -src '1/'
At line:1 char:3
+ 1/
+ ~
You must provide a value expression following the '/' operator.
+ CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : ExpectedValueExpression
Adding a timeout will do the operation in a async powershell session
PS> get-runtimeerror -src '1/' -timeout 5
You must provide a value expression following the '/' operator.
+ CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : ExpectedValueExpression
If the operation takes longer than the supplied timeout, a timeout error will be returned
PS> get-runtimeerror -src 'start-sleep 6' -timeout 2
get-runtimeerror : Operation Timed Out ('start-sleep 6')
At line:1 char:1
+ get-runtimeerror -src 'start-sleep 6' -timeout 2
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Get-RuntimeError
* Modify native linux command tests to skip on Windows and pending on Mac
* remove verbose and progress output from help tests
* Be sure that Feature Counter tests only run on Windows
Also, only call add-type in CounterTestHelperFunctions.ps1 if we're going to actually run the tests
* do not run any get-computerinfo tests on non-windows systems
* suppress progress output from PowerShell Get tests
* remove -quiet from API and CRON Builds
Travis watches output from the build to ensure that it hasn't hung
we need to find a balance between too much output and not enough output.
A run which has too much output is killed because it looks like an error loop
A run which has too little output is killed because it looks like a hang
* Remove commented line in Import-Counter.Tests.ps1
Remove extraneous extra line in PowerShellGet.Tests.ps1
* Change `-as "type"` to `-as [type]` in build.psm1
Alter timeout to 10 seconds to be improve chances of not timing out for runtime parser checks
improve logic for counter tests to also skip for IoT
* use the existing function of SkipCounterTests rather than duplicate the logic in import-counter.tests.ps1
Pester Testing Test Guide
Also see the Writing Pester Tests document.
Running Pester Tests
Go to the top level of the PowerShell repository and run: Start-PSPester
inside a self-hosted copy of PowerShell.
You can use Start-PSPester -Tests SomeTestSuite* to limit the tests run.
Testing new powershell processes
Any launch of a new powershell process must include -noprofile so that
modified user and system profiles do not causes tests to fail. You also must
take care to call the development copy of PowerShell, which is not the first
one on the path.
Example:
$powershell = Join-Path -Path $PsHome -ChildPath "powershell"
& $powershell -noprofile -command "ExampleCommand" | Should Be "ExampleOutput"
Portability
Some tests simply must be tied to certain platforms. Use Pester's
-Skip directive on an It statement to do this. For instance to run
the test only on Windows:
It "Should do something on Windows" -Skip:($IsLinux -Or $IsOSX) { ... }
Or only on Linux and OS X:
It "Should do something on Linux" -Skip:$IsWindows { ... }
Pending
When writing a test that should pass, but does not, please do not skip or delete
the test, but use It "Should Pass" -Pending to mark the test as pending, and
file an issue on GitHub.