[#35333] [Ruby 1.8 - Bug #221] (Open) Net::SMTPでSMTPのHELO/EHLOにデフォルトで不正なホスト名を使用 — Anonymous <redmine@...>
チケット #221 が報告されました。 (by Anonymous)
チケット #221 が更新されました。 (by Masahiro Tomita)
チケット #221 が更新されました。 (by Anonymous)
とみたです。
とみたです。
卜部です。
西山和広です。
[#35355] リリース前ToDoリスト — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
なかだです。
まつもと ゆきひろです
高尾宏治です。
高尾宏治です。
なかだです。
高尾宏治です。
なかだです。
前田です。
なかだです。
前田です。
なかだです。
高尾宏治です。
山口と申します。
高尾宏治です。
高尾宏治です。
高尾宏治です。
GyRCJDMkcyRLJEEkTyEjGyhCTS5TdXp1a2kbJEIkRyQ5ISMbKEINCg0KGyRCO24kNyRGJF8kXiQ3
高尾宏治です。
高尾宏治です。
高尾宏治です。
GyRCJDMkcyRLJEEkTxsoQiBNLlN1enVraSAbJEIkRyQ5ISMbKEINCg0KTWFjIE9TWCAxMC40GyRC
高尾宏治です。
[#35372] patch for ruby-core:17472 — wanabe <s.wanabe@...>
ワナベと申します。
なかだです。
ワナベです。
遠藤です。
=1B$B$`$i$?$G$9!#=1B(B
豊福です。
[#35375] Re: [ruby-cvs:25121] Ruby:r17902 (ruby_1_8_6): * re.c (rb_reg_search): need to free allocated buffer in re_register. [ruby-core:17518] — Urabe Shyouhei <shyouhei@...>
卜部です。ruby_1_8_xの枝を弄る人全員にお願いです。チェックインする前に必
[#35389] Re: [ruby-cvs:25164] Ruby:r17945 (trunk, ruby_1_8): * string.c (rb_str_succ): limit carrying in an alphanumeric region if — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
[#35396] cc always picks ruby/ruby.h on OS X — "Akinori MUSHA" <knu@...>
ruby 1.8 の tk ライブラリが OS X 上でビルドできない件です。
[#35404] ruby_1_8_6/ruby_1_8_7ブランチのメンテナンスポリシーについて — "Shugo Maeda" <shugo@...>
前田です。
卜部です。
前田です。
卜部です。
前田です。
Shugo Maeda さんは書きました:
どこにぶら下げるのがいいのかわからないので、単に意思表明ですが、
卜部です。
At Fri, 11 Jul 2008 01:00:29 +0900,
前田です。
In article <704d5db90807110028o238594f2wda0ec1bf12abc940@mail.gmail.com>,
そういえばこの部分に言及するのを忘れていた
前田です。
卜部です。
前田です。
In article <704d5db90807121803o5ea67361ucbf968f8a18a845d@mail.gmail.com>,
Tanaka Akira さんは書きました:
前田です。
卜部です。
前田です。
卜部です。
前田です。
卜部です。
前田です。
こんにちは、なかむら(う)です。
卜部です。
[#35420] Re: [ruby-cvs:25212] Ruby:r17993 (trunk): * test/ruby/envutil.rb (assert_normal_exit): finish writing script — Tanaka Akira <akr@...>
In article <200807100931.m6A9V4vi014459@ci.ruby-lang.org>,
ワナベです。
こんにちは、なかむら(う)です。
ワナベです。
こんにちは、なかむら(う)です。
こんにちは、なかむら(う)です。
In article <20080711050939.531D.C613B076@garbagecollect.jp>,
こんにちは、なかむら(う)です。
[#35446] [Bug:trunk] Thread#kill cannot break BLOCKING_REGION() on windows — "U.Nakamura" <usa@...>
こんにちは、なかむら(う)です。
[#35450] [BUG] cfp consistency error in Win32OLE — Masaki Suketa <masaki.suketa@...>
助田です。
ワナベと申します。
助田です。
[#35458] make profiler for gc — authorNari <authornari@...>
nariです。
In article <1153cee60807122239t19f6ae05vc0c1995c77349377@mail.gmail.com>,
nariです。
nariです。
三浦と申します。
[#35471] [Bug: 1.9] lazy timer thraed creation — SASADA Koichi <ko1@...>
ささだです.
[#35484] Re: [ruby-core:17739] [Ruby 1.9 - Bug #256] (Open) defined?(Gem::RubyGemsVersion) behaves strange — wanabe <s.wanabe@...>
ワナベと申します。
西山和広です。
斎藤と申します。
[#35542] [Bug:1.9] sleep and Thread#run — Tanaka Akira <akr@...>
1.9 では sleep で寝ているスレッドを Thread#run で起こせない
[#35545] Test::Unit -> miniunit — Kouhei Sutou <kou@...>
須藤です。
まつもと ゆきひろです
[#35555] [Ruby 1.9 - Bug #282] (Open) failure of test_asctime(TestTime) on mswin32 — Usaku NAKAMURA <redmine@...>
チケット #282 が報告されました。 (by Usaku NAKAMURA)
ワナベと申します。
[#35578] [Bug:1.9] context switch may occur during freeing io — "Yusuke ENDOH" <mame@...>
遠藤です。
[#35597] [request]C APIの拡張 — "Goro Fuji" <g.psy.va@...>
藤と申します。
なかだです。
ご意見ありがとうございます。
なかだです。
卜部さん
卜部です。
[#35620] non-locale filename encoding — Tanaka Akira <akr@...>
Dir の使いかたとして、ファイル名のエンコーディングが locale
成瀬です。
In article <48866F3F.80906@airemix.jp>,
成瀬です。
In article <488771FD.4020800@airemix.jp>,
Tanaka Akira wrote:
In article <4888B29D.7030009@airemix.jp>,
成瀬です。
In article <488AC157.7090203@airemix.jp>,
[#35646] [Bug:1.9] Rinda has a race condition — "Yusuke ENDOH" <mame@...>
遠藤です。
[#35648] [Bug:1.9] MingwでIO#dupがブロックする — wanabe <s.wanabe@...>
ワナベと申します。
[#35649] PENDINGS.rb (Was: Re: [Ruby 1.9 - Bug #354] (Assigned) Test failure test/ruby/test_transcode.rb) — "Yusuke ENDOH" <mame@...>
遠藤です。
In article <e0b1e5700807240845o4c09cfa5gae142c1dd0c74170@mail.gmail.com>,
2008/07/25 1:02 Tanaka Akira <akr@fsij.org>:
成瀬です。
遠藤です。
In article <e0b1e5700807290517mee11539lfbd82d4dfc98c53f@mail.gmail.com>,
遠藤です。
In article <e0b1e5700807300311v13752775mcf8bb5086753051d@mail.gmail.com>,
[#35669] [Ruby 1.9 - Bug #368] (Open) 境界における Math.atanh 等の動作 — Yui NARUSE <redmine@...>
チケット #368 が報告されました。 (by Yui NARUSE)
斎藤と申します。
[#35681] [Ruby 1.9 - Bug #369] (Open) Ruby 1.9.0-3で R — Akira Matsuda <redmine@...>
チケット #369 が報告されました。 (by Akira Matsuda)
[ruby-dev:35545] Test::Unit -> miniunit
須藤です。
日本語でごめんなさい。
ruby-coreでの話なのですが、Test::Unitをminiunitで置き換えよう
としていたのを私だけが反対していたという件についてです。
In <E1KIEXZ-0005M6-Sc@x61.netlab.jp>
"[ruby-core:17758] Re: Release Plan: Ruby 1.9.0-2" on Mon, 14 Jul 2008 12:11:43 +0900,
Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
> |I stop to object that Test::Unit is replaced with miniunit.
> |Because nobody objects it except me. It will mean that my
> |opinion doesn't make sense. If Matz says 'go', Test::Unit
> |will be replaced with miniunit.
> |
> |I'll write my opinions in this mail below. I'm happy if my
> |opinions are considered a bit in the future. It's OK for me
> |if they aren't considered.
>
> If I understand you correctly, lack of full compatibility is
> the primary reason of your objection to minitest, right?
私がminiunitへの置き換えに反対していた1番の理由(*)は、
miniunit にはTest::Unit以上に拡張性がないことです。
(*) 1番の理由というよりは、妥協して最後に残った、少なくとも
これだけはお願い、という理由
ただ、↑にも書いたとおり、今は反対していません。大きな理由は
以下です。
* 彼らに私の言いたいことを伝えるのが難しいことがわかった
(私の英語力やdiscussionの仕方では)
* 彼らの方針は「標準添付じゃなくて別にやればいいじゃないか」
のようだ
反対しているのは私だけだったようなので、miniunitで置き換える
のにmore discussionは必要ないんじゃないかと思っています。
もう必要ないと思いますが、せっかくなのでメンテナと私の意見を
以下に書いておきます。
(主に私の意見が)長いです。ごめんなさい。
何人か反応していた人の意見では、メンテナの意見でいいんじゃな
い?がほとんどでした。
== 前提
* 現Test::UnitのメンテナRyan DavisはTest::Unitに問題がある
と思っていた
* 私も問題があると思っていた
== メンテナの意見
=== Test::Unitの問題点
複雑なのでメンテナンス性が悪く(外向きのAPIじゃなく内部のAPI
や構造などを)使ったり拡張したりするのが大変
=== 解決法
Test::Unitをminiunitで置き換える
miniunitは以下の特徴を持ったテスティングフレームワーク
* シンプル
* 小さい
* きれい
* Test::Unitと互換のAPIも提供している
=== 利点
* メンテナンスしやすい
* 速い
* Test::Unitより機能が豊富
* アサーションが多い
* 多分、以下とrefute_*のこと。refute_*はassert_not_*と同じ
* assert_empty
* assert_in_epsilon
* assert_includes
* 小さいBDD用のインターフェイスがついている
* 小さいモックの実装がついている
=== 欠点
なし。今のTest::Unitで書かれたテストはそのまま動くし。
== 私の意見
私は以下の理由からテスト環境はできるだけ機能豊富であって欲し
いと思っています。これはテストを書く1ユーザとしての視点から
です。
* テストを書くのが面倒くさくならないようにしたい
* テストを簡単に書きたい
* テストを簡潔に書きたい
* テストが失敗したときにできるだけ早く問題を特定・解決した
い(少なくとも特定したい)
* 問題箇所が見つけやすいようにテスト結果を表示して欲しい
そして、標準のRubyパッケージがテストを書く人にやさしいパッケー
ジになって欲しいと思っています。もし、それが無理でもせめて外
部パッケージで拡張しやすいようになって欲しいと思っています。
=== Test::Unitの問題点
* 拡張しづらい
* 機能豊富ではない
==== 拡張しづらい
例えば、MochaやActiveSupportではTest::Unit::TestCase#runを以
下のようにまるごと置き換えています。
alias_method :run_before_mocha_test_case_adapter, :run
def run(result)
assertion_counter = AssertionCounter.new(result)
yield(Test::Unit::TestCase::STARTED, name)
@_result = result
begin
begin
setup
__send__(@method_name)
mocha_verify(assertion_counter)
rescue Mocha::ExpectationError => e
add_failure(e.message, e.backtrace)
rescue Test::Unit::AssertionFailedError => e
add_failure(e.message, e.backtrace)
rescue Exception
raise if Test::Unit::TestCase::PASSTHROUGH_EXCEPTIONS.include? $!.class
add_error($!)
ensure
begin
teardown
rescue Test::Unit::AssertionFailedError => e
add_failure(e.message, e.backtrace)
rescue Exception
raise if Test::Unit::TestCase::PASSTHROUGH_EXCEPTIONS.include? $!.class
add_error($!)
end
end
ensure
mocha_teardown
end
result.add_run
yield(Test::Unit::TestCase::FINISHED, name)
end
この例では、入れたいのはmocha_verityとmocha_teardownだけです。
そのためにメソッド全体をコピペして利用しなければいけない構造
になっています。このため、Test::Unitを拡張したいライブラリの
メンテナンス性が悪くなります。(Test::Unitの内部のAPIが変わっ
たら動かなくなるかもしれない)
==== 機能豊富ではない
Test::Unitはここ4-5年くらいテスティングフレームワークとしての
機能のうち、テストをもっと書きやすくするための機能(例えばア
サーション)はほとんど変更されていません。ほそぼそと行われる
変更のほとんどはテスト起動まわりとRuby本体の仕様変更への追従
です。(その多くはTest::Unitメンテナ以外による)
しかし、その4-5年の間もテスト手法は改良されています。例えば、
モックオブジェクトを使ったテスト手法を使えば、もっと便利にテ
ストが書けるでしょう。expectedとactualのdiffを表示して問題点
を発見しやすくする手法を使えば、もっと楽にテストをメンテナン
スできるでしょう。
もっとテストを便利に書きたいプログラマの1人としては、現在の
Test::Unitは少し伝統的過ぎる感があります。
=== miniunitの問題点
↑のTest::Unitの問題点と同じ。miniunitに変えても問題点が改善
されないどころかもっと悪くなると思ったので反対していました。
==== 拡張しづらい
メンテナが言うには、Rubyで書かれているんだからminiunitも
test/unitと同じくらい拡張性がある、らしいです。ただ、私は
test/unitは拡張性が低いと思っているので、miniunitにしても嬉
しくないと思っています。
miniunitの場合でもTest::Unitのように#runをコピペして上書きっ
ぽいことをしないといけません。ActiveSupportではそのようにして
います。関係ないですが、ActiveSupportのやり方だとteardownが2
回呼ばれそうな気がします。
また、miniunitはBDD用の構文もサポートしているのですが、そのた
めのmust_*メソッド(RSpecと違ってshouldではない)は
Module#infect_with_assertionsでassert_*/refute_*から動的に生
成しています。ただ、動的といってもrequire 'mini/spec'した時
点で生成するので独自assert_*を作った場合は自分でmust_*を定義
しないといけません。ただ、Module#infect_with_assertionsはそ
んなに使いやすそうではありません。(拡張しづらそう)
miniunitはsimpleなのをウリにしていますが、このようにevalして
動的にメソッドを定義したりするはsimple?とか思ったりします。
==== 機能豊富ではない
miniunitにはモックオブジェクトのサポートが入っていますが、ソー
スコードが小さいだけがウリのようなおもちゃのようなもので、こ
れで便利にテストが書けるとは思えません。
例えば、可変長引数に対応していないので、こういうことができま
せん。
mock = Mini::Mock.new
mock.expect(:meaning_of_life, 42)
mock.expect(:meaning_of_life, 42 ** 2, [:arg1, :arg2])
assert_equal(42, @mock.meaning_of_life)
assert_equal(42 ** 2, @mock.meaning_of_life(:arg1, :arg2))
mock.verify
mock.expect(:meaning_of_life, 42 ** 2, :arg1, :arg2)と書けな
いことやmock.verifyを明示的に呼び出さなければいけないのもど
うかと思います。
また、miniunitはエラーメッセージがまるで親切ではありません。
例えば、このような失敗するテストがあるとします。
mock = Mini::Mock.new
mock.expect(:meaning_of_life, 42)
assert_equal(42, mock.meaning_of_life(:arg1))
このときのエラーメッセージはこうなります。
...
1) Error:
test_should_create_stub_method(TestMiniMock):
ArgumentError: ArgumentError
/var/lib/gems/1.8/gems/miniunit-1.2.1/lib/mini/mock.rb:15:in `meaning_of_life'
x.rb:14:in `test_should_create_stub_method'
...
メッセージなしのArgumentErrorです。何が悪いのかがわかりづら
いです。
mock.verifyで失敗したときも不親切です。
mock = Mini::Mock.new
mock.expect(:meaning_of_life, 42)
mock.expect(:meaning_of_life, 42 ** 2, [:arg1, :arg2])
mock.verify
こうなります。
...
1) Error:
test_should_create_stub_method(TestMiniMock):
MockExpectationError: expected meaning_of_life, {:retval=>1764, :args=>[:arg1, :arg2]}
/var/lib/gems/1.8/gems/miniunit-1.2.1/lib/mini/mock.rb:26:in `verify'
/var/lib/gems/1.8/gems/miniunit-1.2.1/lib/mini/mock.rb:23:in `each_key'
/var/lib/gems/1.8/gems/miniunit-1.2.1/lib/mini/mock.rb:23:in `verify'
x.rb:15:in `test_should_create_stub_method'
...
呼ばれていないexpectのうち1つだけしか表示されません。また、
失敗ではなくエラーになっているのもどうかと思います。
他にも、expectしていない引数で呼ばれたときをチェックできない
など機能不足な感があります。
また、エラーメッセージが不親切なのはassert_equalもそうです。
assert_equal("IIIIIIIIIIIIIIIIIIIIlIIIIIIIIIIIII",
"IIIIIIlIIIIIIIIIIIIIIIIIIIIIIIIIII")
この場合、以下のように表示されます。
1) Failure:
test_should_create_stub_method(TestMiniMock) [x.rb:13]:
Expected "IIIIIIIIIIIIIIIIIIIIlIIIIIIIIIIIII", not "IIIIIIlIIIIIIIIIIIIIIIIIIIIIIIIIII".
ちなみにTest::Unitはこうです。
1) Failure:
test_should_create_stub_method(TestMiniMock) [x.rb:5]:
<"IIIIIIIIIIIIIIIIIIIIlIIIIIIIIIIIII"> expected but was
<"IIIIIIlIIIIIIIIIIIIIIIIIIIIIIIIIII">.
私はminiunitよりもTest::Unitの方がテストを書く人、テストをメ
ンテナンスする人のこと考えていると思えます。
また、miniの名前の通り、メンテナは現在のminiunitの実装で十分
な機能があると判断しているらしく、これ以上機能が拡張されるこ
とはほとんどないと考えられます。何もしないのだから、それはた
しかにメンテナンスコストは下がるというのはその通りだと思いま
す。
=== 解決法
ruby-coreの方には書きましたが、特に反応もなかったので省略。
今となっては、自分で使うためのテスティングフレームワークは自
分で作ろうと思っています。