TDD

 一時期「TDDは死んだ」なんて記事が話題になった。
テスト駆動開発(TDD)はもう終わっているのか? Part 1
「TDD、いや、テスト自体がウチには合わない」なんて話を直接耳に入れたりもした。そういう環境ではそうなんだろうと思う。銀の弾丸はない。

 ぼくはTDDをかなり気に入っている。最初にテストを書き、それにパスするようにコードを書いていく。炎上中のプロジェクトにアサインされたときになぜだか個人的に使い始めたのだが、結果としてうっかりなミスやデグレードを防いでくれた。プロジェクトで見ればそのうっかりやデグレードが頻発していたが、ぼくの担当したところに対して差し戻しはなかったので、TDDによって品質をかなり高いところまで持っていけていたんだろう。
 はじめてのTDDを炎上中のプロジェクトへアサインされたときに実践したというのは、時間的な制約から一見無謀だと捉えられるかもしれない。けどぼくはこれが成功だったと考えている。一つの機能の実装が終わったときに自動テストが用意されていなければ、ふつうなら手動でテストを行うだろう。デグレードを考えるなら、行うべきテストは機能が増えるたびに累積されていき、後半ではテストを行うコストが無視できないほど肥大化してくる。ぼくはTDDによってテストを自動化していたために、累積されるテストコストをうまく回避できたと考えている。

 ぼくはTDDにそれほどの厳格さは適用していない。自分が自信を持てれば十分という位置づけで行っている。ユニットテストは自分が適切だと思うレベルでしか書かない。カバレッジ100%にする必要はないし、70%を切るようでも場合によっては全然かまわないと考えている。つか今趣味で開発しているものはカバレッジを参考にしていない。
 テストも機能実装中に刻々と変化する。自分が好きで作っているものにしろ、クライアントのためのものにしろ、仕様が変更されるってのは皮肉なことにしょっちゅうある。さらには、自分のものだとテストを書きながら仕様を決めることだってある。刻々と仕様が変わろうが、ぼくはあまり粒度の高いテストは書かないので、テストの変更は大したコストにならない。
 たとえば今、この自作のブログのエンジンを開発しなおしている。TDDで。最初にまずログイン機能を作ることを決め、書いたのはSeleniumを使ったテストである。テストは二つで合計20行から30行ぐらいだ。厳格にやるならログイン機能をに内包されている、トークン取得やトークン付与を単体テストで書くべきだろうか。さすがにそこまでやるのは手間だ。それらが協調して動いていることは、ログインの成功と失敗が確認できれば十分実証される。だからSeleniumでそれを行うテストを書いた。これから機能が追加されていくが、これ以降でログイン機能が正常に動くかを確認するのにかかるコストは、10秒程度の時間コストしかかからない。

 過度にカバレッジを上げたり、すべてのメソッドに対して単体テストを用意しろなんて命令が来たら賛成しかねる。でもTDDってそういうのを強制するものじゃないだろう。ただ自分の自信になる程度にテストを書き、のちのちのデグレードチェックの手間を省いたり、リファクタリングを安全に進めるための補助として役立てる。すごくいい仕組みだと考えている。銀の弾丸ではないにしろ、ぼくはこれを適用できるところには使っていくし、適用できるできないの判断をうまくできるようになっていこうと思うところ。
 
comment: 0