ある技術者がRSpecに目覚めるまで
テスト駆動開発が有用だと理屈ではわかっていても、
実際になかなか適用できないと悩んでいる方は多いと思います
今回は私がRSpecを通して、自分なりの「テスト駆動開発」を見いだすまでのお話
・・・すでにやってる方はスルーしてください(´･ω･`)
「プロ」の技術屋であれば誰でも、確実に「テスト」はやってると思います
つい先日1年以上続いたプロジェクトが開発完了しまして、
運用フェーズに入ったのですが、
単体からリリースまで、当然いろいろなテストを通してます
ただ、そのテスト手法が「プロセス化」されてるかというとそんなこともなく、
テスト駆動開発（TDD）へのあこがれはあるものの、
一人だからいいや・・・という感じで先送りに(´･ω･`)
昔「テストファースト」に失敗したわけ
そもそも、私がこの業界に入った頃には、
「XP」とか「アジャイル」って言葉が注目されはじめてました
（たぶん、5〜6年前？）
私のいた会社は比較的大手のSIerでしたが、
当時、Webの事業部は会社的には浮いた感じの部署でして、
少数でわりといろいろできました*1 *2
Eclipseはまだ2.xの頃から使ってましたし*3、
まだ部署内でも一般的でなかったUMLで設計書を書いたり、
CVSでコードを管理したりΣ(・ω・ノ)ノ
今では信じられない話ですが、当時は（社内で？事業部で？）CVSすら一般的ではなく、
私が一通りドキュメントをまとめ、グループ内の環境を作ったのですが、
当然かなりスムーズに開発が進みました
（いや、本当に今では信じられない話ですが・・・）
そんなグループでしたので、「アジャイル」や「XP」にも興味がありまして、
私の「師匠」*4が「テストファースト」でやりたい、と
私もその手の本を読んでいて、興味は持ったものの、
とりあえず師匠が自分に適用してみるという話だったのですが、
見事に頓挫しました(´･ω･`)
理由はいくつかあるのですが・・・
- テストを書くのが面倒すぎた
- JUnitはすでにあったかな・・・？
- テストを書くためのノウハウが今とは比べものにならないほど乏しかった
- 元々、大規模プロジェクトのわりにコード品質が高かった
・・・こんなところですか
それ以降、大小いろいろな会社を回りましたが、
どこも「開発プロセス」って言葉以前の感じで、
私自身、アジャイルって言葉が忘却の彼方に・・・
私に合ったTDD手法
話は一気に最近まで戻るわけですが、
今月から新しいプロジェクトを始めるにあたり、
いろいろな使えそうな技術や情報を取り込んでました
（前回まとめたKVS関連もその一部です）
この前のデブサミでも開発プロセスの話が盛況だったようですし、
一人とはいえ・・・というより、一人だからこそ、
何らかの手法は確立すべき何じゃないかと思いまして
さっきの話のように、一人ですら回せないプロセスが、
グループで回せるはずもないわけです
すでにRedmineを使ったチケット駆動開発はやっていたので、
今度はテスト駆動開発だろうと、
この前もCucumberのセッションを見てきたりしました
Cucumberはともかく、せめてRSpecだろうと、
まずはるびまの記事を読みまくりました
Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)
Rubyist Magazine - スはスペックのス 【第 2 回】 RSpec on Rails (コントローラとビュー編)
あとは実践するのみ・・・と、
プロトタイプのコードに「テストファースト」を適用しようとしたところ、
いまいちしっくりこないのです(´･ω･`)
頭の中に大雑把なロジックがある状況で、
いちいちテストのコードを書くのが煩わしいんですよね
その暇があったら一気に書いちゃえ、と
（おそらく師匠もそう思ったはず）
たぶん、RSpec自体に慣れてないのもあるんだろうと、
RDGC*5のコードに対して、RSpecのコードを書いてみたところ、
一気に視界が開けました(｀･ω･´) ｂ
以下、あまりに当たり前のことを書きますが・・・
0)
前提として、「一応動いているコード」が存在していること
テストをしてないわけではないが、
RSpecのような客観性を持ったテストは定義されていない状況
1)
すでに動いているコードに対し、別な角度から解析するロジックを書くことで、
そもそも何をやりたかったのかがはっきり見えると同時に、
その妥当性を客観的に担保できる
（明日の私はともかく、1ヶ月後の私がコードの意図を覚えているかは怪しい）
2)
テストを書くという行為は、
コードを他者にわかりやすく説明することに他ならず、
テストが書けないってことは、設計が怪しいんじゃないかと思える
（特にRDGCは「基盤」ですからね）
3)
テストを書くことで、実装に集中していたときには見えなかった、
「穴」や「抜け」が明らかになる
（Areaの保持範囲でない座標にTileをセットしようとしたらしたらどうすべき？ とか）
4)
実装に対してテストコードを書くことで、
動作仕様を客観的にfixできるため、大胆にリファクタリングできる
（昨年のデブサミにあった「レガシーコード」の話そのもの）
5)
そもそも、RSpecのコードは非常に書きやすく、
1)〜4)の利点がわかってくると、逆にテストを書くのが楽しくなる
このあたりが見えたとたん、本気でテンションが上がってきまして、
思わずRDGCのRSpecを書くことに没頭しそうに・・・
（あくまで仕事中だから・・・＞私）
要するに何が言いたいのかというと、
私に「純粋なテストファースト」は合わなかったってことです
- とりあえず頭で組み立てたロジックをさっさと実装しちゃう
- 大雑把に（RSpecを使わず）単体テストしつつ、見える範囲でバグを除去
- ここでRSpecを使い、書いたコードを外から確認する
- 理想的な設計になるようにリファクタリング
- ヽ(`･ω･´)ノ
仮組みしないとそもそも動くかわからないって場合は多く、
その状況でテストを書いたとしても、
テストが妥当かは判断しづらい部分があります
Railsみたいにフレームワーク化されちゃえばテストファーストもありですが、
「より現実的なテスト駆動開発」を見いだした意味で、
RSpecをRDGCで試したのは大きかったのかなと
というわけで、Ver0.2でGitやRSpecを本格的に導入するためにも、
多少あれなコードだとしても、RDGC ver0.1は今週末リリースを目指します(`･ω･´)
どうでもいいおまけ
ここのところ、連続で技術ネタを書いてますが、
本当はAmazonシリーズの新しいのを下書きで保留してまして
デブサミの前後で、技術書を大量に買い込んでるので、
漫画系のネタをさっさと片付けないと、こっちの話が書けないのですが・・・
まあ、読み切ってないからいいか(´･ω･`)
*1:「本体」に取り込まれ、自由にできなくなったあたりで辞めました あのタイミングで辞めた人は多かったようで
*2:ところでこの会社、「情報漏洩ソリューション」なるものを売ってるわりに、見事に退職者の個人情報をnyに流しやがりまして しかも、それに関する社内教育を行ってる人事部が、です それをマスコミに投げてみたのですが、相手にされず、たぶん闇に葬られたかと・・・
*3:「師匠」いわく、「あの時に本を書いておけば売れたよな・・・」
*4:外部の人でしたが、非常にレベルの高い方でした 私の技術的なベースはほとんどこの方から「盗んだ」気が
*5:Ruby(Random) Dungeon Game Core http://sourceforge.jp/projects/rdgc/
