私は現在、これから行うプログラムの設計を推進するのに役立ついくつかの受け入れテストを行っています。Acceptance-Tests が少し複雑であることに気付いたことを除けば、すべて問題ないように思えます。つまり、概念的には単純ですが、実行するにはかなりトリッキーなコードが必要です。受け入れテスト用にいくつかの「ヘルパー」クラスを作成する必要があります。
私の質問は、それらを開発する方法です。
ある友人は、受け入れテストはコードが壊れているかどうかを示し、単体テストはどこが壊れているかを示すという考えに非常に熱心です。これらは補完的で価値のある情報です。受け入れテストは、完了したことを知らせるのに適しています。
しかし、やり遂げるには、途中ですべてのピースが必要です。それらが機能する必要があり、それが単体テストの優れた点です。テストを最初に行うことで、(機能するコードだけでなく) より優れた設計にもつながります。良いアプローチは、全体像の受け入れテストを作成し、「これが合格したら、完了です」と自分に言い聞かせることです。次に、TDD を使用して合格するように作業します。AT に合格するために必要な次の小さな機能の小さな単体テストを記述します。合格するコードを書きます。リファクタリング; 繰り返す。進行するにつれて、時々 AT を実行します。テストの後半で失敗する可能性があります。そして、前述のように、それが通過したら完了です。
受け入れテスト自体の単体テストはあまり意味がないと思います。しかし、そのヘルパー クラスを単体テストする (実際、テスト ファーストで記述する) ことは、非常に良い方法です。「テストのためだけに」作成したいくつかのメソッドが実稼働コードに組み込まれている可能性があります。そうでない場合でも、AT が使用するコードが正しく機能していることを知りたいと思うでしょう。
AT が十分に単純であれば、「テストはコードをテストし、コードはテストをテストする」という古い格言でおそらく十分です。そして、どれを理解するのは簡単なはずです。ただし、テストが複雑な場合は、その基盤も十分にテストすることをお勧めします。
単体テストフレームワーク（JUnitなど）を使用して受け入れテスト（または統合テスト）を作成することに問題はありません。人々は多くの理由でそれらを「ユニットテスト」と呼ぶのが好きではありません。私にとっての主な理由は、変更をチェックインするたびに統合/受け入れテストが実行されないことです（長すぎるか、適切な環境がない）。
ヘルパークラスは、「テストインフラストラクチャコード」を構成するかなり標準的なものです。それらは他のどこにも属していませんが、テストコードです。それらをテストするかどうかはあなたの選択です。しかし、それらがなければ、大規模なシステムでのテストは実行できません。
したがって、選択は＃2であるか、テストのテストをまったく行わないことです。インフラストラクチャコードをリファクタリングして、より透過的でシンプルにすることに何の問題もありません。
ソフトウェア開発を車の生産工場にたとえると、ソフトウェアを書くという行為は新しい車を開発するようなものです。各コンポーネントは新しいため、個別にテストされています。これまでに行われたことはありません。（持っている場合は、以前にそれを行ったことがある人を入手するか、棚から購入することができます. ）
ソフトウェアをビルドし、それをテストするビルド システムは、コンベヤー ベルトのようなものです。自動車メーカーは通常、新しいコンポーネントの生産を自動化し、新しいコンポーネントを作成する一環として自動車をテストする方法を検討します。また、それらの自動車を製造する機械もテストすることは間違いありません。
ですから、はい、受け入れテストの単体テストは、特に、より速く進み、物事を簡単に変更できるようにするのに役立つ場合は、まったく問題ないように思えます。
あなたのオプション 2 は私が行う方法です: ヘルパー クラスをテスト ファーストで記述します。
テストはテストであり、ヘルパー クラスは厳密にはテストではありませんが、メイン コードでは参照されず、テストのみで参照されるため、テストに属します。おそらく、それらは通常のテストとは別のパッケージ/名前空間にある可能性があります。