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.コンテンツ マニュアルになるように以下の順序
PSUnit
すべての Microsoft 製品 Global Microsoft 365 Teams Copilot Windows Surface Xbox セール 法人向け サポート ソフトウェア Windows アプリ AI OneDrive Outlook Skype OneNote Microsoft Teams PC とデバイス Xbox を購入する アクセサリ VR & 複合現実 エンタメ Xbox Game Pass Ultimate Xbox Live Gold Xbox とゲーム PC ゲーム Windows ゲーム 映画とテレビ番組 法人向け Microsoft Cloud Microsoft Security Azure Dynamics 365 一般法人向け Microsoft 365 Microsoft Industry Microsoft Power Platform W
Pester - BDD style testing framework for PowerShell - ＠fsugiyamaの技術日誌
このエントリは PowerShell Advent Calendar 2011 に参加しています。 はじめに 「PowerShellスクリプトに対してユニットテスト、書いてますかー？」 「TDD で PowerShellスクリプト、書いてますかー？」 「テストコードがあれば、勇気を持ってリファクタリングできる」 「テストコード、書いてますかー？」 とアントキの猪木が言うわけはありませんが、 PowerShellユーザーの皆さんはこの辺いかがお考えでしょうか？ かくいう私は、ユニットテストを書いたり、TDD(Test Driven Development)でPowerShellスクリプトを書いたりしていません。試行錯誤しながらスクリプトを書いた後に、いくつかのパターンで実行し、その結果を目視確認し、問題がないようだったら「完成♪」とか言っている口です。 ただ、書き捨てのスクリプトでも、不慣れ
レガシーコード改善ガイド : 小野和俊のブログ
以前からパラパラと部分的には目を通していたレガシーコード改善ガイドを、週末に最初から最後まで通して読んだ。 テスト駆動開発入門(以下TDD本)がゼロからテスト駆動でソフトウェアを開発するための方法を示した書籍であるのに対し、本書はテスト駆動で開発されなかったソフトウェアを、後からテスト駆動に変えていく方法を示した書籍である。本書の定義によれば、最近開発されたソフトウェアでも、テストコードのないコードはレガシーコードであり、そのレガシーコードを改善し、レガシーコードでなくしていくための道筋を提示するのが本書の目的だ。 TDDに興味は持ったものの、自分たちのソフトウェアはすでに完成してユーザーに使われており、今からTDD化のためだけに大きな予算や工数を取るわけにもいかず、「TDDは良いと思うけれど、次のプロジェクトから」という結論に落ち着いた事例を目にしたことがある人は少なくないだろう。そして
テスト駆動開発チートシート - やさしいデスマーチ
TDD（テスト駆動開発）のチートシートを作ってみた。 TDDBCでid:t-wadaさんが話している内容とかテスト駆動開発入門から引っ張ってきています。 ダウンロードはこちらからどうぞ。 PNGイメージ: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.png PDFファイル: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.pdf 追記 印刷・再配布などはご自由にどうぞ。 もし、元データ（OmniGraffle）が欲しいという人は、コメント欄かTwitter経由で教えていただければ差し上げます。 追記２ このチートシートは、OmniGraffleで作りました。他に使えそうなツールとしては、イラレとか。Visioでもたぶん作れると思います。
xDDについて考える(その1)
※このブログはデブサミ後のTwitterで話題になっていた時に下書きしていたものをそのままUPしています。 先日TDDBootCamp北陸に参加して少し考えたところもあるのですが、それは別エントリに。 最近xDD(???-driven development)という言葉が色々取り上げらています。 TDD(Test-driven development) BDD(Behavior-driven development) SDD(story-driven development) DDD(Domain-driven development) ※ここでTiDD(Ticket-driven development)のような技法を含んでいないのは、ちょっと方向性が違うかなと思ったためです。 デブサミでも話題になったそうで、Twitter上でも色々議論が流れているようですが、 ちょっといま忙しくてほと
TDDはテスタビリティの保証をしてくれるのかも - プログラマーの脳みそ
TDD Boot Camp 北陸行ってきました。 TDDはテストドリブンデベロップメントの略で、自働テストを書いてから実装を書くというスタイル。ここでよく誤解されるのだけど、業務でおなじみ単体テストや結合テストといった網羅的なテストを記述してから実装を書くわけではない。目の前の1歩分、ひとつだけテストを書き、すぐさま実装を書いて自働テストをグリーンにする、というやり方をするのだ。こればかりは実際にやってみないと誤解は解けないかもしれない。 さて、深夜のテストTL - Togetterや、TDDはテスト手法か否か - Togetterで議論されている「TDDは品質保証の手法ではない」という部分に関する議論。ここでいう「品質保証」はバグがないこと、ソフトウェア品質の12の属性でいう信頼性(reliability)が高いことを指す。 TDDのスタイルには網羅的な検査をしてバグをあぶりだすようなフ
テスト駆動開発やユニットテストを定着させるには
ユニットテストやテスト駆動開発(TDD; Test Driven Development)については、メリットや作り方の説明ばかりが先行している気がします。 現場にとって本当に必要なのは、どうやったら開発の現場に定着させることができるのかということではないでしょうか。 カバレッジだとか、より効果的なテストコードだとかは、ユニットテストが継続的に実施されるようになってからのハナシだと思います。 私が実際に、開発現場にユニットテストとテスト駆動開発を導入した経験から、この問題を考えてみたいと思います。コンテンツ障壁ユニットテストしたくなる環境オススメ障壁 まず、最初に意識しておいていただきたいのは、テスト駆動開発を導入する際に、障壁となるのは誰かということです。 テスト駆動開発の導入をもっともシブるのは、経営者でもマネージャでもありません。 技術者です。 普通、技術者(に限らないとは思いますが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
