69

MS がすべての新しいサーバー製品に PowerShell を搭載するようになったことで、私は (しぶしぶながら) 真剣に取り組む必要があると考え始めています。「真剣に取り組む」ことの一部は TDD です。パワー シェル スクリプトを単体テストするための適切な方法を見つけましたか?

Mr Geek Noiseからモッキングのサンプルを見つけましたが、 RhinoMocksのようなものが本当に欲しいです。Brian Hartsockは、MS Test の powershell 文字列でテストを実行するサンプルを持っています。少しハックですが、うまくいくようです。

私が欲しいのは、「実際の」言語と同じくらいクリーンな Powershell TDD エクスペリエンスです。

明確にするために更新します。

最初の 2 つの回答は、私を Powershell のテストから遠ざけようとしています。意見は興味深いです。powershellでテストするのが良い考えかどうか知りたくありません。これは、別のフォーラムで尋ねるべき主観的な質問です。PowerShell の単体テストのソリューションが必要です。それが悪い考えだと思う場合 (そうかもしれません)、楽しい学術的な質問として扱ってください。

  • はい、スクリプト言語は異種システムを結び付けます。ただし、すでに指摘したように、動的言語では継ぎ目を嘲笑したり壊したりすることも簡単です。
  • 「デバッグ」について尋ねているのではありません。デバッグは非常に役立つトピックです。他の人に聞いてもらいます。
  • おそらく、PS スクリプトは単純なはずです。この言語はモジュール性をサポートしており、複雑なプロセスが PS に実装されることは避けられません (たとえ悪い考えであっても)。
  • この質問に対する答えは、「できません」ではありません。(リンクされたブログから - 少し古いですが) 何人かの人々がこの問題について前進していることがわかります。

繰り返しますが、 Powershellロジックの自動テストを xUnit のスタイルでどのように実装しますか? 統合テストは興味深いものであり、依存関係を壊す単体テストは最も興味深いものです。

4

6 に答える 6

44

Scott Muc は、Pester と呼ばれる PowerShell 用の軽量 BDD フレームワークのプロジェクトを開始しました。

https://github.com/pester/Pester

于 2011-01-04T21:31:57.883 に答える
11

PsUnitがフレームワークで更新されました。私は数ヶ月前にあなたと同じ問題を抱えていました.PsUnitは私が書かなければならないスクリプトの数に対して大きくて複雑だと感じたので、PS用の独自のユニットテストフレームワークを書きました. PS には、たとえば Python などの他のスクリプト言語と同じ種類の特徴があります。つまり、テスト メソッドのスコープを使用しても、いつでもどこでも関数をオーバーライドできます。これは、偽造 (別名モッキング) に最適です。つまり、テストしたい関数またはオブジェクトが他の関数に依存している場合、テストメソッドでそれらを宣言して、ローカルの偽の実装を作成できます。

したがって、どのテスト フレームワークを使用するかに関係なく、PS は TDD が非常に簡単であると言えます。それは少なくとも私の経験でした。

于 2009-08-21T05:21:50.190 に答える
3

特にTDDではなく「テスト戦略」について質問していると思うので、両方の質問に答えます。

PowerShell での作業の大部分は、コマンドレットとオブジェクト パイプを介してさまざまなシステムを統合することになります。PowerShell スクリプトが確実に機能することを確認したい場合は、これらすべてのシステムをできるだけ正確にテストできるように、完璧なステージング環境を構築することに最大限の努力を払ってください。

完璧なステージング環境でスクリプトを実行することは、TDD を使用して「設計を具体化する」ことや、事後単体テストで「コードの意図をテストする」ことよりもはるかに価値があります。

役立つかもしれない小さなメモ:

  • スイッチは、組み込みの-whatifコマンドレットに存在します。また、これも同様に実行できることがわかりまし-whatif:$someBoolた。-必要なときにわかります。
  • V2 で登場する ISE にはデバッガーがあります。甘い。
  • いつでも C# でカスタム コマンドレットをコード化して、そこで必要なことを実行できます。
于 2009-06-02T20:54:56.010 に答える
0

死んだ議論ですが、懸念は非常に生きています。

PS の単体テストの有用性についての議論で、その使用目的がエンタープライズ システム内のモジュールに関係していることを考えると、私が見落としていることが 1 つあります。PS に実装された一般的なネットワーク/ファイル レベルのタスクの中央リポジトリを備えたエンタープライズ環境を想像してみてください。この設定では、少数の開発者とネットワーク スペシャリストがいて、それぞれの職務がわずかに重複しています。開発者がビジネス ロジックをカプセル化したモジュールを作成すると、その有用性がすぐに認められるため、すぐに他の開発者が飛び込んで自分の努力にモジュールを組み込みます。このモジュールは、1 回限りの対話型スクリプトから中規模のクライアント アプリケーションまで、あらゆるものに含まれています。シェル スクリプト言語の使用例について同意しない人もいるかもしれませんが、この分野では常に進化しています。

このシナリオでは、これらの共通モジュールが従うべき一連の「契約」を定義することに価値があると私は信じています。知識の共有が組織にとって不可欠である場合、複数の人がこれらのモジュールを変更する可能性があります。単体テストでモジュールの完全性を検証することは、秩序を維持し、混乱を最小限に抑え、モジュール自体の価値を維持 (おそらく増加) するのに大いに役立ちます。

好ましいアプローチに関しては、私はまだ採用していません。PS は流動的/動的/機敏な物質を思い起こさせます。私がTDDで見たような厳格な構造の中にそれを含めることは不自然に感じます. ただし、上記のシナリオを考えると、この目標を無視することはできません。気にしないでください、私は引き裂かれています、あなたの時間を無駄にしてすみません。読んでくれてありがとう。

于 2012-05-25T14:02:58.187 に答える
-4

あなたの質問から、あなたは失望に向かっていると思います。Powershell はほんの小さなコマンド ライン言語です。もちろん、C# でできることは何でもできますが、それ以上のこともできますが、アセンブリ言語もできます。もちろん、これも OO であり、.NET ライブラリにフックされていますが、はるかにクリーンな言語である C# も同様です。

ソリューションが 1 つのライナーよりも長い場合、または TDD が必要だと思われる場合は、Powershell を使用したくありません。それは驚きに満ちた不可解な言語であり、複雑なことは避けるべきです。

アドホックな検索、テキストの置換または書式設定を行いたい場合、またはファイル システムを調べたい場合は、Powershell が最適です。本当にやりたいことは、構文に慣れるために、毎日少しずつ使用し、頻繁に繰り返すことです。このため、アドホック コマンド ラインの使用に非常に特殊なケースがない限り、オープン ソースの Powershell ライブラリも避け、独自の CmdLets を作成することは忘れてください。パイプバインディングのルールは難解で醜いです。

もちろん、これはすべて私の意見にすぎませんが、私は長い間 Powershell を使用しており、このように考えると非常に満足しています。

于 2009-06-02T18:32:31.647 に答える