You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Rubyのbundled gemのtest-unitをメンテナンスしている須藤です。 歴史 test-unitはxUnitスタイルのテスティングフレームワークです。Rubyのテスティングフレームワークの歴史(2014年版)にまとめてある通り、Ruby本体に標準添付されています。 Rubyに標準添付されているライブラリーには実は次の3種類あります。 ただの標準添付ライブラリー(例:URI) requireするだけで使えるライブラリー default gem(例:csv) requireするだけで使えるライブラリー RubyGemsで更新できる Gemfileでgemを指定しなくても使える bundled gem(例:test-unit) requireするだけで使えるライブラリー RubyGemsで更新できる どれも標準添付ライブラリーなのでrequireするだけで使えます。違いはRubyG
The document discusses testing practices for the Ruby programming language. It provides details on how to run various test suites that are part of the Ruby source code repository, including: 1. Running the "make test" command which runs sample tests, known bug tests, and tests defined in the test/ directory. 2. Running "make test-all" which runs core library and standard library tests under the te
2014年12月にRuby 2.2がリリースされる予定です1。 Ruby 2.2にはRuby 1.9.1のときに外されたtest-unitというテスティングフレームワークが再びバンドルされる予定です。Rubyのテスティングフレームワーク周りに詳しくない人にはよくわからない状況でしょう。そこで、Rubyのテスティングフレームワークの歴史を説明することで状況を整理します。 名称の整理 この説明の中ではたくさんのテスティングフレームワークが登場します。似たようなものもあるため、最初にテスティングフレームワークの名称を整理します。この説明の中で登場する名称は次の通りです。 RubyUnit Lapidary rubyunit Test::Unit test/unit test-unit miniunit minitest RSpec 違いがわかりますか?ざっくり説明すると次の通りです。 RubyU
テストの書き方 基本 今までのTest::Unitと変わらないので,classで書く.ただ,昔のTest::Unitとは違い,TestCase毎に呼ばれるstartupやshutdownなどが増えている. require 'test/unit' class TestSample < Test::Unit::TestCase class << self # テスト群の実行前に呼ばれる.変な初期化トリックがいらなくなる def startup p :_startup end # テスト群の実行後に呼ばれる def shutdown p :_shutdown end end # 毎回テスト実行前に呼ばれる def setup p :setup end # テストがpassedになっている場合に,テスト実行後に呼ばれる.テスト後の状態確認とかに使える def cleanup p :cleanup
僕が作った gem の中で、ダントツにダウンロード数が多い rake_shared_context という gem のバージョンを 0.2.1 に上げました。0.1.0 にバージョンアップしたときから8000ダウンロードくらいされてるみたいなんですが、その間何かあったんですかね…。 0.2.1 と 0.2.0 のバージョン間の違いは殆ど無くて、RSpec 3.0 のお作法に対応しただけです。ただ、RSpec 2.x 系との互換性も保っておきたいので、両方のバージョンでテストできる環境を整える必要がありました。 そこで appraisal というステキな gem を使います。この gem は、今回のような依存ライブラリのバージョンが複数ある場合のテスト環境を整えてくれます。詳細は README 見るとよくわかるのですが、テストしたいバージョンごとに Gemfile を作り、それを切り替えてテ
rails-erdに~/.erdconfigという設定ファイルを作ろうとしたときにrubygemsのGem::ConfigFileの実装とテストが参考になった。 lib/gem/config_file.rb test/rubygems/test_config.rb 特に参考になったのはテスト用の設定ファイルの準備。 テストしたいときには自分で使ってる実際の~/.hogercを読み込みたくない。ではどうするかというと、設定ファイルのパス(~/.hogerc)はベタ書きを避けて定数で書いておき、テストを実行する前にremove_constとconst_setでそれをテスト用のファイルに上書きするのである。 そしてほかのテスト項目ではデフォルトの設定を前提としていることもあるから、 test_helperやspec_helperなどで、全体としてはデフォルトの設定が有効になるように設定ファイルの
ok_gntpdというTCPServerをつかったサーバを相手にしたテストを書いた時のメモ。 テストしたい内容としては サーバを立ちあげて、 特定の文字列を送信したときに 特定の文字列を受信する ということ。規模的に結合テストというほどのものではないけど、サーバを外から叩いた結果をチェックしたいのでサーバは別スレッドで動作させることになる。 こんな感じ: require "spec_helper" describe OkGntpd do specify do #== 1. サーバを立ちあげて、 # サーバのインスタンス作成 server = OkGntpd.new( # 空いてるポートを探すためのおまじない :port => TCPServer.open('127.0.0.1', 0) { |s| s.addr[1] } ) # サーバの起動を子スレッドで t = Thread.new(s
みなさん、 timecop 使ってますか?timecop は、テストで時間を扱う時に必須と言えるライブラリです。テスト中の時間を止めたり(Timecop.freeze)時間を移動させたり(Timecop.travel)できます。似たようなライブラリとして delorean があります。RailsCasts でも紹介されています。 さて、timecop の README には下記のようなコード例が書いてあります。 t = Time.local(2008, 9, 1, 10, 5, 0) Timecop.travel(t) 僕はこれまで上記のように書くしか方法が無いと思っていたのですが、今日下記のようにも書けることに気づきました。 Timecop.travel(2008, 9, 1, 10, 5, 0) また、ブロックを使うこともできます。 Timecop.travel(2008, 9, 1,
TDDBC横浜にスタッフとして参加してきました。 TDD自体がはじめてなわけではないですが、まだまだ経験が浅いので、いい勉強になりました。 個人的に勉強になった点を中心にまとめます。ある程度TDDをやり始めた人がハマる点、この手があったかと思う点が中心になると思います。 なお、個人的には野球に詳しくなかったり、好きじゃなかったり、苦手だったりするので、別の例で書きます。 レッド、グリーン、『リファクタリング』 TDDというと、まずテストを書いてレッドになるのを確認し、実装をしてグリーンにし、その後リファクタリングをしてコードを整理します。これが、レッド、グリーン、リファクタリングです。 レッド、グリーンには気が向いていたのですが、その直後にリファクタリングをするということにはこれまで意識がまわっていませんでした。 (無意識に多少はやっていたような気もしますが。) イテレーションの中に、リフ
The document discusses strategies for testing Rails applications. It recommends: 1. Writing model unit tests first to cover the core functionality. 2. Using different data strategies like fixtures, fixture replacements, and before blocks depending on the type of data (e.g. master, resource, event data). 3. Sharing testing contexts with descriptive names to clearly express intentions and reduce fat
At Collective Idea, we do a lot of work with RESTful JSON APIs. They can be a joy to build but a pain to test. We’re currently working on a project that’s all API all the time, so we developed some reusable Cucumber steps for testing. Now, we’ve abstracted all that goodness out into its own gem… json_spec. The Gem The json_spec gem is a collection of RSpec matchers and a collection of Cucumber ste
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く