rubyベストプラクティスchapter6.1

デバックのプロセス。

ある程度出来たコードに対して不安要素を確認していく過程なのかな。。。

  1. ちょっと逸脱したテストケースを考えて
  2. pメソッドとかログメッセージとかで上記のテストケースがうまくいくか確認して
  3. irbで詳細をおってみて
  4. テストを書いて
  5. テストをパスするようにライブラリコードを修正する

といった流れを具体例をまじえながら説明してくれる。

本文では「テストコードを先に書くべきだった」あるので、このケースはテストコードが無い場合なんだと思う。
すでにテストがある場合は

  1. ちょっと逸脱したテストケースを考えて
  2. テストコードを書いて
  3. 失敗することを確認して
  4. irbとかで詳細をおってみて
  5. テストをパスするようにライブラリコードを書く

だと思う。

今までirbって調査のためにあんまり使わなかったなぁ。というのが反省点。簡単なメソッドの返り値を調べたりする程度にしか使わなかった。
そういえば、railstokyoでmoroさんのコードリーディングセッションでirb使って、コードの理解を深めるのにirbを使ってたのを思い出した。

irb -I hoge_directory

ってやるとそのディレクトリをライブラリパスに追加した状態でirbが起動して、

irb -r hoge

ってするとそのライブラリを読み込んでirbが起動するってのは勉強になったけど使ってなかった。こういった基本的なことって、当然のごとくリファレンスマニュアルにあるんですよね。
やっぱり振り返ると色々あるなぁ。


Rubyベストプラクティス -プロフェッショナルによるコードとテクニック

Rubyベストプラクティス -プロフェッショナルによるコードとテクニック