単体テストはリポジトリに保存する必要がありますか？

私は成長中のプログラマーで、GitHubに保存しているライブラリの単体テストを最終的に実践しています。

レポジトリにテストスイートを含めることができたのですが、他のプロジェクトを見てみると、テストを含めるのは失敗したように思えます。

これは悪い形と見なされますか？ユーザーは作業コードにのみ興味があり、とにかく自分のフレームワークでテストするという考えはありますか？

必ずテストをリポジトリに配置する必要があります。私の意見では、テストはコードの一部であり、他の人がそれを理解するのに非常に役立ちます（うまく書かれていれば）また、コードベースを変更したり、コードベースに貢献したりするときに他の人を助けることができます。良いテストは、あなたの変更が不注意で何かを壊さないという自信を与えます。

ただし、テストコードは製品コードから十分に分離する必要があります。たとえば、Mavenは、生産コードとテストコードを異なるフォルダーに配置することでこれを実現します。「このファイルは本番またはテストコードの一部ですか」という質問は決して発生しないはずです。

私は個人的に、自分のコードで使用済みライブラリの単体テストを書いていません。それらが動作することを期待しています（少なくともリリースバージョンを使用する場合は、バグが明らかに表示される可能性があります）。統合テストである程度のテスト範囲を取得できますが、それだけでは不十分です。

チェックインしたソースコードに単体テストを含めない場合、次のようになります。

• そのコードの独自のコピーをダウンロードしてビルドする人は、それが意図したとおりに機能していることをどのように検証しますか？コンパイラーとライブラリーのバグはまれであり、データエラー（特にソースコードをコンパイルできないようにしないもの）はさらにまれですが、特にビルド環境を指示できない程度の場合、間違いが発生する可能性があります雇用主は、使用するツールを指定できます。
• ソースコードのローカルコピーに何かが発生した場合、どのようにしてテストを元に戻しますか？
• 新しい開発者は、自分の変更が既存のコードベースの何も壊さないことをどのように検証しますか？

ボトムラインは、私は考えるでしょうではない非常に悪いことでリポジトリ公式ソースコードで記述された任意のユニットテストを含みます。

もちろん、いくつかの理由から、ユニットテストをリポジトリに配置する必要があります。

• 以前のバージョンに簡単に戻すことができます
• プロジェクトに取り組んでいる他の人々もユニットテストにアクセスできます
• 一部の人々は、ユニットテストをドキュメントの一部と考えています（TDDおよびBDD）

別のコンピューターで実行する機会がある場合は、必ず含めてください。これらは個別にビルドする必要があるため、ユーザーは追加する必要がなく、余分な依存関係がある可能性がありますが、必ず含める必要があります。

リポジトリにテストを含まないほとんどのプロジェクトには、単に何もないと強く思うでしょう。

テストを個別のモジュールとして使用する理由があるので、古いコードに対して新しいテストを簡単に実行できます。APIで安定したライブラリやコマンドラインを介したブラックボックステストに役立ちます。新しいテストがおそらく古いコードでコンパイルされないようなコンパイルされた言語の有用性は限られています。

絶対に。ここでの追加のボーナスポイントは、ソースファイルのバージョンXがテストのバージョンYに対応することを追跡する機能にあります。つまり、以前のバージョンに戻って、そのバージョン用に設計された適切なテストを取得できるようにする必要があります（APIの変更などの場合）。

「Brownfield Application Development in .Net」を読み終えたところです。これにより、ソース管理や単体テストを含む場所/方法/理由（特に継続的インテグレーションの分野）など、アプリケーションの構造に関する優れたアドバイスが得られます。 。.Net開発者の方は、お勧めします。