t-wadaさんとのテスト駆動開発勉強会
はじめまして、技術開発部門のgemaです。数ヶ月に渡ってコツコツと『テスト駆動開発』本を輪読する会を社内で開いてきました。先日に最終回として翻訳者であるt-wadaさんを招いての質問会を開くことができました。ここでは、当日の話とこれからの取り組みについて書きたいと思います。
『テスト駆動開発』本はこちら
そもそもテスト駆動開発（TDD）とは何かという人はこちら
ちなみに、FiNCでt-wadaさんをお招きするのはSQLアンチパターン勉強会に続いて２回目です。
質問会では色々な質問をt-wadaさんにさせていただきましたが、ここでは特に学びの多かった２つの質問とFiNCのこれからの取り組みについて紹介したいと思います。
TDDの開発者のためのテストは品質保証のテストと両立することはできるのか？
まず一つ目の質問ですが、そもそも最初に本を読む前はテスト駆動開発は品質保証のための手法だと思っていました。しかし、TDDを学んでいく過程でわかったことは、TDDのテストは開発者のためのCheckingのテストであって、品質を保証するためのテストではありませんでした。開発を助ける手段としてテストを用いるのがTDDです。
ただし、現実的にはテストに品質を保証する役割が求められることが多いと思います。そこで、TDDの開発者のためのテストと品質保証のテストが両立できるものなのか、ということが疑問として出てきました。
品質保証のテストとTDDの開発者のためのテストが混ざることでTDDの開発サイクルが遅くなったりしないのか？TDDのテストは開発者のコンディションに左右されるので、テストの粒度がバラついてしまうので品質のテストには使えないのではないか？
t-wadaさんに聞いてみました
結論から書くと両立できるということでした。開発者のためのテストコードをメンテナンス対象にしていくにつれて品質のためのテストにしていくことが可能だそうです。
TDDの段階では品質を保証することはあまり考えず、品質が求められる段階になってから、TDDの成果物としてのテストコードを軸に品質保証のテストに変えていけることがTDDのメリットでもあると仰られていました。
重要なのは、TDDの成果物としてのテストコードを早い段階でリファクタリングしていくことです。特に、品質保証の観点を持っている人とペアプロすることはおすすめだそうです。開発者のための粒度がバラついたり、網羅性のなかったりするテストコードに、第三者から品質保証の観点を入れることが重要です。
そうすることで、品質保証のためのテストに変えることができ、メンテナンスできる状態にできます。QAチームの人はコードを書けなくていいから一緒にやりましょう、というのはすごい大事だと仰られていました。開発者とペアプロを行ったり、テストケースの洗い出しを行ったりすることなどが例としてあげられていました。
Ruby on Railsにおいて、TDDは設計を悪化させるのか？
次の質問です。Ruby on Railsの作者であるDavid Heinemeier Hansson(DHH)が『TDD is dead. Long live testing.』というタイトルのブログを公開しました。
要点としてはTDDでは、大量のユニットテストが作られることにより、無駄な間接層が増え、設計を悪化させるという主張です。
TDDから導かれる悪い設計についてのDHHの詳しい主張に関してはこちらを読むのがいいでしょう。
このDHHのブログが発端となり、DHHとTDDの考案者のKent Beck、Martin Fowlerの三者で議論が行われています。
ここでKent BeckはTDDの問題ではなく、設計の決定の質が問題であると主張しています。
t-wadaさんに聞いてみました
TDDを行うことで設計が自然と導かれていくが、それが良い設計ではないという主張は衝撃的だったためt-wadaさんに聞いたみました。結論から言うと、Railsの話に限ると「TDDは設計を悪化させる」というDHHの主張は正しいという話でした。
そもそもTDDは良い設計を導くというのはどういう論理かというと、テスト可能な設計はよい設計であるというのがまずOOPにおける暗黙の了解としてあります。TDDはテストファーストであり、テストファーストはテスト可能な設計を導くので、TDDは良い設計を導くということになります。
ただし、Railsは疎結合を良しとしていないフレームワークです。例えば、Railsにはモデルとデータベースを密結合させたActive Recordという仕組みがあります。結合度を高め、機能的な凝集度を高くすることで生産性をあげることがRailsの良さです。TDDにより無駄な間接層をいれてしまうとRailsの良さを殺すことになってしまいます。
『テスト駆動開発』本の付録Cにも書かれていることですが、自分のスタイルを見つけることが重要です。ロンドン学派とデトロイト学派など、TDDも色々なスタイルがあります。これからやるべきことは、教条主義的にならずに、それぞれの良し悪しを考えて取り入れ、自分のスタイルを確立していくことだと考えました。
これからの取り組み
現状としては、開発のテストコードはほとんどCheckingのテストしかできていません。TDDの副産物としてのCheckingのテストコードを軸に、いかに品質保証のテストを行えるようにするかが品質保証のためには重要です。
そのためにも、まずソフトウェア・テストとは何かを理解し、開発とQAチームが「良いテストとか何か？」という問いに関して共通の認識を得ることが第一歩だと考えました。そこで、『テスト駆動開発』本を開発部門を中心に読んできましたが、次は『ソフトウェア・テストの技法』を開発部門とQAチームが一緒になって読む勉強会を行うことにしました。
はじまったばかりの取り組みですが、勉強会で得られた成果に関しては後日また記事にできたら、と思います。
株式会社FiNCでは、サーバーサイド・QAエンジニアを募集しています。ご興味がある方はぜひこちらからご応募下さい。
