テスト駆動開発における誤解が解けた。ケント・ベックの原典の要点と感想。

2017年1月23日2019年10月13日

ケント・ベックの「テスト駆動開発入門」(Test-Driven Development. By Example. Kent Beck)を読みました。

原典を読んでみると、グーグル検索をしてヒットするテスト駆動開発(TDD)の記事で得られる印象と異なる部分が多々あったので、感想と共にメモしておきます。

テスト駆動開発は、リズムよくコーディングをするために書くテストである。

頭のなかではっきりしていない設計をはっきりさせるための手段となるもの。

今これからすべきコーディングの内容を指し示すもの。

テスト駆動開発は、品質を保証するテストとは異なる。

三角形の種類を返すプログラムで品質を保証するためのソフトウェアテストとして、Bob Binder は65個のテストを書いたが、テスト駆動開発のためにケント・ベックは6個のテストを書いた。

I wrote 6 tests (kind of like Name That Tune, “I can code that problem in four tests.” “Code that problem.”) Bob Binder, in his comprehensive book Testing Object-Oriented Software, wrote 65 for the same problem.

テスト駆動開発の導入に失敗したという日本の記事では、テスト駆動開発のことをxUnitによるソフトウェアテストの自動化と誤解している場合がある。

米国ではソフトウェアテストは専門のテスト屋が行うことが多い。テスト駆動開発のテストコードは、日本でプログラマーが行っているソフトウェアテストを代替するものにはならない。

開発サイクルのステップサイズは変えてもよい

開発サイクルの4つのステップは次の通り。

次に実装する機能についてのテストコードを書く。
コンパイルが通る最小限の開発コードを書く。
テストが通るように最小限、開発コードを修正する。(仮実装)
開発コードの重複を取り除き、開発コードの抽象性を上げる。(リファクタリング)

テスト駆動開発ではなるべく小さいステップで、この開発サイクルを何度も回して開発してゆく。

しかし、実装コードが明白で、もしステップが小さすぎると感じる場合には、仮実装を適宜省略してもよい。「大胆に」ステップを大きくしてもよい。

テスト駆動開発は、個々人で明日からすぐに導入できるもの。

チームで導入するかどうかに左右されない。それくらい範囲の限られたところから着想を得たコーディング手法である。

ただ、それをチームまで拡張して大規模な開発を行うことは不可能ではないことも示されている。

とは言え、テスト駆動開発は、他のあらゆる開発手法と同様、どんな案件に対してもうまくいくというような万能な手法ではない。

適用が困難な箇所もある。テストの自動化が困難な箇所はやはりテスト駆動開発もしにくいのでは。

適材適所である。銀行のシステム開発をアジャイルでやろうという人はいない。

テストのコード量は、開発コード量と同等になる。

そのため、テスト駆動開発を導入すると開発コードを書ける量が半分になる。開発コード量を維持するなら倍の量働かなければならない。

また、そうなることを同僚に説明する時間も考慮に入れる必要もあるとのこと。

コーディングのコストが2倍かかることになるため、導入には理解を得られにくい。小規模の導入から始めて、手戻りが少ないことが成果として現れ、全体としてのコストに優れることがわかってきたときに、テスト駆動開発が広がるだろう。

既にたくさんのコードがあるものに、後からテスト駆動開発を適用するのは困難

そもそも、テスト駆動開発のテストは、新しく開発コードを書くときの指針として書くテストなので、すでにあるコードを「保守」するために書くテストは、テスト駆動「開発」のテストではないが、本にはこう書いてあった。

ただ既存のコードが疎結合であれば、追加機能をテスト駆動開発の手法で開発することは可能ではないかと思う。

まとめ

現在の日本のソフトウェア業界においては、テスト駆動開発の流行りが落ち着いて、その利点と欠点の議論が出終わったという状況かと思います。

しかし、テスト駆動開発の提唱者であるケント・ベックは、2002年に出版された本で既に、テスト駆動開発の欠点も良く理解していたということが分かります。

原典を読んでわかったことは、日本でのテスト駆動開発に関する批判の一部は、テスト駆動開発の誤解や不理解から生じた不幸であるということです。

原典の日本語訳が非常に読みづらいのがその不幸の原因の一つかと思います。

しかしそれでも、テスト駆動開発を理解するために、他の実践本よりも先に読む意義は大きいと思います。

以上、テスト駆動開発における誤解が解けた。ケント・ベックの原典の要点と感想。でした。