Rubyist til i die

■ 1.8 or 1.9.1 12:28

初心者に薦めるのはどっちか、とか、入門レベルの授業でどっちを使うか、とかいう話題がちらほらと出ていて、思ったのは

• 今、1.9.1を薦めないと、将来乗り換えコストが発生する。しかも多分、将来の方がコスト大
• 1.8を薦めたがるのは、要するに、教える側のコスト（自分が相違点を把握できてない、教科書を更新する手間）を掛けたくないだけだろ

と思った。

そんなもん、1.9.1に決まってるでしょうが！

■ [Rails]DBのダンプ方法 09:18

RailsからDBをダンプする方法はないのか？ワタシが知らないだけ？とりあえず、

def dump
  env = ENV["HOMEPATH"]
  dbname = "db_#{RAILS_ENV}"
  path = env + '\\' + dbname + '_dump.sql'
  command = 'mysqldump -u hoge ' + dbname + ' > "' + path + '"'
  if system(command)
    @message = path
  else
    flash[:notice] = "データベースのダンプに失敗しました"
    @message = "#{$?} : #{command}"
  end
end

というような（実際はちょっと違うけど）感じにしているが、これはちょっとダサいなあ。

なんかいいアイデアあったら教えてください。

■ [tips]テストの時だけprivateなメソッドをpublicにする方法 01:55

デバッグのときだけExampleクラスにdebug_methodメソッドを追加し、 private_methodをpublicにする。なんて強力なんだRuby。

83's : デバッグ用メソッドはどうするか

いやいや、そこはTest::Unit::TestCaseを使ってですね…というのはともかく、そうか、テストの時だけ改めてクラス定義してprivateなメソッドをpublicにすればいいのか。目から鱗。

class Hoge
  private

  def foobar
  end
end

というprivateなfoobarメソッドに対して、

class Hoge
  public :foobar
end

class TestHoge < Test::Unit::TestCase
  def test_foobar
    hoge = Hoge.new
    assert(hoge.foobar)
  end
end

などとやれば、テストの時だけ一時的にfoobarをpublicにして外から呼び出せるという仕掛け。インタプリタ様々ですね。

■ system()の戻り値はifとかで使いたい 01:19

I can see the reason for distinguishing the three, but I think that using an exception might be a bit too much: most of the time, you simply want to write

if system(...)

As a user of the API, your first priority is knowing whether it worked. You _might_ then be interested in knowing why if it failed. I'd definitely support the nil/false approach over using an exception.

Re: Change in system() behaviour

Ruby 1.9ではsystem()の戻り値はtrue/falseだけではなく、コマンドが見つからなかったりすると例外Errno::NOENTが発生するという話に対するDave Thomasの反応。

確かに、コマンドの結果はifで使えるものにしておいてほしいな。なんか別の組み込み変数とかで分かれば十分じゃないかな。$!とか。

■ [question]Test::Unit::TestCase#setupの使い方について 08:05

setupイラネ。

• たしかにDRYにはなるけど、テストメソッドのみだとテストは完結しない。
• setupを実行する必要がないのに実行してしまうことがある。
• テストが長くなると、最悪、setupに気付かないでテストを書いてしまうことがある。
• 長いsetupが必要になってきたらリファクタリングすべきという警報だ。
• one assertion per testを実践してたらsetupなどそもそも不要。

setupは不要だが、teardownについては述べていないようだ。後片付だからsetupと違ってそこにテストを理解する情報がないってことなのかな。

ひとつのテストメソッドにはひとつのassert文、そしてEmacsサポート - ’(rubikitch wanna be (a . lisper))

でっかいファイルを処理して情報を取り出すようなクラスを書くと、個々のメソッドのテストにいちいちヒアドキュメントとか書いていられないので、setupで一発ドカンとでっかいファイルをTempfileオブジェクトにputsしておいて使ったりしますが、そういうのはマズいでしょうか？

いや、マズいというかsetupてテストメソッド毎に実行されるので、setupに書いておいてさえかなりの負荷になるし、one assertion per testなんてもうムッキーと叫ぶくらい遅くなってしまうので絶対できない。

なんかこう、でっかいファイルは一回書いておいて後のテストでは使いまわし、っていうのがいいのだと思うけれど、どうやって実現すればいいのかいまいち分からない。ソースコードに別途含めておくのがいいのかな。みなさんどうしてますか。

クラス変数という解法

rubikitchさんからお返事。ありがとうございます。

テストメソッドの外に書いて定数だかクラス変数だかに入れておく。Railsでもfixtureをテストメソッドの外に書いては複数のテストメソッドで共有している。

class FooTest < Test::Unit::TestCase
  @@large_data = LargeData.new("arg")

  def test_xxxx
    # ...
  end
end

ひとつのテストメソッドにはひとつのassert文、そしてEmacsサポート - ’(rubikitch wanna be (a . lisper))

なるほど、それなら処理は1回ですみますね。そこでヒアドキュメントしておけば、テスト自体と離れて困ってしまうこともないか。ふうむ。勉強になります。