PowerShell/test/powershell
Dongbo Wang 54fa658e31 Migrate from project.json to MSBuild (#3398)
- FullCLR build is disabled in this change.
- FullCLR build related functionalities in `build.psm1` and `AppVeyor.psm1` are disabled. They are not cleaned up from `build.psm1` and `AppVeyor.psm1` yet. We need to adopt .NET Core 2.0 to verify the portable module concept, and if that works well, we will remove the Windows PowerShell source code and clean up our scripts.
- `dnxcore50` and `portable-net5+win8` target framework monikers are removed.
- Dependency on `Microsoft.NETCore.Portable.Compatibility` is removed. It's not necessary, but it may come back when we work on supporting the `portable module`. Its necessity can be reviewed at that time.
- I didn't spend the time to try building powershell in Visual Studio 2017. We should have a separate issue for that. It's tracked by #3400

The `TypeCatalogParser` project is replaced by a MSBuild target to gather the dependency information.
Due to .NET Core SDK issue [#1021](https://github.com/dotnet/sdk/issues/1021), our meta-package project `Microsoft.PowerShell.SDK` starts to generate an empty assembly during the build and that results in an empty assembly `Microsoft.PowerShell.SDK.dll` appear in `publish` folder and in `.deps.json` file. We cannot simply remove the assembly because it's now part of the TPA, and removing it will cause powershell to crash at startup. We have to live with this empty assembly until that .NET Core SDK issue is fixed.  It's tracked by #3401.
2017-03-23 13:04:52 -07:00
..
Common Migrate from project.json to MSBuild (#3398) 2017-03-23 13:04:52 -07:00
engine Get-Help does not work in JEA sessions (#2988) 2017-03-23 11:30:26 -07:00
Host tab expansion not working correctly for some parameters (#3364) 2017-03-21 08:23:51 -07:00
Language Search the assembly cache kept by ExecutionContext for type resolution. (#3327) 2017-03-17 13:19:31 -07:00
Modules Remove Archive tests 2017-03-22 12:43:38 -07:00
Provider Updated tags of automounted drives tests (#3290) 2017-03-08 16:34:39 -08:00
SDK Migrate from project.json to MSBuild (#3398) 2017-03-23 13:04:52 -07:00
README.md

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.