InfoQ

News

RSpec 1.1 - 振舞駆動開発支持者のためのステップアップ

作者 Rick DeNatale, 翻訳者 岡田 英久 投稿日 2008年1月7日 午後12時50分

コミュニティ
Ruby
トピック
アジャイル技術,
Ruby on Rails,
Delivering Quality
タグ
BDD,
Rails,
TDD,
RSpec
最近 Ruby コミュニティでいくつかの重要なリリースがあった。12 月 7 日には Rails 2.0 がリリース(サイト・英語)され、そして先日 David Chelimsky 氏は RSpec 1.1 のリリース'(サイト・英語)を発表(source)した。

この新しいリリースは Rails 2.0 にしっかり対応している。RSpec のトランクは EdgeRails (まだリリースされていないものなど Rails の開発バージョンのこと)をトラッキングしており、EdgeRails と RSpec 両方のトランクで開発をしているデベロッパは RSpec チームが両者の相違点を解決するのを手助けしてくれている。これがリリースの動機のひとつであるが、他にもいくつかのアピールポイントがある。

RSpec の主要な新規機能のひとつは Story Runner だ。これは RSpec にマージされた Dan North 氏の RBehave がもっていた機能(source)である。ストーリーは、アプリケーション要件の実行可能なステートメントである。RSpec 1.1.0 は Rails ユーザ用には RailsStory を用意しており、従来の Rails でいう Test::Unit を使った integration test がもっている役割を完全にカバーしている。受入テストのようなそれ以外の利用もできる。

Test::Unit を使用している既存の Rails プロジェクトに RSpec を導入するのを妨げる要因のひとつは、移行方法の問題だった。現在 RSpec はこれを簡単に行うことができる。Rails 用の RSpec ランナーは実は一年以上前から Test::Unit の上に構築されている。RSpec 1.1.0 では Spec モジュールを Test::Unit の TestCase に含めることが可能になった。これで、Test::Unit から RSpec シンタックスへの段階的な変更が可能である。TestCase は振舞に、テストメソッドは実行可能なサンプルに、そしてアサーションはエクスペクテーションに、少しずつ変えていくことが可能だ。既存の TestCase を、それまでの動作を維持したまま変更することができるのである。

もうひとつの主要な新機能は、振舞の定義がネスト可能になったことだ。多くの場合、これまでの RSpec がもっていた shared specification 機能よりも、こちらのほうが一般的なスペックのバリエーションである自然なサブスペックの定義に役立つ。
全体として、これは現在のそして将来の RSpec ユーザたちにとって大きなニュースである。

あなたはもう RSpec を使っているだろうか?もしまだなら是非使ってみてほしい。

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