BitRoar「TDD(test driven development)がコケるとき」
2011.9.24のブログエントリ
When TDD Fails - BitRoar
- TDD(test driven development)にはいいところと悪いところある
- TDD信者（＝藁人形）はここがおかしい
という主旨のエントリ
TDDをdisる記事はマイナーなのでhacker newsでもスレッドが伸びてる
本人的には自分の考えをまとめるためにTDD信者なる藁人形をこさえた模様
以下斜め読んだ内容
- マントラ
- TDDは高品質ソフトウェア開発方法のベスト
- TDDは好きになれない？お前はクソ
- 黙ってコツコツ学べ、ゆくゆくは体得できるよ
- まあ耳にタコ。信者は至る所に
- プログラミングではTDDは万能じゃなくて問題を生むケースがある
- こんなこと言ったらアホ呼ばわりされるかも
- 観測範囲内では議論されてるのをみたことがない
- ただし、Peter Sergeantのエントリには影響受けてこのエントリ書いてる
- TDDがうまくいくケース
- 書かれたクラスやメソッドが実装してるアルゴリズムのせいで開発がややこしいことになってるとき
- 例
- 営業日／休日を計算する関数を書いてるとき
- 汎用性の高いコード、あれこれしないインターフェース、トリッキーなロジック
- TDDにうってつけ
- コードのテストに必要なものは、任意の２日と、休日カレンダーだけ
- この手のコードは再利用可能性の高いコードにもなる
- TDDがコケるケース
- TDDとアクションメソッドの相性が悪い理由２つ
- アクションメソッドでは複雑なシステムとの通信が発生することが多い
- 自分が手を入れられないシステムとの通信や連携であるケースもある
- こんなアクションメソッドをテストするときに必要になるコード
- 無数のインターフェース、ラッパー、DI（依存性注入）パターンの実装、などなど
- 「これこそ良いデザイン」と言われるコードの山。
- 追加されたコードの山がテストのためだけなんだとしたら、プロダクション環境で何もしないコードなんだとしたら、良いわけがない
- 尤も、この手の肥大化はエンタープライズの世界では蔓延してるんだが
- アクションメソッドは再利用できる機会が低い
- アクションが表現してるのが、特定のシナリオに適用できる特定のロジックだから
- 一応、PrintHelloWorldメソッドが「Hello world!」と出力とassert、とできる
- typo検出にはきっと役立つ
- 汎用性が高く再利用できそうなコードのテストでは、システムのベースになり永続的なプロパティや情報をassertできる
- 汎用性が低く再利用しにくいコードのテストは、校正チェック仕事のようになる
- 校正チェックが無意味なわけじゃないが、頻度低のエラーだし、もっと手間なく検出できる方法がある
- アクションメソッドのテストのために追加されたコードの山は、モチベーションを根こそぎ奪う元凶になる
- ビジネスの要件が変わったら？テスト書き直し。
- viewの名前を別のエンジニアが変えちゃったら？テスト書き直し。
- リポジトリクラスとして別のクラスを使いたくなったら？テスト書き直し。
- モックアップやりなおして、テストを書き直す
- 早期治療的なユニットテストはアクションメソッドで発生しがちなバグを検出できない
- アプリを構成するサブシステムの境界線上で発生するバグを検出しない
- htmlのform要素内のフィールド名の間違いは検出しない
- DBの欠落したレコードを検出もしてくれない
- アクションメソッドでは複雑なシステムとの通信が発生することが多い
- TDDがコケるのはアクションメソッドだけじゃない。他にも向いてないケースある
- グルー的に書かれたコード
- 複数ある複雑なサブシステムと通信するために書かれたシンプルなメソッド
- マントラその２
- それはコードが悪い
- テストできないものは、悪いデザイン
- テスト1stを原則にデザインされたものが、良いデザイン
- こんな風に言ってる人は厳密にはいないので、誇張してる部分は認める
- でもマントラを体現したようなエンジニアは結構いる
- TDD信者は、特殊な開発プロセスと品質を同一してる
- その開発プロセスが品質を保証するというのがミソだとしても
- 循環論法臭い
- もちろん、ユニットテスト可能なようにコード書いていれば、スパゲッティコードでできたお化けメソッドは生まないだろう
- クソみたいなソフトウェアを生み出してしまう開発プロセスは他にもある
- 抽象化レイヤーの数が増えすぎた
- なんでもフレームワークになってしまった
- あらゆる処理とバグがconfig/DBに書き出されることになった
- ある機能が単体で意味をなさないピースに分割され、ピースが連携して動かすようになった
- 実例を目にしてきたが、テスト1stでやって挙げ句にこういうまずいケースを生むことだってありうる
- 結論
- だいだいPeter Sergeantのエントリと同じ
- TDD＝悪ではない
- テストは色々ある。ユニットテストだけじゃない
- テスト以外にもソフトウェアの検証方法はある
- 比較した上で手法は選ぶべき
- 自分が選んだ手法を使った結果からのフィードバックを受けずに自分の手法が正しいとか言わない
補足エントリ書かれてる
More on Testing - BitRoar
補足エントリだが繰り返し言ってるところがおおい
- 繰り返すがTDD=悪、とは言ってない
- TDDがフィットする場面
- 他のツールや手法に軍配があがる場面がある
- 実装したコード１行ずつコードせずに、自動化されたUIレベルのテスト使うとか。アプリ全体のテストできる
- disする人の頭から抜け落ちてるのは、品質保証の手法は他にも色々あること
- 関数型言語
- 論理プログラミング
- etc..（10個弱例示してる）
- TDDはビジネス要件の影響を受けない、基礎的なピースやモジュールの検証には向いてる
などなど
