コードテストコード（「unittest」クラスを使用）を含むファイルがいくつかあります。
後で、データベースの整合性もテストするとよいと思いました。これを別のディレクトリツリーに配置します。（キーの形式が正しい、親ノードと子ノードが正しく指しているなど。編集：これはnosqlプロジェクトであり、データベースレベルのチェックに依存することはできません。参照整合性などがあります。）
整合性テストに同じunittestクラスを使用します。
さて、これを別にしておくのは本当に理にかなっているのだろうか。データの整合性をテストするために、データを処理するコードをテストするために使用するコードの一部を複製することがよくあります。
しかし、それは同じではありません。コードテストはテストデータベース（各テストの後に削除されます）を使用し、整合性テストはライブデータに接続して分析します。cronから呼び出して、ライブデータベースで何かが発生した場合にアラームを送信したい整合性テスト。
それをどのように処理しますか？そのような設定の基準はありますか？あなたの経験は何ですか？
私の傾向は、すべてを同じファイルに入れることです。その結果、コードテストも実稼働環境のcronによって実行されます。
編集：私を駆り立てるのは、プロジェクトをシンプルに保ち、1つのタスクまたはワークフローであまり多くのファイルに触れないようにすることです。すべてのテストを行わなくても、クラスファイル、サブクラス、関連クラス、いくつかのライブラリ（ヘルパー）ファイル、およびメインコードがすでにあります。テストでは1つのファイルが追加されます。これにより、コーディング中に注意を集中でき、ストレスが少なくなり、エラーが少なくなり、影響を受けるファイルが少ない特定のコード部分をすばやく覚えて見つけることができます。ここでは、ワークフローごとに1つのテストファイルのみが役立ちます。私がそれを別々に保つならば、2つのファイル（データ整合性テストとコードテスト）と多分3つ（両方のための共通のライブラリ）があります。抽象化は複雑さを増します。
Edit2：少しリファクタリングして、データテストファイルをコードテストも存在する同じディレクトリツリーに移動するだけですが、「整合性」または「テスト」を示す名前の異なるファイルを保持しています。2人が反対を勧めたので、私は（まだ）ファイルをマージしません、そして私は今のところ彼らの経験とアドバイスを信じています。今のところ、コードの重複を抱えています。
Edit3：この場合、実行ごとのテストの選択はツリー構造によって決定されないことを忘れました。テストはマスターファイルに列挙されているので、現在、「整合性」と「コードテスト」の2つのマスターファイルがあり、テストは同じディレクトリ構造で実行できます。
たぶんもっと多くの人が答えるでしょう。これまでのところ、最終的な構造の開発にすでに役立っている貴重な情報をありがとうございました。
Edit4：今はもっとリファクタリングをしました。2つのファイルを保持する必要があるようですが、目的が少し変更されています。1つは、実動サーバーでのスケジュールされたモニターを対象としています。そしてもう1つは開発用です。ただし、両方のファイルに整合性テストまたはコードテストを含めることができます。また、どちらのファイルでも、テストデータベース（テスト後に消去される）と永続データベース（それぞれに永続データベース、本番サーバー、開発サーバーがあります）で操作を実行できます。そして重要なことの1つは、多くの一般的なコードをテストファイルからクラスファイルに移動していることに気付くということです。したがって、クラスはテスト専用の能力も取得します。私はこれまでのところこれが好きで、きれいに感じます。私は（まだ）2つのテストフロントエンド間で共有されるテスト用のライブラリを作成していません。このコードは、今のところテストされているオブジェクトのクラスファイルに移動しました。
以下の私のコメントは「user89021」で署名されていますが、それは私、karlthorwaldであることに注意してください。私はそれについて何もできません。