CIでは、srcまたはdistに対してテストを実行する必要がありますか？
2つの異なる時間のいずれかでCI環境でJavaScriptユニットテストをいつ実行するかについて、同僚との間で論争がありました。 2つのパーティをPE（初期）とPL（後期）と呼びます。
初期（srcに対して）
バージョン管理システムから直接、ソースコードに対してテストを実行します。
PEは、最もリスクの高いコードを最初に実行して、「すぐに失敗する」ようにするべきだと述べています。サイクルタイムがはるかに速いため、開発中にユニットテストをこのように実行する必要があることに両当事者は同意します。 PEによると、いずれの場合もビルドを早期に実行するように構成する必要があるため、テストを遅く実行する別の構成では複製と膨張が発生します。
遅い（距離に対して）
コードに対して同じテストを実行することがパッケージ化（連結および縮小）されました。
PLは、出荷時にコードをテストする必要があると言っています。 PLは、ソースから直接実行したときにコードが機能するが、コードが配布用にパッケージ化されたときに問題が発生したために失敗した、時間のかかるシナリオを経験したと主張しています。
PEは、「何かがうまくいかない可能性がある」という仮説は弱い議論であると述べています。とにかく、そのような問題を捉えることはCIの仕事ではありません。配布可能なコードは、出荷前にQAによってテストされます。
さらなる詳細
「早期および CIの後半」はオプションではなく、PELのがっかりさせるものです。
コードはAMDとRequireJSを使用してモジュール化されています。単体テストにはKarmaを使用し、ビルドスクリプトにはGruntを使用しています。
それでそれはどちらですか-早いですか遅いですか？
片側は間違いなく正しいですか？ある人を反対側に揺さぶるような配慮が欠けていますか？
一般的なテストの観点から：
「早期テスト」はワークフローの最適化です。すばやく失敗することで、より速く反復することができます。単体テストのように、ソースコードに近いテストはここで役立ちます。
「遅いテスト」は品質保証の要件です。あなたが言ったように、ソースコードが検証された後でも問題が発生する可能性のある場所が複数あるため、コードは出荷時に正確にテストする必要があります。ここでは、複数のコンポーネントを統合する高レベルのテストが役立ちます。
低レベルと高レベルの両方のテストを行う必要があります。 「アーリーアンドレイト」が選択肢にならない理由はわかりませんが、それがまさに私がお勧めすることです。
一般的なケースとして、コードのすべての変更をテストする必要があります。これらのテストをどのように実行し、どのようなテストを実行するかは、自分がいる状況や環境によって異なります。
早い段階と遅い段階の両方をテストすることをお勧めします。これは最終的にそうなると言いますが、それまではどちらかを選択する必要があります。
状況が成熟して両方が可能になるまで、最善の妥協案を探しているように聞こえます。 最も高いリスクの変化をテストし、コードの修正を最速にするものを選びます-その音で、これは今のところ早い段階のテストです。このすべての後にQAを実行すると、問題を発見する最後の機会が与えられます。
すでに述べたように、ユニットテストを使用した初期のテストでは論理エラーを特定し、統合に進む前にそれらを修正するのに役立ちます。統合に入ると、テストは遅れて統合と互換性の問題を特定します。また、最終的なシステムテストとユーザー受け入れテストも提供します。
CIを使用している場合、それは高度に自動化された環境である可能性が高いため、それを使用して、できるだけ多くのテストを自動化します。これにより、回帰の問題が発生していないことをより高いレベルで確認できます。あなたが両方を実行できない理由の原因を特定できてうれしいです。発券システムは、品質の高いコードの迅速な配信をサポートする必要があります。
通常、ユニットテストは早期に実行します。これは開発したテストであり、開発したビットが単独で期待どおりに機能します。その後、開発したビットが他のビットで期待どおりに機能するかどうかをテストするため、後で広範囲の統合テストを実行します。
ユニットテストを早い段階と遅い時期の両方で実行する必要はありません。すでに早い段階で実行している場合は、後で実行するのは冗長ですが、統合テストを（明らかに）早く実行することはできません。 CIはこれらを実行する場所です。
回答ありがとうございます。 CIで「すぐに失敗する」ことが重要だと人々が考える程度に驚いています。開発（個人）サイクルと統合（チーム）サイクルには違いがあります。
開発
開発者が小さな変更を行います。テストを実行して、変更によって何も破壊されなかったことを確認します。何かが壊れた場合、開発者はコードを検査し、エラーに気づき、修正して、テストを再度実行します。テストがほぼ瞬時に実行できる場合、そのサイクルは文字通り1分間に数回発生する可能性があります。テストの実行に数分かかると、サイクルタイムが途切れ、開発者のワークフローが中断されます。
統合
開発者が変更をマージします。ビルドが実行され、何かが失敗します。チーム全体に障害が通知されます。チームは、誰が問題に取り組むかを理解するために連絡します。数人の開発者が頭をまとめ、最新のコードをプルダウンし、ローカルでビルドを実行し、何が問題だったかを理解し、変更を加え、コードを慎重なコミットメッセージでコミットし、コードをサーバーにプッシュして、マージします。他の時間のかかるステップがあるかもしれません。それは一般的に最低限のことです。
この場合、障害が発見されるまでに数分以上かかる場合（「初期」と「後期」の違い）は、全体のサイクルタイムに大きな影響はありません。
CI中に最終製品に対してテストを実行しないことを選択し、連結/縮小プロセスに関する何かによりバグが発生する場合、そのバグが最終的に発見されるまでに数時間、数日、または数カ月かかる場合があります。
CIで「早期」にテストを実行することは「ありがたい」です。全体的なサイクルタイムへの影響はわずかです。 「遅い」テストを実行することは「必須」です。そうしないと、壊滅的な状況になる可能性があります。