よりによってこの時期にと思われるかもしれないけど、ラジオを買った。ラジオ聴くのは久しぶりだ。
更新情報
texttemplate.py r1519 公開。この小さなモジュールは今まで結構地味に使ってきていたのだけど（掲示板もこれを使っています）、いまいちコードに自信がなかった。まあ今も自信があるわけじゃないのだけど、このたび結構がんばってリファクタした。行数も減ったし見通しもよくなったので、今後機能の追加もやりやすくなったと思う。
プログラミング読みもの紹介
なんでリファクタリングをがんばったかというと、最近ユニットテストについてのよい読みものを読んだ影響です。ユニットテストについて、じつは今までどうもぴんとこなかった。いや、役割と効用はわかってたつもりだったんだけど、自分の開発手順にどう組み入れていけばよいのかが難しかった。
テストの本とか適当に買って読んでみたりしたのだけど、「境界が危ないのでそこをテストする」とか書いてあって、「引数に -1, 0, 1, 最大値、最大値-1, 最大値+1 を与えてチェック」みたいなことを奨励していた。それでなんというか「あらゆるケースを網羅しておくことでバグをなくす」という神経症的なプロセスに見えて恐れをなしたりしていた。
数値の計算結果を返すような単純な関数ならそれは必要なんだろうけど、それよりも一段階抽象化を進めたレベルのクラスやモジュールではどうなのか。そこでもそんな強迫的なアプローチが必要なのかと思うと、それこそいくつテストケースを書いてもきりがないじゃないかと憂鬱になってしまう。たとえばテンプレートのコードをパースするとして、そのトークンの組み合わせは膨大な量になる。そのほとんどは無効な組み合わせになるわけだけど、それをパーサやハンドラのテストとして網羅的にやるべきなのだろうか？ ところが以下のリンクのひとつに、クラスのテストでは「メソッドではなく振る舞いをテストする」と書いてあって、なるほどと思った。ようは、テストにも粒度の概念が必要だというのがわかっていなかったのだった。
それからスタブやモックについても、なんでそんなものが必要になるのかがいまいちよくわかってなかったのだけど、場合によっては小さなクラスのテストにも使えるものなんだということもわかった。（また逆に、必ずしもないといけないものでもないということもわかった。）テストがクラス間の依存関係をなくすのに役立つというのも今ごろになって発見した。
わかっている人にとっては何を今さらというような話だと思うけど、じつはよくわかってなかったことをここに告白しておきます。以下の記事がとても参考になった。英語が多いけど。載せている順に読むのがおすすめです。
- Writing Great Unit Tests Best and Worst Practices ? Steve Sanderson’s blog
- Unit Testing Best Practices
- Mocks Aren’t Stubs
- コード品質を追求する カバレッジ・レポートに騙されないために
あとはあと一年くらい修行したらきっともう少しテスト書けるようになるだろう。
おまけ
リンク紹介したついでにぜんぜん別件ですが最近見つけたものを追加。たいへんわかりやすい JavaScript 入門スライド。