Make Start-PSPester more user friendly by calling Restore-Pester automatically when needed and not having to specify -Path as a named parameter for Start-PSPester #7210

bergmeister · 2018-06-29T21:35:40Z

PR Summary

Make Start-PSPester automatically call Restore-PSPester when needed. This simplifies it and reduces manual steps when running it interactively (I tend to use git clean -dfx or Start-PSBuild -Clean relatively often as I do not work with the code base every day). I am running Pester tests usually using Start-PSPester
Make -Path parameter on Start-PSPester the 0th parameter to so that Start-PSPester $Path works without needing to specify -Path as a named parameter (useful when using the cmdlet interactively for running tests locally). Yes, I know, named parameters should be encouraged but for cmdlets that are used interactively a lot and where mostly just one parameter is used, I think it is fine and I rather prefer the lazy option in this case (PSSA 'allows' for up to 3 parameters to be not named before warning btw).

PR Checklist

…o RestorePesterAutomatically

…without having to specify -Path

daxian-dbw · 2018-07-02T17:51:47Z

build.psm1

-    # Restore the Pester module
-    if ($CI) {
-        Restore-PSPester -Destination (Join-Path $publishPath "Modules")
-    }


I think this is still useful -- I want to build powershell and then manually run some Pester tests, but not Start-PSPester. In this case, I can run Start-PSBuild -Clean -CI and Pester will be installed.

Maybe I misunderstood the usage of this line by making the assumption that the function is only useful for Start-PSPester. Because I made Start-PSPester restore Pester if needed, I thought, I could remove this line. I would be happy to revert this change but would also be interested in why one would want/need Pester to be installed when building PowerShell (my guess is that your use case is to call Start-DevPowerShell and run the pester test from there?)

would also be interested in why one would want/need Pester to be installed when building PowerShell (my guess is that your use case is to call Start-DevPowerShell and run the pester test from there?)

When I'm wringing Pester tests for some code changes and just want to run the tests I'm working on, I would build the code base, start pwsh from the bin folder, and run Invoke-Pester -Script <path-of-my-test-file>. Or when I'm investigating a test failure from daily build, I might want to sync master branch, build, start the pwsh produced from the build, run Invoke-Pester with the file where the test fails.

Sure, we can install Pester to user module path, so it will always be available, but install the Pester module while build powershell could be useful in case you don't have Pester in other module paths.

Ok, I see. I will revert this change then.
When I run tests locally, then my workflow is Start-PSBuild ... and then Start-PSPester $TestFile

Yeah, sometimes I expect some of my tests to fail initially, and it's easier for me to keep the pwsh instance around for some ad-hoc verifications.

daxian-dbw · 2018-07-02T17:54:08Z

build.psm1

    [CmdletBinding(DefaultParameterSetName='default')]
    param(
+        [Parameter(Position=0)]
+        [string[]]$Path = @("$PSScriptRoot/test/common","$PSScriptRoot/test/powershell"),


In your PR description, you wrote:

Make -Path parameter on Start-PSPester the 0th parameter to so that Restore-PSPester $Path works without needing to specify -Path as a named parameter.

I'm confused about the Restore-PSPester $Path part. You are not calling Restore-PSPester with $Path in your change.

This change was for easier interactive usage only when running a test locally.

You mentioned about Restore-PSPester $Path in your description, but I don't see how making -Path positional affect your use of Restore-PSPester.

Do you mean without needing to specify -Path for Start-PSPester ?

Sorry, my bad. I meant to write Start-PSPester $Path, you are right. I corrected the PR description

Can you please update your PR description? Thanks!

Ok, done. Sorry for that mistake.

daxian-dbw · 2018-07-02T20:09:22Z

build.psm1


    $getModuleResults = Get-Module -ListAvailable -Name $Pester -ErrorAction SilentlyContinue
-    if (-not $getModuleResults)
+    if (-not ($getModuleResults | Where-Object { $_.Version -ge "4.2" } ))


How about moving Where-Object part after the Get-Module call? Like Get-Module ... | Where-Object .... Then the if check would be simpler to read here.

anmenaga · 2018-07-02T20:48:16Z

Restarted Travis CI build because of this error on Mac:
dotnet_install: Error: Could not download .NET Core SDK version 2.1.301

bergmeister added 4 commits June 28, 2018 23:47

Run Restore-PSPester automatically when needed and simplify

e701252

remove redundant documentation

deb7b60

Merge branch 'master' of https://github.com/PowerShell/PowerShell int…

207e78a

…o RestorePesterAutomatically

make -Path the 0th parameter to so that Restore-PSPester $Path works …

e23d01f

…without having to specify -Path

bergmeister requested review from TravisEz13, adityapatwardhan, anmenaga and daxian-dbw as code owners June 29, 2018 21:35

Restart Travis CI Build

758fadb

daxian-dbw requested changes Jul 2, 2018

View reviewed changes

revert 1 change as discussed in PR review (CI switch on start-psbuild)

78146cf

daxian-dbw reviewed Jul 2, 2018

View reviewed changes

Simplify Pester module check as per PR comment

96986d6

daxian-dbw approved these changes Jul 2, 2018

View reviewed changes

daxian-dbw merged commit 56e50ce into PowerShell:master Jul 3, 2018

Make Start-PSPester more user friendly by calling Restore-Pester automatically when needed and not having to specify -Path as a named parameter for Start-PSPester #7210

Make Start-PSPester more user friendly by calling Restore-Pester automatically when needed and not having to specify -Path as a named parameter for Start-PSPester #7210

Uh oh!

Conversation

bergmeister commented Jun 29, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Summary

PR Checklist

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bergmeister Jul 2, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bergmeister Jul 2, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bergmeister Jul 2, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

daxian-dbw Jul 2, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

anmenaga commented Jul 2, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

bergmeister commented Jun 29, 2018 •

edited

Loading

bergmeister Jul 2, 2018 •

edited

Loading

bergmeister Jul 2, 2018 •

edited

Loading

bergmeister Jul 2, 2018 •

edited

Loading

daxian-dbw Jul 2, 2018 •

edited

Loading