有頂天Rubyスマートフォン用の表示で見るスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。読者です読者をやめる読者になる読者になる有頂天Rubyビールを飲みながらRubyについて書きます。この広告は、90日以上更新していないブログに表示しています。(翻訳最中なう)だいたい翻訳しました。訳がうんこなのは勘弁(ご指摘いただけると助かります)。さんのツッコミをもとに、誤訳等を修正しました。2.0は2010年10月にリリースされました。リリースされてから今までの3年間、後方互換性を保ったままRSpecを継続的に改善してきました。RSpecの2.xより古いリリースとの後方互換性を保つために残しているひどいコードの蓄積は限界点に達しています。2の最後のリリースになるでしょう(今後も多分bugfixのリリースすることはあるでしょう)。3に取り掛かっています、私は、私たちがRSpecをどのような方向に進めていくかについて、考えを共有したいと思います。ここに書かれているものの中に、既に確定していて絶対に変えらないようなトピックはありません。結局のところ皆さんが使ってくれていることがRSpecプロジェクトが成功している理由です。1.8.6のサポートを続けてきました。Rubyのテストインフラのエコシステムにおいて我々が重要だと感じていることは、gemの作者がいつ古いRubyのサポートをやめるか決められること、そして、gem作者が使用することを選択したテストフレームワークが彼らがサポートするRubyのバージョンをサポートしなくなることによって彼らがgemのサポート終了を早めるのを強制されないことです。1.8.6と1.9.1はここ2年間Travisで利用できなくなっており、またCIサーバーのセイフティネットなしでは、我々がこれらのバージョン上でビルドを実行し、古いバージョンをサポートすることは非常に難しくなっています。実際には我々はここ2年間これらのRubyバージョンを「セミサポート」しています。ユーザーがこれらのRubyバージョンについての問題を報告した際には、修正はしますが、それ以上のサポートはしません。それに、これらのバージョンのサポートを終了する時期に来ています。3では1.8.7と1.9.2、それより新しいRubyのバージョンについて、継続的にサポートする計画です。4で1.8.7のサポートを終了するでしょう。いえ、もしもTravisがそれ以前に1.8.7のサポートを終了した場合は、我々に出来るのは1.8.6と同様な「セミサポート」のみです。itsは外部gemに移動します前にこれについて書いたので、ここでは長々と書きません。我々はitsをrspec-coreから、外部のgemへと移動させようと計画しています。have(x).itemsマッチャ―が外部gemに移動しますRSpecはCucumber/Gherkinが生まれる前に作られました、そして早期の目標の1つが、プロジェクトのステークホルダーが理解出来るような自然言語のように表現できることでした。have(9).playersのような表現がプロジェクトの目標を示していました。その後、ステークホルダーにフォーカスしたテストとしてCucumber/Gherkinが現れ、今日ではRSpecがステークホルダー向けのテストを書く目的で使われることは珍しくなりました。eq(9)のようにシンプルでうまく動く表現に比べると、必要以上に複雑です。我々はこれらのマッチャをrspec-expectationsから、外部のgemに移動させようと計画しています。gemによるデバッガーを有効にするための-d/--debugコマンドラインオプションをサポートしてきました。今日ではruby-debugはRubyをデバッグするのに使うただ1つのgem(あるいはメインのgem)というわけではありません。1.9.2+でデファクトスタンダードになっています、そして多くの開発者がpryをデバッグに好んで使うようになっています。他のRubyインタプリタ、たとえばRubniusは自身にデバッガの機能を持っています。3で明示的なデバッガーのサポートをやめ、取り除こうと計画しています。コマンドラインオプションを取り除くのに加えて、我々はruby-debugがロードされていない際にKernerlにモンキーパッチするのをやめます。そんでもって、debuggerがロードされてないのにdebuggerと書いているとNoMethodErrorが飛ぶようになるでしょう。flag(-r)が使えます、-rdebuggerのように使います。rcovとの統合をやめますRSpec::Core::RakeTaskは長い間rcov向けのオプションを持っていました。1.8でのみ動作し、最近のRuby開発者のほとんどはコードカバレッジが必要なときはSimpleCovを使うようになっています。SimpleCovは非常にシンプルで、RSpec自身からの明示的なサポートなしで、RSpec(あるいは他のフレームワーク)と一緒にうまく動きます。Autotestとの統合は外部のgemに移動しますAutotestは主に継続的にRubyのテストを実行するために使われています。今日では、guardがより人気になったので、RSpecがAutoTestとの統合をrspec-coreの中で行う理由はありません。TextMateフォーマッターがTextMateのbundleに移動する長い年月、TextMateはRuby開発者が使うもっとも人気のあるエディタでした。RSpecはTextMate向けのformatterを長い年月もっていましたが、今日ではTextMateはRubyの開発者の間で人気のエディタだとは言えなくなっており、TextMateフォーマッターをrspec-coreにいれておく説得力のある理由がありません。2.14はdeprecatedになって2年以上たつようなものを大量に含んでいました。我々はdeprecatedになったほぼすべてのAPIを取り除く計画です。2.11では新しいexpectベースの記法がrspec-expectationsに入りました。2.14では、我々はrspec-mockをアップデートし、似たような記法を使うようにしました。新しい記法を紹介してから、私は「どれぐらい近いうちにshouldベースの古い記法をdeprecatingにするの?/とりのぞくの?」という質問を受けました。今のところ我々に古い記法を取り除く計画はありません。ユーザーは長年にわたり、古い記法でコードを書いてきました。私たちは(新規プロジェクトなら尚のこと)新しい記法を使うことを推奨していますが、かといって今すぐ古い記法を取り除いてしまうことはユーザーにとって非常に不親切です。それに、古い記法のサポートのメンテナンスはものすごく大変というわけでもありません。3では、我々は古い記法をデフォルトで無効にし、ユーザーがオプトインでそれを使うよう強制することを検討しました。私はそうするのは新しくRSpecを使うユーザーにとって、不親切になると考えました。RSpecを試してみる人たちにとっては、チュートリアルからコピーしてきたコードでNoMethodErrorがでるのは非常にがっかりすることになるでしょう。経験豊かな人はかんたんに古い記法を無効にできるのに対して、新人がチュートリアルにある古い記法を有効にして使うためのRSpecの知識を十分に持っているとは言いがたいです。etc...)を使うと警告メッセージを出すように計画しています。4で古い記法を無効にするのをデフォルトにするための道を開くでしょう。新機能についてゼロモンキーパッチモード!歴史的に、RSpecは読みやすい記法を作るため、広範囲にわたってモンキーパッチを行って来ました、describeやshared_examples_forやshared_contextやshouldやshould_notやshould_receiveやshould_not_receive、そして全てのオブジェクトで使えるstubなどです。2.11では、describeはすべてのオブジェクトに追加されなくなりました、代わりに、トップレベルのmainオブジェクトとModuleに追加されるようになりました(つまり全てのclassとmodule内で使用可能です)。2.11では、我々はexpect記法を追加しshould記法を無効にするための設定オプションを提供しました。これはshouldとshould_notを全てのオブジェクトから取り除くものです。2.12では、shared_examples_forとshared_contextは、全てのオブジェクトに追加されなくなりました。describeのようにそれらはトップレベルのmainオブジェクトとModuleにのみ追加されるようになりました。2.14では、我々はrspec-mocksがexpectベースの記法をサポートするようアップデートしました、そしてmockするための古い記法を無効にするオプションを提供しました。これはshould_receiveとshould_not_receiveとstubをすべてのオブジェクトから取り除くものです。上述したように、3.0で我々はRSpecのモンキーパッチをあてたKernel#debuggerを削除します。doend最終的には3つの設定オプションにより決まります(1つはrspec-expectations、1つはrspec-mocks、そして1つはrspec-core)、それはRSpecにゼロモンキーパッチモードを提供します(我々はこれら3つを一括して設定出来るオプションを提供する予定です)。4.0は何もしなくてもゼロモンキーパッチモードで使えるようになります。残念ながら、テストダブルが置き換えているインターフェースと実際のインターフェースはかんたんに噛み合わなくなります。あなたがメソッドをリネームしたり、期待される引数の数をかえたとき、変更したクラスのテストダブルを更新するのはかんたんに忘れがちです。私は長い間、この問題を解決するrspec-fireのファンでした。そこで私はrspec-mocksにそれをポートすることを計画しています。詳しくは、githubのissueでのディスカッションを見て下さい。2.13では、我々はincludeマッチャーがマッチャ―の配列を受け入れるようなサポートを追加しました。このような組み合わせ方はとても使えるので、我々はこれをRSpec3のすべてのマッチャ―で出来るようにしようと計画しています。match(/bar/)))何を期待するかを詳細に表現しています:「私はsome_objectがdo_somethingしたとき/foo/と/bar/にマッチする文字列を含んだ配列をyieldすることを期待する。我々はまた、このスタイルでマッチャ―を組み合わせたときにより読みやすいように、マッチャ―のエイリアスを追加することを検討しています。a_string_matching(/bar/)))より詳細な情報についてはGitHubのissueを見てください。FormatterのAPI改善formatterにテストの状態を通知するための現在のAPIは、新しく通知を追加したり、既存の通知を変更する際に、ちょっとばかり柔軟性に欠けることが分かっています。我々はこれを2つの方法で変えようとしています:formatterにすべての通知メソッドを実装することを要求するよりも、formatterが特定の通知だけをサブスクライブする方法。これであなたはformatterで必要なほんのちょっとの通知メソッドだけ実装すればよくなります、そして既にあるformatterを壊す心配なしに、新しい通知を追加することが出来るようになります。通知の引数は順番にならんだ引数列から、1つの値オブジェクトに変わります。メソッドのシグネチャを変更せずに、追加のデータを特定の通知に加えることが可能になります。これらの変更により2.xのリリースで出来なかったさらなる改善が出来るようになります。我々は古いAPIで書かれたformatterをラップして互換性をもたせる層をRSpec3で提供する予定なので、ユーザーが古いformatterを使っていても、かんたんにアップグレードすることが出来ます。詳細についてはGitHubのissueを見て下さい。2では現在実行中のexampleをexampleで見ることが出来ます。これはexampleのメタデータにアクセスするために使うことができます。これはときどき、ユーザーがうっかり独自のexampleメソッドを定義した際に、問題を引き起こします。APIを使うgem(例えばCapybaraのこと)に頼っているユーザーが、アップグレードに頭を抱えることを承知しています。我々はアップグレードをスムーズにする方法について、gemの作者とともに議論しています。issueをみてください。マッチャ―のプロトコルと、カスタムマッチャ―APIの変更RSpecはshouldベースの記法からやり方を変えていってますが、その一方でマッチャープロトコルとカスタムマッチャーのAPIはその変更に追従していませんでした。マッチャ―のプロトコルは未だにfailure_message_for_shouldとfailure_message_for_should_notに依存しており、カスタムマッチャ―APIはmatch_for_shouldとmatch_for_should_notのようなメソッドに依存しています。3では、マッチャ―プロトコルとカスタムマッチャ―APIを変更し、shouldが使われなくなるまでの間、既存のマッチャ―がうまく動くよう後方互換性のレイヤーを残しておき、RSpec4でそれらの互換性を取り除こうと計画しています。我々は新しいAPIがどうなるべきか未だ確証を得ていません。issueで知らせて下さい。any_instanceがブロック実装にreceiverをyieldするようになるany_instanceを使ってメソッドをスタブするとき、通常のメソッドスタブと同様に、実装をブロックで渡すことが出来ます。あなたがブロックの中からreceiverにアクセスしたいとき(つまりインスタンスからメッセージを受け取りたいとき)、それをする方法はありません。365).floorend後方互換性のために、我々はこの挙動を無効にする設定オプションを追加する予定です。3.0は、2010年以降はじめて意図的に破壊的な変更を加えることが出来るメジャーリリースとなるにも関わらず、既存のテストスイートが可能な限り楽にアップグレード出来るようなアップグレードのみちすじをたてることが我々にとって重要です。移行を終わらせるために、我々は純粋にユーザーのアップグレードを助けるための2.99をリリースすることを計画しています。warningを加えたものになります。2.xで書かれた既存のテストコード一式は何の変更も加えずに2.99にアップグレードできるので、2.99であなたのテストコード一式を実行してください。2.99は、3.0で取り除かれたり壊れてしまう変更点の警告を出しますから、この警告に対応してください。2.99で警告が出なくなったら、そこからは何も変更を加えることなく3.0にアップグレードできます。2.99は重要なステップなので、3.0へのアップグレード手順としては省略しないでください。3で何が変わったか探そうとするよりも、あなたによりシンプルで効率的なアップグレード方法を提供してくれるでしょう。3に向けての取り組みを開始しています。我々はまた、2.14での変更用に2-14-maintenanceブランチ(パッチリリースを可能にするため)、2.99での変更に向けて2-99-maintenanceブランチをもっています。Candidates版(といくつかのβ版)のリリースを計画しています。RSpec3のリリースがいつ頃になるかを予想するような危険を冒すのはやめておきます。2013»プロフィールid:nilpビールを飲みながらRubyについて書きます。Blog|ブログを報告する。