InfoQ

News

RubySpecのオフィシャルWebサイトとGoogle Summer of CodeのRubySpec担当の学生

作者 Mirko Stocker, 翻訳者 編集部 投稿日 2008年6月14日 午後6時39分

コミュニティ
Ruby
トピック
アジャイル技術,
ユニットテスト
タグ
Google Summer of Code,
テスト,
RubySpec

Brian Ford氏はRubySpecプロジェクトのオフィシャルWebサイトを(サイト・英語)発表した(source)

 

このプロジェクトは、RSpecスタイルの仕様に基づいてRubyプログラミング言語向けに完全に実行可能な仕様を書くことを目的としています。当プロジェクトは、初期のRubiniusに(サイト・英語)貢献するというほんのささいなところからのスタートでしたが、以来献身的な人々のおかげで6900を超えるサンプル(example)と2560を超えるエクスペクテーション(expectation)に到達するまでに成長しました。

Ruby言語には望ましい振る舞いを明記した正式な標準がまったく存在しないが、Rubyの実装数増加に伴い、仕様書は明らかに必要になってきている。最新ソフトウェアを開発する精神からすれば、実行可能な仕様はその他のドキュメンテーション形式より望ましい。その理由は単純で、仕様集が実行可能であれば、適合性の実証がいっそう容易になり、ただちにフィードバックできるからである。

来たるGoogle Summer of Codeに参加する2人の学生、Federico BuilesとArthur Schreiberは、Ruby仕様の改良と拡張を行う予定である。この2人と話し、この夏、何に取り組むかを聞いた。

Federico Builesはコロンビアの学生で、Cの替わりとなるものを探していたおよそ2年前に、Rubyに関わるようになり、現在はRubiniusプロジェクトに貢献している。Google Summer of Codeにおける目標について尋ねた。

 

 

プロジェクトではまず、Standard内のライブラリとCore Lib、すなわちREXML、YAML、Logger、Socket、IO向けに仕様(テスト)を書きます。

私のプロジェクトのもうひとつの役割は(Charles Oliver Nutter氏に(source)提案されたものですが)、他のRuby実装で使用している異なるテストケースに注目し、それをRubyspecにポートし、可能な限り完全な仕様一式を作るよう努力することです。

テストが欠落しているコードを探し出す方法についても、Builesに聞いた。

 

 

 

すでに作業中の決まったライブラリ一式があるので、寄り道せずにこのライブラリのドキュメンテーションをすぐに見て、メソッドにさせるべきことを確かめてから、スペックを仕上げます。ドキュメンテーションどおりに機能するなら申し分ありませんが、機能しない場合はソースを読むことから始め、何が起こっているのかを確かめます。

すぐにコードに取り掛からず、ドキュメンテーションを読むことには利点がありますが、その1つは、ものによっては期待どおりに動作しないと判明することがたびたびあることです。REXMのスペックカバレッジを始めたとき、小さなバグや最新状態になっていなかったドキュメンテーション向けに、一日のうちに3つも4つもパッチを送らなければならなかったのですが、現在ではRuby 1.9になって修正されています。今ではRubyspecがMRIの一部になったので、この種のものはすぐに発見され、その修正もずっと早くなると思います。

Rubyspecで使うRSpecの単純なクローンMSpecにより(source)、まだテストがないライブラリでスタブ生成が可能になり、その後、XもしくはY実装向けにタグincomplete、タグready、タグfailingなどを付けることができます。 こうすれば、Ruby実装で問題を起こしているlibの存在が明らかになりますが、修正で加える変更をカバーしてくれるテストスイートが存在すると分かっているので、その問題の修正にすぐに取りかかれます。

Rubyの仕様に取り組む2人目の学生は、19歳のドイツ人、Arthur Schreiberである。Rubiniusとの関わりは2007年5月以来で、これまでに小規模のパッチやバグ修正、多数のスペックで貢献している。Schreiberにも同様の質問をした。

 

Google Summber of Codeにおける私の目標は、Ruby Standard Libraryの少数のスペックを作成もしくは改良することで、対象ライブラリはCGIやStringIO、Net、Set、その他の小規模ライブラリです。


RubiniusチームのBrian Ford氏がRSpec互換のBDDフレームワーク、MSpecを開発しましたが、このMSpecを主要ツールの1つとして使用します。裏側にあるアイデアは、Ruby言語の高等機能を回避することにより、それほど完璧でない実装でもスペックを実行できるようにすることです。


MSpecはかつて基本的なカバレッジユーティリティーをサポートし、まったくスペックを持たないメソッドを指し示すことができましたが、MSpecとRubyspecsが別々のライブラリに分かれたため、ユーティリティーは削除されてしまいました。Brian Ford氏は、できるだけ早い時期にこの機能の再追加を検討する予定です。RCovを(source)Standard LibraryスペックのSpecカバレッジに使うことについても、検討中です。

これをお読みのあなたも貢献したいなら、Vladimir Sizikov氏が書いたRubySpecのクィックスタート・ガイドに(source)基本的な始めの一歩が説明されている。プロジェクトの詳細については、RubySpecWebサイトをご覧あれ(サイト・英語)

原文はこちらです:http://www.infoq.com/news/2008/05/rubyspec-website-and-gsoc

ブックマーク
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 つの理由について書きたいと思います。