

テスト駆動開発(Test Driven Development, 以下
TDD)において、作成したテストコードの妥当性を検証するテストコードを更に用意する必要があるのではないでしょうか？
私はその様に認識しているのですが、正しいのでしょうか？  
正しいとして、TDD を実践している方々はやはりテストのテストを書いていたりするのでしょうか？
それとも、テストのテストを書かなくても済ませられる方法があるのでしょうか？ ご回答いただければ幸いです。


CC BY-SA 3.0
2015-03-05T11:50:34.277
7491
2015-03-06T01:26:23.387
2015-03-05T12:31:27.063
5855
question
テスト
テスト駆動開発に関する疑問


`TDD`はテストのためのテクニックではなく **開発のためのテクニック** です。  
クラスなどの小さな部品を実装する際に、そのAPI(publicメソッドなど)を呼び出す簡易的なテストコードをあらかじめ書いておき、そこから実際に対象クラスを実装していきます。

そうすることで、本当に欲しい部品を設計しながら実装することができます。もちろん、簡単なバグを見つけ出すのにも役に立ちますが、テストケースの網羅はしません。

その際に、テストコードは呼び出したメソッドの戻り値がなんであるかを簡単なアサーション(等しいかどうか、大小、nullかどうかなど単純な真偽チェックが多い)を用いてチェックすることが多いです。テスト側でロジックを持たせるわけではないので、テスト側のテストは不要です。

逆にテスト側にロジックを書いている場合、それは何かがうまくいってないでしょう。

* * *

`TDD`の解説はWeb上にも数多くありますが、個人的には [The RSpec Book（David Chelimsky Dave Astels Zach
Dennis 株式会社クイープ 角谷信太郎 豊田祐司） ｜
翔泳社の本](http://www.shoeisha.co.jp/book/detail/9784798121932)
が`TDD`や`BDD`(振舞駆動開発)などにについて書かれていて良いと思いました。


CC BY-SA 3.0
2015-03-05T14:06:37.693
7499
2015-03-05T14:06:37.693
3313
7491
answer


TDDの方法論に従うと、自ずと「テストに対するテスト」が必要な状況にはなりにくくなります。これがTDDの大きなメリットです。テストが必要なほど複雑なテストを書くのではなく、簡潔で誤りの余地がないテストコードを積み重ねていくのがTDDの方法論です。

## テストフレームワークの使用

TDDでは一般に何らかのテストフレームワークを使用します。事前準備と後片付けをテストコードと分離したり、複雑な振る舞いをモックを用いて簡略化したり、専用の文法でテスト条件を記述したりすることができ、これによりテストコードを簡潔に保ち続けることができます。簡潔なコードであればバグが入り込む余地はすくなくなります。

## テスト可能なコード

テストフレームワークでのテストを前提にすると、実装コードもテスト可能になるような実装であることが要求されます。

  * 内部状態への依存を減らす
  * 予測可能な動作
  * 判定可能な出力

など。

## テストファースト

ここまではTDDとは直接関係ないテストそのもののセオリーです。これに加えてTDDの「テストファースト」を守ることによってもたらされるメリットが2つあります。一つは、上記のテスト可能なコードであることが強制されることによってそれを担保することができることです。

もう一つは、テスト条件の事前の明文化です。事前にテスト条件を書いてしまうことで、実装コードに合わせてテスト条件を書いてしまうという誤りを排除することにつながります。また、テストを書いた直後はそのテストが失敗することを確認しなければならないので、テスト対象の誤認や判定条件の誤りといったバグも排除できます。

テストを後から書くと、成功すべくして成功しているのか、成功してはいけないのに成功 **してしまっている** のかが判断できません。

## 小さなステップ

さらにTDDは、Red→Green→Refactoringをできるだけ小さなステップで回すことを求めています。これはテストコードと実装コードを常にクリーンに維持し続けることにつながります。


CC BY-SA 3.0
2015-03-06T01:26:23.387
7510
2015-03-06T01:26:23.387
5793
7491
answer