InfoQ

News

オートテスト-隠されたツールの宝石

作者 Werner Schuster, 翻訳者 編集部 投稿日 2007年12月14日 午前2時39分

コミュニティ
Ruby
トピック
ユニットテスト,
アジャイル技術,
プログラミング
タグ
テスト,
ZenTest,
Automation,
IDEs
Rubyコミュニティの秘密の一つは、なぜたくさんのデベロッパ達がIDE上でテキストエディタを好むのかということである。その理由の一つはRuby内で書かれているツールのグループである。それはコーディングの地道な作業を大幅に自動化するのに役立つのである。これらのツールのいくつかは最近Pat Eyler氏のブログ上のポールで紹介されている(source)

これらのツールの一つはZentest(サイト・英語)パッケージに含まれているオートテストである。そのインストールは至ってシンプルなものである。
gem install zentest 
Zentestがそれらでユニットテストとあなたのコードを同期化するのを助ける一方、オートテストは確実にある一つ事をする。一旦始まったらファイルが保存されるた度にテストを再実行するのだ。保存されたファイルの中でコードに対応するテストのみを再実行するところが賢明なのである。

オートテストのクリエーターであるEric Hodel氏はオートテストを行うための仕事のやりかたを説明した(source)
オートテストを書く前に私は構文的に正しいきめの細かいセーブを作っていたのです。どのテストを実行するか選ぶ必要がなくなるのでテスト実行を自動化するためにオートテストを書いたのです。変更点はとても少ないのでコマンドラインを編集するのにはほとんど時間を費やしませんでした。
これはテストを実行するにおいてもう一つの利点を意味している。コードは保存の度にロードされチェックされる。これをコード上でシンタックスとセマンティックチェッカーのような静的アナライザーを増やしたり、保存する度に動かしている現代のJava IDEと比較してみて欲しい。デベロッパたちは未だ好みのエディタに依存している一方、同じくらいのレベルの自動チェックがAutotestでは成されて いる。

プラグインインターフェースもまたオートテストの拡張を可能にする。プロジェクトルーツに ".autotest"ファイルを作るだけでいいのである。これにおいて既存のプラグインを要するかもしくは多様なフック用にカスタムハンドラを書いて欲しい。
Autotest.add_hook :red { |autotest|   p "Failures!" } 
最初のパラメータはこれがフックするフックの名前である。このケースにおいてはテスト障害である。このコードはテストが通らなかった場合に単純に "Failures!"をプリントアウトする。これはまたテスト結果によって、もしくは単純に保存の度に他のツールの呼び出しを可能にする。Emacsを伴う統合用のプラグインか、もしくはハウリング(source)が入手可能である。

あなたはオートテストを以前聞いたことがあるだろうか?そしてそれを使おうと考えているだろうか?

原文はこちらです:http://www.infoq.com/news/2007/12/autotest-tool
ブックマーク
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 つの理由について書きたいと思います。