私家版テスト駆動開発
テスト駆動開発(TDD)をやってみたいけど最初の一歩がなかなか踏み出せないという人が少なくないようだ。あまり形式張らずに出来るところから少しずつでも挑んでいくのがコツだと思うのだけど、教科書に出てくる「正しいやり方」に躊躇してしまうケースがあるらしい。そんな訳で、今回は我流のテスト駆動開発方法を紹介してみたい。
- テスト戦略を決める
制限のある開発期間内に効率的にテストコードを作る必要がある以上、何を目標として何処までをテストすべきか目標を決めておくことは欠かせない。もちろん、カバレッジ100%のコード作成は望ましいものの、異常系を含めてそこまでの網羅率を実現するのは難しいことが多いし、GUI処理は時間をかけてマクロを作るより人間が目視で確認した方が手っ取り早かったりする。費用対効果を考えて、もっとも効果の大きい箇所を重点的にテストコードでカバーすることを考えたい。 - テストコードは後付け
由緒正しいテスト駆動開発の本には「最初にテストコードを書きましょう」というウォータフォールもビックリの堅苦しい手順が記載されているけど、実際問題としてこれはかなり難しいのではないだろうか？実装よりも前にテストコードが書けるのは「仕様が全て決まっている」「アーキテクチャが全て決まっている」「設計方針に一切変更が無い」という条件が全て満たせる時だと思うのだが、実際の開発現場においてこんな状況はあり得ない。開発途中で仕様が毎日コロコロと変わっていくことは珍しくないし、仮にテストコードを先に書いてみたところで、直ぐに使い物にならなくなってしまうのは明らかだ。だから、実装コードとテストコードを同時並行で書いたり、仕様や設計方針が決まって実装側に変更が入らないと確認出来て初めてテストコードを書くようにしている。最終的に動作検証出来れば良いのだから、最初からテストコードの存在に囚われる必要はないと思っている。 - 正常系の確認を優先
異常系の動作がおかしくなってしまうよりも、正常系の動作がおかしくなってしまうことの方が、不具合流出時の影響範囲が大きい。利用者側から見れば、バージョンアップによって、今まで使えていた機能が使えなくなってしまったら怒るのは当然だろう。だから検証ではとにかく全ての正常系の動作を確認出来るように力を注ぐようにして、異常系の検証は後回しにしている。元々発生確率の低い異常系の動作を検証するのは労力が勿体ないし、もともと異常な状態がさらに悪化したところで大した問題ではないと思う。 - 設計時の考慮が必須
単体テストのことを考慮せずに完全に組み上がってしまったコードを、後からテストするのはかなり面倒だ。設計時点からテストの方法を考慮したクラス、インターフェース設計をしておくことが不可欠であり、上手く分割出来るクラス構成にスタブやモックを組み合わせると単体テストが簡単、かつ網羅的に行えるようになる。もちろんこのためにはクラス間の依存性を減らすためのオブザーバパターンを導入するなど、デザインパターンを始めとする技術的な知識が欠かせない。 - 本領発揮は派生開発時
少々大きな開発プロジェクトでも、開発時には様々な情報が頭に入っているのでテストコードの有り難みは分からない（テストにパスして当然だ）。テストコードが本当に役立つのは、ソフトウェアのリリース後に行われる機能拡張や仕様変更の開発時だ。そのような派生開発時には仕様の部分理解の元でコードの一部を変える必要があり、その変更が引き金となって引き起こす副作用箇所の検出に、テストコードは大きな威力を発揮する。開発者自身が気がついていない、或いは見逃していた箇所を自動的に暴き出してくれるのだから、デグレード防止用としてテストコードの存在意義は大きいはずだ。 - カバレッジでテスト漏れを確認
テストコードによって検証した範囲を確認し、不足箇所のテストコードを追加したり、あるいは従来通りの手作業による検証を行うために、何をテストして何がテストされていないかという情報は重要だ。単体テスト実行時には、必ず同時にカバレッジの確認も行って、テスト漏れがないか確認する必要がある。また、カバレッジの数字が見えてくると、少しでも対象範囲を広げようと開発者は頑張ることが多いようだ。 - 完璧を求めない
実際にテストコードを書き始めると「privateメソッドの検証方法は？」とか「依存するライブラリがまだ出来ていないので検証出来ない」等の様々な課題が上がってくる。技術的なテクニックで対処出来るものがある一方で、このようなテスト方法では対処出来ない問題も存在している。そんな箇所を気にかけていたらいつまで経ってもテストの自動化は見込めない。手元にある一つのメソッドや一つのクラスの確認から着手して、少しずつ対象を広めていくことが肝要だろうと思う。
かなり自己流のやり方なのでケント・ベック先生には怒られそうだけど、手作業での検証箇所が少しでも減らせることが出来るのならそれでOKという方針なので、割と上手く行っている。理想を言えばキリがないけれど、一部でも検証可能なコードは手元にあるハズ。まずは自分で試してみてはどうだろうか？
関連
