【感想】テスト駆動開発(TDD)を読みました。振る舞い駆動開発(BDD)も絡めた自分なりの感想を書きます

名著として有名な「テスト駆動開発」を読みました。元々は古い本だったのですが、和田卓人さんによる新訳版が2017年に出版されましたので、読んでみようと思い手に取りました。

テスト駆動開発

テスト駆動開発

本記事に書く感想は、厳密なテスト駆動開発(TDD)の話というよりは、自分なりの感想であり解釈です。

その点、ご了承願います。

テストを通じてプログラム(コード)を育てる

まず、私が最も感動したのは「レッド・グリーン・リファクタリング」という方法です。

  1. レッド: 動作しない、おそらく最初のうちはコンパイルも通らないテストを1つ書く。
  2. グリーン: そのテストを迅速に動作させる。このステップでは罪を犯してもよい。
  3. リファクタリング: テストを通すために発生した重複をすべて除去する。

引用:テスト駆動開発

私の解釈としては、以下のようになります。

  1. レッド:テストを1つ追加します。対応するコードを書かないとエラーになります。
  2. グリーン:まずはエラーを解消します。
  3. リファクタリング:エラーを解消するために暫定で書いたコードを、綺麗にしていきます。

感覚的には、これはテストを通じてコードを育てているのではないかと思いました。

よくタスク管理では、タスクは細かく区切ることで、進捗の可視化を高めたり、一歩ずつ着実に前進しようといった取り組みが紹介されますが、本書で紹介されている「レッド・グリーン・リファクタリング」は、まさにそれのプログラミング版です。

重要なのは、一度にたくさんのテストを書かないことです。一度にたくさんのことを実現しようとすると、普通の人であれば、脳がオーバーフローを起こします。一歩ずつ着実に進むのです。

テストが増える度に振る舞いが増える

「付録C 訳者解説:テスト駆動開発の現在」で、ビヘイビア駆動開発・振る舞い駆動開発(BDD)が紹介されています。

私は、このBDDという考え方がとてもしっくり来ました。TDDは、まさにテストによってコードの振る舞いを表現しているのです。

Dollar dollar1 = new Dollar(5);
Dollar dollar2 = new Dollar(5);

// 5ドルと5ドルを足すと、10ドルと等しくなるという振る舞い
assertEquals(dollar1.plus(dollar2), new Dollar(10))

プログラム(コード)を育てるという、前項の話にも通じるのですが、テストコードを通じて振る舞いを足していくことで、プログラムが少しずつ豊かになっていき、目的とする仕様へと近づいていきます。

ここでも大事なことは、一つずつ振る舞いを足して行くことです。千里の道も一歩からというわけです。

テストを足していった結果、振る舞いが保証されたコードが出来上がる

TDDで行っていることは、テストであり、設計であり、分析です。

  • プログラムに求める仕様(条件)を、テストを通じてプログラムに伝えます。
  • 要求に応えるコードを書きます。

上記を繰り返す事で、プログラムの振る舞いを仕様に近づけていきながら、尚且つ、テストによって振る舞いが保証されたコードが出来上がっていきます。

常に品質を維持しながら、プログラミングを繰り返して行くという意味では、アジャイルの考え方と似ています。アジャイルでは、プロダクトレベルで「動くソフトウェアを短い時間間隔でリリース」することをポリシーとしていますが、それをコードレベルに落とし込むとTDDでありBDDになります。

アジャイル宣言の背後にある原則

常にテストによって動きが保証されたコードこそ、TDDの真髄なのです。

さいごに

読んでみて分かった事は、テスト駆動開発(TDD)は、非常にシンプルであると言うことです。高度な開発手法だと思っていた時期もあったのですが、全くもってそんなことはありませんでした。

  • シンプルに始める。
  • 自動テストを書く。
  • リファクタリングで設計判断を1つずつ行う。

引用:テスト駆動開発

巻末の付録Cに「テスト駆動開発は個人スキルである」という和田さんのコメントがありましたが、まさにその通りであると感じました。TDDの考え方はとてもシンプルなので、誰にでも理解することが出来ます。

ここで言う個人スキルとは、「どのようなテストを書くのかという設計力」であったり「どのようなリファクタリングを行なうか」であったりします。

TDDはシンプルであるが故に、プログラミング能力が要求されます。逆に言ってしまえば、TDDは設計判断やリファクタリング判断など、常に考えるという局面を要求されるのです。

つまり、TDDでプログラミングをすれば「かなりエンジニアとしても成長できるのではないだろうか?」というのが、私の見解です。

本書は、私にとっては刺激的な本でした。本書を読む事によって、その奥底にあるテスト駆動開発の本質に触れる事ができます。

テスト駆動開発は、単に品質を高めるためだけの手法ではありません。それが理解できただけでも、本書を読んだ価値が十分にありました。

この感動はぜひ本書を読んで味わってみて欲しいです。

テスト駆動開発

テスト駆動開発