しばたテックブログ

気分で書いている技術ブログです。

Pester 4がリリースされました

PowerShell Pester

というか結構前にしていました。

9月の中旬にPester 4.0.7がリリースされ、このバージョンからRCが取れ正式にStable Releaseとなっています。

Pester 3からの変更点

公式なリリースノートはこちら。

github.com

Release 4.0.7 · pester/Pester

また、Peseter 3からの移行ガイドも出ています。

機能追加・変更点

主な変更点は以前に書いた

blog.shibata.tech

や

blog.shibata.tech

で説明した内容からほとんど変わっておらず、

  • Shouldで使う動詞の文法の変更
  • 配列を入力する際の仕様変更
  • 表示色の刷新
  • ContextとDescribeのネスト
  • Gherkinのサポート
  • Add-AssertionOperatorによるカスタムアサーションの追加

といった内容となっています。
この他に、

  • Invoke-Pester実行時に現在実行中のスクリプトファイル名を出す様に
  • コードカバレッジをJaCoco形式のXMLで出力できる様に
  • パッケージのサイズを削減

といった変更も加えられたそうです。

破壊的変更・廃止された機能など

Pester 4で発生した破壊的変更や廃止された機能について本エントリではリリースノートの内容を軽く紹介する程度にとどめておきます。

破壊的変更

  • Contain*の動詞はFileContentMatch*という名称に変更されました。
    これは通常の-contain演算子の挙動と誤解されない様にするための措置になります。
  • Assert-VerifiableMocksはAssert-VerifiableMockに改名されました。
  • Get-MockDynamicParametersはGet-MockDynamicParameterに改名されました。
  • モックの実装を大幅に見直したためこれまでの挙動と微妙に異なる部分が発生します。
    詳細は移行ガイドを参照してください。

非推奨となった機能

  • New-TestDriveItemは非推奨となりました。*1
  • Invoke-Pesterの-Quietパラメーターは非推奨になり、代わりに-Show Noneを使うことが推奨されます。

廃止された機能

  • Invoke-Pesterの-OutputXmlパラメーターは無くなり、-OutputFileとOutputFormatの組み合わせに変更されます。

*1:以前も触れましたがこの関数はもともと無い様に見受けられます...

Pesterでカスタムアサーションを行う - 正式版

PowerShell Pester

blog.shibata.tech

以前Pesterの機能をハックしてカスタムアサーションを行うエントリを書きましたが、Pester 4.0.5より正式にカスタムアサーションを追加する方法が提供されました。

本エントリではその方法を紹介します。

Pesterでカスタムアサーションを行う

これまでは、

  1. Pester[動詞]
  2. Pester[動詞]FailureMessage
  3. NotPester[動詞]FailureMessage

という名称の3つの関数を用意してやればPesterが内部的に独自の動詞として認識してくれました。

Peseter 4.0.5からは新たにAdd-AssertionOperatorという関数が追加され、任意の関数を1つ用意すれば独自の動詞として使用することができる様になりました。

カスタムアサーション例

Gistに前回の例を正式な方法で移植したものを上げました。
前回の関数をそのまま移植している部分があるので若干ごちゃごちゃしていますが、とりあえずはBeHashという関数に注目してください。

gist.github.com

Pesterでカスタムアサーションを行うサンプル(正式版)

カスタムアサーションを行う関数の仕様

カスタムアサーションを行う関数の名称は任意で良くなりました。
今回はBeHashという名前にしています。

ただし、引数は最低限以下の様にする必要があります。

  • ActualValue : テスト対象となる値
  • ExpectedValue : (オプション)期待値
  • Nagate : -Notと併用される場合は$true、そうでない場合は$falseが指定される

検証していませんが、内部的にはパラメーター名で識別している様なので引数の順序はバラバラでも大丈夫そうです。
また-ExpectedValueは無くても問題ありません。

そして-Nagateパラメーターは

Should -Not -BeHash @{ Name = "田中"; Salary = 300 }

