BT

TDDを諦める

| 作者: Abel Avram フォローする 7 人のフォロワー , 翻訳者 吉田 英人 フォローする 0 人のフォロワー 投稿日 2016年4月14日. 推定読書時間: 6 分 |

原文(投稿日:2016/03/23)へのリンク

この記事は,TDDに見切りをつけたある大学教授の経験と,Uncle Bobの反論を要約したものだ。

ソフトウェア工学の大学教授を退官したIan Simmerville氏には,“Software Engineering, 10th edition”を含む数冊の著書がある。同書の第8章はすべてソフトウェアテストに関する内容であり,特に8.2章ではTDDを取り上げている。それらの章で紹介された考え方を何度も引き合いに出しながら,Sommerville氏は先日の記事に,“TDDはソフトウェア工学の大きな進歩です。いくつかのクラスのシステムにおいては,それが有効であることが明らかです。”と述べて,次のような“TDDフレンドリ”なシステムの一覧を紹介している。

  1. 階層化アーキテクチャ
  2. 合意された成功基準を持ち,それに準拠したテストに基づいて構築されるシステム。
  3. 自身のコントロールを越えてシステムと対話する必要のない,コントロール可能な環境。

このようなシステムならばTDDは良好に機能する,とした上で氏はさらに,それに該当しないシステムでTDDを使用したことによって,難題に突き当たった自身の経験を説明している。

最初これらの基準を満たすシステムでTDDを使い始めた時には,使い勝手もよく,結果も良好でした。そこで次に,複雑なリンク構造の可視化を課題とするシステムに適用することにしたのです。しかしながら,可視化という作業には,(a) UIプログラムのように,明確に分離されたレイヤを持つことが難しい,(b) 成功基準を事前に定義することが極めて難しい - 基本的に試行錯誤を繰り返してプログラムする必要がある,という面があり,TDDではうまく行きませんでした。

Sommerville氏は “Giving up on test-first development”という記事でも,個人的なプロジェクトでのTDD経験について書いている。TDDは当初は有効だったが,GUIの作業に着手する頃になると,テストの記述が非常に難しくなり,テストの作成に費やす時間が無駄に思えるようになってきた。その結果として氏は,場合によってはテストより先に実装コードを書いて,後でテストを追加する方法を用いるようになったのだ。最終的にはTDDを諦めた氏は,それを次のように説明している。

(一般的に言われているような)GUIの自動テストの記述が難しいために,TDDを断念したのではありません。保守中心のプログラミングを強いられること,プログラム上の判断よりもテスト可能性を考慮した設計を強いられること,構造よりも詳細な部分に注目せざるを得なくなること,そしてプログラム作業の最も大きな課題である,予期しないデータに関する問題に対して機能しないこと,などが理由です。

さらに詳しい説明として,

  • TDDは保守的である – 多数のテストが失敗して書き直しを余儀なくされるため,アプリケーションの大幅な変更に対してはいきおい消極的になる。
  • “時として,最高の設計はテストが難しいものである”。
  • TDDは全体よりも詳細に焦点を置く。“TDDでは,プログラムのさまざまな詳細部分に注目することになり,一歩引いて全体を見渡すことはほとんどない。”
  • 予期しないデータによるテストの記述が困難である。

そのため氏はまずコードを書き,テストはその次とした。しかし,氏の記事が見過ごされることはなかった。Robert C. Martin氏,通称“Uncle Bob”が,“a rebuttal of Sommerville’s arguments on giving up on TDD”という記事で議論に加わったのだ。Uncle Bobは,Sommerville氏の経験は初心者のトラブルであって,諦めるには早過ぎると考えている。ひとつのコンポーネントの変更が別のコンポーネントを棄損するのは,システムの2つの部分が緊密に結合されているためだ。テストの失敗を心配してリファクタを躊躇するというのは,テストコードと製品コードが強く結合され過ぎているということに他ならない。システムを独立したレイヤに整理して,各レイヤ間はインターフェースを介してアクセスするようにし,そのインターフェースをテストでも使用するようにするべきだ。

Uncle Bobは“最高の設計はテストが難しい”という考えを,くだらないものだと言下に否定する。テストのできないような設計は,おそらく必要な時に機能しないものだろう。GUIやデバイスドライバなどの困難なケースについて氏は,The Humble Dialog Boxパターンの利用という選択肢を指摘している。

TDDが詳細にあまりにも重点を置いている,という点にも,Uncle Bobは異議を唱える。開発者は常に設計しなくてはならないのだ,と氏は主張する。

ユニットテスト,受け入れテスト,あるいは製品コード,あるいはモック,スタブなど,どんなコードを書く場合にも設計は必要です ...

私たちはプログラマなのです!設計します。凝縮性の高い,結合性の低い構造を作り上げます。依存性を管理します。モジュールを分離します。設計するのです。

プログラマは時に設計を忘れる,とUncle Bobは言う。特に初心者は,どのような分野であれ,低レベルの詳細な部分に注目する傾向がある。それは彼らが学習の過程にあるからだ。氏は,Ron Jeffries氏 – XPの共著者であり,アジャイル憲章の署名者 – の “全体を考えよ,部分で行動せよ” ということばを引き合いに出して,全体像を意識することの重要性を強調する。

最後にUncle Bobは,予期しないケースを考慮に入れることが極めて困難である点には同意しつつも,それはTDDの問題ではない,と主張する。

アポロ1号は火災を起こしました。アポロ13号は月に向かう途中で爆発しました。チャレンジャーは打ち上げ直後に爆発しました。コロンビアは再突入時に破壊しました。なぜでしょう?何千という頭脳がすべてを考え抜こうとしたにも関わらず,予期しない何かが起こったからです....

それに対処すること。リスクは常にあります。TDDのせいではありません,諦めないでください。

ソフトウェアエンジニアのIsrael Fermin Montilla氏は,Sommerville氏の記事に対して,もっと同調的な立場でコメントしている

テストを先に書くか後で書くかが問題なのではなく,とにかくテストを書いて,規律を持ってそれを維持管理し,プロジェクトで必要とされているコードカバレッジを厳格に守ることが重要なのだと思います。テストを先に書くことのメリットは明白ですが,そのテクニックがすべての人たち,すべてのプロジェクトで実行可能な訳ではありません。私の経験でも,時間的な制約のために,まず実装を行なって,重要な部分のみテストせざるを得ない場合はあります。私はスタートアップとインターネット企業で働いた経験しかないのですが,非常にハイペースで,マーケティング重視の環境です。そのため,リリースと評価データの収集を目的として,(特にスタートアップの初期段階では)時には多くの技術的負債を抱えることもあるのです。

 
 

この記事を評価

関連性
形式
 
 

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT