InfoQ

News

.NET向けPex自動化調査テスト

作者 Al Tenhundfeld, 翻訳者 編集部 投稿日 2008年7月17日 午後6時38分

コミュニティ
.NET
トピック
ユニットテスト
タグ
MSTest,
xUnit.Net,
MbUnit,
TDD

Pex(リンク)はMicrosoft Research提供によるホワイトボックステスト生成ツールである。特定のメソッド内で各実行パスのテストケースを別々に手書きするのではなく、デベロッパは1つのパラメータ化されたテストメソッドを記述することができる。Pexはそれを使用し、標準MS Testユニットの一式を生成し、ターゲットメソッド内でパスを実行する。Pexは命令ごとに.NETコードを分析し、コードが実行しているアクションを 解釈し、「完全に自動的な方法で、Pexは関連のあるテスト入力を計算する。テスト入力は、コードのコーナーケースをトリガーする」。

手書きによるパラメータ化されたユニットテストを与えられると、Pexはコードを分析し、自動的に関連のあるテスト入力を判別する。結果はコードカバレッジが高い、従来のユニットテストスイートである。また、Pexはプログラマに対してバグの修正方法を提案している。

Pexはメソッドの意図された振る舞いを定義したり、カバーするユニットテストを書き出すというデベロッパの必要性を少なくするものではなく、APIや機能性が不可欠なユースケースやユーザストーリーの要求を満たすことを確実にしている。しかしながら、Pexはテストが実装コードを適切にカバーする(リンク)ことを 保証するための、別の手段として使用することができる。この自動化された調査テストは、メソッドで意図されていない振る舞いやエラーを特定するのに、特に便利である。

ほとんどの生成ツールと同様に、Pexは特定の規則で使用されたときに、最もその機能を発揮する。メソッドを短く、テスト可能な状態に維持することは、 TDDの設計原則であり、この原則はPex生成のテストをさらに理解しやすくする。またPexはこの設計目標を達成する上で助けとなり得る。たとえば、 Pexが大量の複雑なメソッドのテストを生成する場合、メソッドはリファクタリングの候補になる場合がある。またメソッドがカスタムオブジェクトではなく パラメーターとしてプリミティブを持っている場合に、最も良く機能する。

デフォルトで、PexはVisual Studio 2008およびMSTestを統合するが、Pexの拡張機能はダウンロードしNUnit、MbUnitまたはxUnit.Netをサポートすることができる(リンク)。Pexは、Extended Reflection管理プロファイリングAPI(リンク)上にビルドし、モニタリングアプリケーションの統合を促進する。

現在PexはMicrosoft Research提供による試作であり、Microsoftのサポート対象製品ではない。ユニットテストを記述することを主な目的としてPexを使用すべ きではない。しかしその自動化されたテスト生成は、効率的にエッジケースをカバーするのに役立つ。

原文はこちらです:http://www.infoq.com/news/2008/07/introduction-lean-thinking

ブックマーク
digg+,
reddit+,
del.icio.us+,
dzone+,
Hatena

No comments

返信

特集コンテンツ一覧

トップスポーツチームの監督に教わる秘訣

この論文では、氏が発見した原則を要約し、その原則をいかにしてソフトウェア開発に応用するかを説明します。

事例研究:Dutch Railwaysのプロジェクトにおける分散拠点でのスクラム・プロジェクト

この記事では、私達がどのようにして大規模(240人月、10万行強)でインドとオランダの開発者も参加したスクラム・プロジェクトを成功させたのかを示しています。

Agile2008チーム参加レポート - 帰国そして変化

Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。参加者はカンファレンスで各々の発表や、各セッションへの参加、諸外国のエンジニアとの出会い、ステージ上で DearXPを熱演などの様々な思い出を抱えて、無事日本に戻ってきました。

SilverlightとJavaのインターオペラビリティ

マイクロソフトのRobert Bellが、SilverlightとJavaを使用したインターオペラビリティのシナリオを紹介し、サンプルコードを例にとってアーキテクチャの手引きを提供します。

Agile2008 チーム参加レポート - カンファレンス参加編

Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。サブミッションが選択された人、そうでない人も含めて、個々の目的意識の確認、膨大なプログラムから聞きたいセッションの選択、旅行の準備、プレゼンテーションの準備の期間を終えて、無事当日を迎えました。

Agile2008 チーム参加レポート - 動機/準備編

筆者はアジャイルソフトウェア開発についての年に一度の国際会議であるAgile2008に初めて参加してきました。今年の日本からの参加者の数は14名にも及び、発表者は5名、受け持ったセッションは8つに及び、例年にない活躍を見せました。なぜ今年のAgile2008では、これほど多くの日本人が参加し発表に至ったのか? そのレポートをお届けします。

Javaトラブルシューティングメルマガ総集編 2008/08~09

エスエムジーでは、Java全般を対象にしたトラブルシューティングサービス「JaTS」を提供しています。この記事では、前回に引き続き、JaTSにて蓄積したトラブル事例とその解決ノウハウの一部をお送りしている「Javaトラブルシューティングメールマガジン」(JTSMM)の総集編として、過去2ヶ月のトラブル事例と追加情報をダイジェストとして提供いたします。

モデル駆動アプローチがうまく機能しない(しなくなる)8 つの理由

この記事では、モデル駆動アプローチがうまく機能しない、または機能しなくなることによって期待した結果が実現できなくなる 8 つの理由について書きたいと思います。