の様に-Notと動詞が併用されるときに$trueが渡されるパラメーターとなります。
先の例にある様にこのパラメーターによって検証結果の成否を反転してやる必要が出てきます。

ちなみに、本エントリでは詳細に触れませんが、この3つ以外に引数を追加すると独自パラメーターとして使える様です。

次に、関数の戻り値は以下のプロパティを持つPSCustomObject*1にする必要があります。

  • Succeeded : テストが成功した時は$true、失敗した時は$false
  • FailureMessage : テスト失敗時のエラーメッセージ

先の例にある様に-Nagateパラメーターによってエラーメッセージを切り替えてやるのがパターンの様です。
(この例では最終的に同じメッセージになるのですが、Pesterの内部実装を見るときちんとメッセージを分けてやっています)

Add-AssertionOperatorの使い方

新たに作った関数をAdd-AssertionOperatorに渡すことで独自の動詞として登録し、カスタムアサーションを行うことができる様になります。
Add-AssertionOperatorは以下の引数を取ります。

  • Name : Shouldで使われる動詞の名前。BeHashを指定するとShould -BeHashと宣言することが可能
  • Test : カスタムアサーションを行う関数
  • Alias : (オプション)動詞のエイリアス。[string[]]型で複数指定可能
  • SupportsArrayInput : (Switch)配列入力をサポートするか否か

使用例として先の例から利用個所を抜粋しておきます。

# 使用例
Add-AssertionOperator -Name BeHash -Test $function:BeHash -Alias 'Hash'

参考資料

とりあえずこんな感じです。

Pester 4.0では/Functions/Assertionsディレクトリにある標準の動詞もAdd-AssertionOperatorを使う様に実装が書き換えられています。

これらの実装を読むのがカスタムアサーションを行う際の一番の参考資料になるでしょう。

*1:実装上はNew-Object PSObjectとしています

PowerShell 6.0からPowerShellのプログラム名がpwshに変わります

PowerShell

発端はGitHubのこちらのIssueから

github.com

もともと「PowerShellのプログラム名であるpowershell.exe(powershell)は長いので略称があった方が良いよね。」という提案から始まっています。

新しいPowerShellの略称について

先のIssueを見ればわかりますが、新しいPowerShellの略称は pwsh になりました。

これまでは慣例的にposhが良く使われていましたが、既存の名称(Policy-compliant Ordinary SHell)と重複するため却下され、最終的に名称の重複がないpwshが採用されました。

名前の重複に関しては以前にエイリアスにwgetやcurlを使っていた件で荒れに荒れた過去があるためPowerShell Teamとしてかなり慎重になっている様です。

他にも以下の名称が候補に上がっていました。*1

候補 不採用の理由(明確な理由がある場合のみ記載)
posh Policy-compliant Ordinary SHellと名前が重複
ps psコマンドと衝突
psc
psh Perl Shellと名前が重複
msh 既存の様々な略称と重複
mosh Mobile Shellと名前が重複
monad
pscore
coreps
coresh
pscmd
psc
pscx
pscsh cshと名前が重複
pshell
prsh
wpsh
wprsh
pwrsh
paua paua shell(パウア貝)...

個人的はpshが良かったのですが仕方ないですね...

PowerShellのプログラム名が変わる話

PowerShellの新しい略称が決まり、私個人の予想としてはショートカットやシンボリックリンクを張ることで実環境に反映させるのかと思っていたのですが、PowerShell 6.0ではプログラム名(powershell.exe(powershell))をpwsh.exe(pwsh)に変更する対応となりました。

変更するPull Requestが以下に上げられており、つい先日マージされ、正式にプログラム名が変更されることになりました。

github.com

この対応はかなり破壊的な変更になるので正直全く予想できませんでした...

とはいえ破壊的変更といっても非Windows環境においては影響が無く、Windows環境においても既存のWindows PowerShellと明確に区別したいという意図がある様で、改めて考えるとむしろ良い変更なのかな？という気もします。

*1:チェック漏れがあるかも...