Pesterマニュアル PowerShellによるユニットテスト

0.前置き

この記事はPowerShell Advent Calender 2012の17日目のエントリーです。
前日は@Chukiさんの「Active Directoryの管理なら 7/R2以降を使いましょう^^」でした。

今回は、PowerShellのユニットテストの内容を書こうと意気込んでいましたがなんと@fsugiyamaさんが2011年のAdventCalenderで書いていらっしゃいました。今回はせっかくなので導入編は省いて、マニュアルっぽくまとめてみたいと思います。

0-1.Pesterの紹介

BDDスタイルテスティングフレームワークです。
・本家のサイトはこちらのgithubで
・日本語だと@fsugiyamaさんのPester – BDD style testing framework for PowerShell

0-2.コンテンツ

マニュアルになるように以下の順序に沿って整理していきます。
記載の分類は、「JUnit実践入門」、記載内容は、Pesterの解説ページなどを参考にしています。

  • 1. テストの準備
  • 2. アサーション
  • 3. テストランナー
  • 4. テストのコンテキスト
  • 5. モック
  • 6. CIとの統合

1. テストの準備

Get-Hogeというコードの作成と、これに対するテストコードの作成を行いましょう。
まずはPesterの機能を用いてスケルトンと呼ばれるテンプレートを作成します。

PS D:\xxx> New-Fixture scripts Get-Hoge
Creating => scripts\Get-Hoge.ps1
Creating => scripts\Get-Hoge.Tests.ps1
PS D:\xxx>

Get-Hoge.ps1が本体のコードを格納するファイル、Get-Hoge.Tests.ps1がテストコードを格納するファイルになります。

2. アサーション

続いて、アサーション(検証方法)を整理していきます。
Pesterでは、「Should」オブジェクトを利用して検証を行います。「Should」のメンバーには以下のものがあります。
多くが内部的にはPowerShellの標準機能をそのまま利用しています。

Be

2つのオブジェクトを比較します。

$actual="こんにちは"
$actual.should.be("こんにちは") // 成功する

Hava_Count_Of

IEnumerable型オブジェクトの件数を検証します。

@(1,2,3,4).should.have_count_of(5) # 失敗する

Exist

PSドライブ内に対象が存在するかどうかチェックします。
ファイル・フォルダーの存在チェックや、レジストリー値の存在チェックなどなんでもOK。
Test-Pathと同等の検証機能です。

"C:\hogehoge\fuga".should.exist()

Match

正規表現を利用して2つのオブジェクトを比較。
PowerShellの正規表現と同等の検証機能。

"192.168.1.1".should.match("\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}") # 成功

Be_Like

ワイルドカードを利用して2つのオブジェクトを比較。

"PowerShell".should.be_like("P*S*") # 成功

3. テストランナー

テストを実行するときは、Invoke-Pesterを利用します。
このコマンドを利用すれば、指定したフォルダー以下にあるテスト用のファイルを再帰的に探し実行してくれます。
オプションを指定することによって、テスト結果をNUnitのレポート形式(?)にて出力できます。

Invoke-Pester -OutputXml "TestResults.xml"

実行結果は以下のように表示されます。
result

4. テストのコンテキスト

テストケースが複数になった場合は、グループ化して可読性をあげる必要があります。
そのためにPesterでは、Describe、Context、Itを利用します。
Itが1テストケースに相当します。ContextがItをまとめたもの。DescribeがContextをまとめたものです。

Describe "Exec-Calc" {
    Context "例外処理の確認"{
        It "引数がnullかチェックする"{
            #...
        }

        It "引数が数値かチェックする"{
            #...
        }
    }

    Context "本体処理の確認"{
        It "加算処理を実行する"{
            #...
        }

        It "減算処理を実行する"{
            #...
        }
        It "除算処理を実行する"{
            #...
        }

        It "乗算処理を実行する"{
            #...
        }
    }
}

テストの実行結果はこのようにグループ化されて表示されます。
result2

5. モック

PowerShellは利用されるシチュエーション上、外部モジュールとのやりとりが気持ち多くなる気がします。
ユニットテストを行う場合、その外部モジュールの挙動をシミュレーションするモックが重要になります。
モックの作成方法と、モックの検証方法は以下の通りです。

#モックを作成
Mock Get-Hoge { return 2 }

#モックを作成(パラメータによってモックを起動するかどうか指定する)
Mock Get-Hoge {return 7} -parameterFilter{$val -eq 10}

#モックの検証(-verifiablez属性を付与したモックが利用されたかどうか)
Mock Get-Hoge -verifiable {return 7}
Assert-VerifiableMocks

#モックの検証(モックが指定回数呼ばれたかどうか)
Assert-MockCalled Get-Hoge-Times 10

6. CIとの統合

PesterはさまざまなCIツールと統合することができます。
PowerShellのコマンドで走らせてもよいのですが、batがあります。

./pester.bat

もちろんNunitと同じ形式でテスト結果を出力できます。(「3.テストランナー」参照)

7.最後に

PowerShellのコードもユニットテストをしようということで、Pesterを紹介しました。
なるべく全機能を紹介するようしました。
これだけあれば、あとはテストコードを書き始めるだけ!

明日は、@ichiohtaさんです!お願いしますー。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

%d人のブロガーが「いいね」をつけました。