各単体テストは、他のテストとは独立して実行できる必要がありますか？
クラスの2つのメソッドのテストがあるとします。最初の方法は、別の層からデータを収集し、ランタイムに依存しないある種のストレージ（SQLテーブルなど）に配置するため、このテストで処理されるすべてのデータがテストにハードコーディングされます。 2番目の方法は、最初の方法がデータを残した場所からデータを取得し、何らかの方法（計算、特定の部分を別の場所に移動するなど）で変換する責任があります。
この2番目の方法では、最初の方法と同様にハードコードされた入力を使用できます。または、2つのテストが順番に実行され、最初のテストが終了したところをピックアップして、最初のテストで実際に保存されたデータを取得することもできます。
2番目のオプションを使用した場合、2つの方法がうまく機能することは非常に良いことですが、最初のテストが失敗すると、その後のすべてのテストが失敗し、バグをより迅速に特定するのに役立つテストの利点が失われます。
最初のオプションを選択した場合、各メソッドは個別に分離およびテストされますが、それらが実際に適切に連携できることを実際に知ることはできません。
ここでより良いオプションはどれですか？ハードコーディングされた分離されたメソッドごとに単一のテストを行い、次に両方のメソッドを1つに含むより大きなテストのような代替策はありますか？
最初のオプションを選択した場合、各メソッドは個別に分離およびテストされますが、それらが実際に適切に連携できることを実際に知ることはありません。
メソッドが完全に独立している場合、これは問題になりません。あなたの2番目の方法は：
a）有効なデータが提示されると、正しく動作します。
b）無効なデータが提示された場合、慎重かつ一貫して失敗する。
同様に、最初のメソッドも同じようにする必要があります。したがって、エラーケースを処理する限り、それらは適切に連携します。
メソッドが一緒に正しく機能することをテストする場合は、単体テストではなく統合テストです。
テストを個別に実行できない場合は、単体テストではありません。
単体テストは、データベーステーブルの内容などの外部状態に依存してはなりません。純粋に1つのコードユニットを分離してテストする必要があります。
特定の状態を変更または要求するテストは有効です。たとえば、統合テストの一部を形成する可能性があります。そのような場合、適切な設定が行われていることを確認することが重要ですが、これらは単体テストではありません。この場合でも、1つのテストを実行するために別のテストが必要であることはお勧めしません。この場合は、おそらく必要なコードを別のセットアップメソッドに除外する必要があります。たとえば、セットアップコードを呼び出して例外がスローされないことを確認する1つのテストと、セットアップメソッドで設定されたデータをアクティブに使用する別のテストがあるとします。
単体テストBによって残された状態に依存する単体テストBを今すぐに問題ないように思います。しかし、1000の単体テストがある1年後を考えてみてください。変更する必要があるたびに、テストスイート全体が完了するまで10分間待機しますか？
もちろん、それは開発スタイルに依存しますが、機能を開発するときに個別のテストを何度も実行する可能性のある適切なテスト駆動型開発の希望が必要な場合は、各テストに独立した機能を与えることをお勧めします。
いくつかの方法で実行できるテストのセットアップについて話しているように聞こえます。各テストのテストデータ（フィクスチャと呼ばれる）のクリーンなコピーが必要なため、各テストが互いに依存しないようにする必要があります。
このタイプのテストを可能にするいくつかのフレームワークと、テストおよびテストスイートの開始と終了でデータ構造をすばやく構築および破棄できるDBUnitなどのツールがあります。