私は現在 Git で管理している大規模な (っぽい) プロジェクト [90 ファイル 650 KB コード] を持っています。私はいくつかの独立したテスト ハーネスを使用して、後でメイン コードとそのブランチにマージされる新しい低レベルの計算を試行/テストします (現在はコピー アンド ペーストを使用しています!)。
テスト ハーネスを管理するための推奨されるベスト プラクティスは何ですか?
それらは別のリポジトリにある必要がありますか、それともメイン リポジトリに空のブランチを作成して開始する必要がありますか、それとも単に「テスト ハーネス」ブランチを作成して古いコードを上書きする必要がありますか?
利益が期待されるのは、メイン ブランチでテストされたコードが、テストされたものと明らかに「同じ」であることです。
私は Windows (msysgit) を使用しており、会社で Git を使用するための主要な「エクスプローラー」です。
私がほとんどのプロジェクトで見た通常の構造は、test/ディレクトリ階層を と並行して含み、src/それらをそこに (同じリポジトリに) 格納することです。
90個のファイルと650KBのソースコードは間違いなく大きくありません。テストハーネス/テストスイートなどをソースコードと一緒に同じリポジトリに保持することをお勧めします。githubのいくつかのリポジトリ（例：PLY）を確認し、ソースコードとテストスイートをどのように編成するかを決定します。
ファイルの数とサイズは、すべてを 1 つのリポジトリとして保持する git の能力の範囲内です。たとえそれらを1桁か2桁上げたとしても。したがって、それらを 2 つのリポジトリに分割する、または単一のリポジトリに保持する本当の理由は、git の技術的な制限ではなく、使いやすさに関係しています。
テストするコードと同じレポにテストを保持するのが好きです。新しい機能を含めるためにコードを更新するときは、単体テストを更新します。2 つが同期していると便利です。
コードを追加して欠陥を修正し、回帰テストを追加すると、2 つを同期させることができます。
古いリビジョンをチェックアウトすると、単体テストと回帰テストがコードと同期しているため、バンドルされているテストはすべて合格するはずです。システム内の他のコンポーネント (OS やツールの変更など) に起因すると考えられる障害はすべて、どのテストが「予想される障害」であるかを推測することから干渉されることなく、そのようなことを特定するのに役立ちます。
欠点は、単体テストに何かが欠けていることに気付いた場合、それを「あるべき」場所にさかのぼって追加するのは簡単ではないことです。ただし、昨年 4 月のコードが新しいサブシステムなどで動作するかどうかを確認するときに、多くの「大丈夫かもしれない」という失敗が発生することよりも、小さな欠点があることがわかりました。
ただし、トレードオフは異なる場合があります。おそらく、管理チェーンは、新しい機能が追加されたときに追加される広範な単体テストに対して十分なサポートを提供していないため、さかのぼって適用したいテストの割合が高くなる可能性があります。読み取り可能な属性を介して機能の変更をエクスポートするのが得意で、テスト セットが予想されるエラーを実行できない場合があります。テストは、コードとは別のグループによって管理されている可能性があります。それらのいずれかがバランスを変える可能性があります。