ソースコードにとってみると、もっともきめ細かくテストされるのはユニットテストになります。ユニットテストでは、ホワイトボックス・テスト（ソースコードの記述に応じてテスト項目・入出力データセットを決める）を行うので、コードの条件分岐をなめるようにテストを実行することになります。
しかし、このユニットテストはテストケースの作成と保守がJUnit等のフレームワークを使ってもかなり大変な労力となります。実はアジャイルな開発ほどリファクタリング・機能追加／変更が頻繁に発生し、まじめにユニットテストを記述していればいるほど修正が大変になります。
アジャイル、テストファーストな分野でこのことってあまり議論にあがっていないように見えるのが不思議です。多分、ユニットテストについてはブラックボックス・テストを行うだけで良しとしてしまっているか、実はユニットテストをしていないのではないかと想像します。
そこで、ユニットテストはソースコードが十分枯れてきた終盤で実施するとどうでしょうか？
ユニットテストをしてから結合テストをするという流れを逆転させてみます。
結合テストを先にすることで、ユニット（クラス）同士の協調を先に作りこんでテストします。結合の過程でリファクタリングしたり、機能追加／変更に対応してクラスが変遷していきます。この間はプログラムが動くことを作業的にも試験的にも優先します。次第に機能やシーケンスが確定し、枯れてきたころに個々のユニット(クラス)についてユニットテストを記述してテストをします。
枯れてきていればそれほど変更はないので、ホワイトボックス・テストを十分記述していても手直しのコストはある程度極小化されることでしょう。
さらに、ユニットテストの記述はクラス作成者でなくても可能です。ホワイトボックス・テストならば、メソッドの仕様とソースコードの条件分岐を把握すればテストが記述できます。理想はペアプログラミングでテストを記述することですが、テスト部隊を作って別チームでユニットテストをすることもできます。結合テストでソフトウェアが動いているので、最悪でも解析して理解することは（効率はさておき）可能です。
高品質なソフトウェアを開発することが重要なプロジェクトであれば、開発者とは別チームを編成してこのユニットテストを実施するほうがよいかもしれません。従来ならシステムテスト等のV字モデルで言えば右肩に近いレベルをQAチームで実施していたのですが、V字の底辺にあたるユニットテストをQAチームで実施するということもありではないかと考えます。QAチームがユニットテストを記述できない（コードが理解できない）ということがあれば、それは保守性に対するコードの欠陥なので、それも指摘できます。
