トップ «前の日(02-25) 最新 次の日(02-27)» 追記

2003-02-26

_ 勝手に slashdot バナー

画像の説明

最近、slashdot.jp のメインのストーリーの方がさっぱり面白くないと感じていたのですが、先日の脱線をきっかけに日記の方に重点をシフトしようかなと思い始めました。ちょいとうろうろしていたのですが(このうろうろがものすごくやりにくい!)、ふと見たバナーページのバナーに気に入ったものが一つもないので、

しゃあなしで

自分で作ってしまいました。

Tags: 日々 Web

2004-02-26

_ Lynx でマウス

Lynx に対する w3m の最大のメリットはマウスが使えることとレイアウト用の TABLE も正しくレンダリングできることだと思っていた(タブは使わないので)が、実は Lynx でもマウスが使えた。けっこうびっくり。でも cygwin と Debian の Lynx 2.8.4 では使えたが、FreeBSD では terminal の設定に影響されて「カラー表示でマウスを使う」ことができないでいる。うーぬ。

Tags: Web Tool

_ phpdoc on eclipse

phpdocumentor はデフォルトで @access private なメソッドのドキュメントを生成しないようだ。これがコマンドラインから起動するならオプションの設定は楽なのだが、eclipse からの phpdoc はどうやってオプション設定するのだろう?(^^; まぁ @access private は PHP 5 にならないと意味ないコメントなのだが。

Tags: Web PHP Tool

_ FreeBSD 5.2.1

出たぞ出たぞ。そろそろ current に移行しちゃおうかな?

Tags: Unix News

_ Matz日記収束か?

なんとなく私と同じような結論に至りつつあるらしい。

まーでも私は個人的にはオープンソースなんて面倒くさいからみんなフリーソフトウェアにしちゃえ派ですが(こら


2011-02-26

_ RSpecのdescribe, context, itと感想

RSpec の動かし方だけは分かってたんだけど、あんまり真面目に整理したことがなかった。少しだけ真面目にドキュメント読んでみた。

基本概念

explicit subject - Subject - RSpec Core - RSpec - Relish

RSpec is a DSL for creating executable exmaples

おぉ、なるほど。

コードが動作例のように見えることが大事ってことか。テストらしく書くのではなく動作例らしく書く。そうすると実行結果のレポートもとても自然に読める。これが設計書のように読める。

基本構造

  • ファイル : spec
  • describe : example group
    • context : alias of group
      • it : example

it はどこで定義されているのかよく分からないけど

 it 'behavior' do
   ...
   テストしたい振る舞い
   ...
 end

でも

 it {
   ...
   テストしたい振る舞い
   ...
 }

でも良いらしい。it の中身が DSL の力を借りて英文そのもののであれば `behavior' は省略しちゃうという流儀もあるらしい。

cf. RSpec 2 Best practices

でもそれって

日本語でレポートを作れる

っていうメリットがなくなるような?

context ってどう使うの?

describe の alias として context は用意されているが、こんな感じで使うのがいいんじゃないか案。

describe MyClass do
  describe 'this method' do
    context '条件' do       # 英語だと 'in ...' とか 'when ...' とか ?
      it '振る舞い' do
        obj.should be_XXX
      end
    end
  end
end

みたいな感じがE和スタンダードみたい。(間違ってたらツッコンでください!)

確かにこれが自然かも。なるほどなぁ。

Twitter / @SHIBATA Hiroshi: @wtnabe あー、そこについてはケースバイケース ...

感心したこと

RSpec って書き方自体は知ってたんだけど、あんまり意味が分かってなかった。あと、読みやすさの代わりに書きにくさがあるなーと感じていたんだけど、これは誤解だなと思った。むしろテストを分類しやすくてとても書きやすい。

これまでも xUnit 系のツールは使っていたんだけど、なんだかとても読みにくくメンテしにくいテストコードを量産していたように思う。少なくとも確認したいことの単位でメソッドを起こしたりはしていなかった。何かを意図していたわけではないけど、一つのメソッドに対するテストメソッドが 3つも 4つもあるのも変な感じがしていたし、メソッド名が長くなりがちなのもいい印象を持てなかった。

それが RSpec だと違和感なく書ける。describe を階層化できるから確認したい振る舞いの名前に重複が発生しない。つまり DRY だ。

もう一つ、diff の出力が素晴らしい。もうほんとこれはすごくいい。これだけでも Test::Unit からの乗り換えに十分値する。

まぁ Test::Unit2 はさらにその上をいくらしいんだけど。

cf. デバッグしやすいassert_equalの書き方 - ククログ(2011-02-28)

Tags: Ruby RSpec