出荷テストコード。なんでだろう？
テストコードを製品と一緒に発送したいのですが。具体的には、私たちのプログラムのコピーを持つ誰もが「セルフテスト」ボタンを押すか、コマンドラインで--self-testをパスして、ユニットのスイート全体を実行できるようにオプションを提供します。統合テスト。
私は主に、フィールドで発見された問題をデバッグするためにこれを実行したいので、バグレポートがエンドユーザーから届くと、「また、これらの3つのテストは私のマシンで失敗しました」とサポートされる可能性があります。手動テスターでユニットを実行できるようにしたい|統合テストも同様です。
ただし、チームのテストでは、テストコードは製品コードではないため、出荷されません。ほとんどのオープンソースプロジェクトはテストスイートを出荷しているので、私はこの議論を実際には受けません。クローズドソフトウェアでは珍しいようです。
どちらかの論拠について、証拠や逸話を裏付けたいと思います。私はどのスタック交換サイトが最も適切であると思いますが、これが適切でない場合はお知らせください。
テストコードには、会社の外部と内部の両方のサードパーティからのコードのスニペットが含まれる場合があります。これは、ユーザーがバグを提出するときに発生します。次に、テスト（回帰テストなど）が提供するコードを組み込んで再現します。多くの場合、バグを再現するためのそのようなコードスニペットのライセンスは不明確です。したがって、知的財産の問題に注意する必要があります。会社の別の部署または外部パートナーの企業秘密や知的財産を誤って明らかにするテストコードを出荷したくありません。
別の注記として、テストコードが製品コード標準に準拠することはめったにありません。コードレビューが必ずしも行われるとは限りません。コーディング標準が適用されていないなど。これは残念ながらまだ一般的であり、これらのテストが開発された時点で目標が設定されていなかった場合でも、テストチームに反映されているとは限りません。
一方、多くのテストは単に恥ずかしいほど悪いものであり、テストされていると思うものをテストすることすらありません。それは別の問題です...
最終的には、これらすべての要因により、テストを出荷可能なものとして分類することができます。 オープンソースとして、そして単にできないもの。 （それらを出荷することを念頭に置いて、いくつかのカスタムテストを作成し、他のテストをゆっくりとそのセットに移行することができます。）
出荷テスト？はい。出荷単位テスト？番号。
あなたがコメントで言うように、クライアントコンピュータで製品を実行するときに直面する可能性のある問題には、間違ったdllとのリンクなどの問題が含まれますが、これは通常、ユニットテストがキャッチするものではありません（これは間違いなくdllをモックアウトしているでしょう）コードをテストします）。
これで、dllを呼び出すロジックを呼び出すUIを呼び出す統合テストスイートが出荷されました。統合テストでは、単体テストでは表示されない、失敗したインストールの他の側面を表示できます。 （たとえば、私の現在の製品には、ライセンスのためにバンドルすることが許可されていないk-liteコーデックのインストールが必要です。ユニットテストでは、コードが正常に機能しているにもかかわらず、顧客満足度に機能しない場合があります。同様に、コーデックの構成正常に動作しなかった可能性があります。単体テストでも表示されません）。
そのため、代わりに統合テストの一部を出荷します。これは、インストールされ、統合された製品にまさに必要なものです。
マルチスレッドの次世代AAAゲームエンジンなど、すべての単一のCPUコア、SIMD組み込み関数、GPU、GPGPUなどを使用してクロスプラットフォームを提供するなど、ハードウェアのあらゆる側面をカバーしている領域でこの懸念を強く理解できました。製品。
これらの場合、最悪の悪夢は、テスト（ユニットと統合）がテストされた最初の5,000の異なるマシン/プラットフォームに合格するが、GPUモデルが不明瞭なためのドライバーのバグが原因で5,001回失敗するケースです。これについて私は震えを与えます-あなたはおそらくこれらを事前にテストしたり予見することはできません。
特にGPUシェーダーを作成する場合、作成したコードの半分が未定義の動作を呼び出すという逆の宝くじをプレイする可能性があります。関係するすべてのGPUモデル/ドライバーによって適用されるポータブルな標準保証がほとんどないためです。最近マインスイーパをプレイするようになっていますが、これは人々にいくつかのアイデアを与えるでしょう： http://theorangeduck.com/page/writing-portable-opengl 。 90年代後半から2000年代前半にこれを試すのは本当にひどいもので、ずっと掃海艇でした。
これらの種類のケースでは、製品を本当に確実にして自信を持たせるために、本当に幅広い範囲のハードウェアとオペレーティングシステムを持つ10,000人以上のテスターのチームが必要になることがよくあります。安定版リリース前のそれについて。すべての企業がそのような幅広いテストベースを利用できるわけではなく、すべてが正しく実行するための規律を持っているわけではありません（広く知られている問題はすべて修正する必要があります前に内部のプレアルファ/アルファ段階で非常に多くのテスターがいる場合、または冗長なレポートの洪水が発生すると、開発者をパッチアンドパニックパニックに陥らせる可能性があります）。
この場合に私が推奨するのは、他の人が提案したものであり、統合された一連の統合テストに焦点を当てています。これをインストーラーにバンドルして、ユーザーが開発者に渡すことができるインストールが失敗した理由の詳細を提供することに注意して、基本的な診断チェックに合格することをユーザーに要求できます。
もう1つ（上司を納得させることができる場合）は、隣接する統合を実行するために利用できる幅広いハードウェアを用意することです。ハードウェア/ OSコンボの種類が多いほど、メリットがあります。 CIサーバーの最小限のハードウェア要件をモデル化したさまざまながらくたハードウェアも必要です。
しかし、もう1つ提案したいことがあります。
ロギング
私が上記で説明したシナリオのようなものを扱っている場合、最も問題が多い傾向にあるこれらのものをテストできないことがよくあります（可能な限り最悪のタイミングで表示され、さらにはこれは非常に特定のハードウェア/ OSコンボに制限されている問題であるため、最も包括的なテストスイートです。
しかし、あいまいなハードウェアの非互換性、完全なドライバーの不具合、間違ったdylibへのリンク（実際にはこの問題に直面したことがない）など、これらの種類の問題のほとんどは、ソフトウェアの起動をはるかに超えてしまうことはありません。大雑把に言えば、それは通常、すぐにクラッシュして燃えるでしょう。
正直なところ、避けられないものを受け入れることをお勧めします。これらを包括的にテストすることはできません。ハリケーン（不可能）を防ごうとしないでください。しかし、それらの窓に乗り込みます。
通常、ここで私たちができる最善のことは、できるだけ早く問題を見つけ、できるだけ詳細に発生して（容疑者のリストを絞り込むため）、問題が報告された後にできるだけ早く修正することです。
この場合、ロギングは命の恩人になることができます。これらの種類のフィールドでは、誰も読まないこれらのスパム性のある技術ログを作成できます。多くの場合、関連するのは、ユーザーがドライバーの不具合のためにクラッシュに直面する前にログに記録された最後の行だけです。クラッシュを監視し、ユーザーがコピーして貼り付けることができるログの最後の行を表示する外部プロセスまたはフックを作成できます。クラッシュダンプに加えて。
これは詳細な情報を必要とすることが多く、これらのハードウェア/プラットフォーム/ドライバーの問題に対するコードの最も影響を受けやすい領域の多くはパフォーマンスが重要であるため、ロギングが頻繁に発生し、実際には遅くなるという厄介な問題があります。ソフトウェアをダウン。
この場合の便利なトリックは、1回実行されたものが2回目、3回目などで正常に実行されるという仮定に依存することです。これは、最も適切な仮定ではありませんが、多くの場合「十分」であり、何もないよりはるかに優れています） 。これにより、少しの外部状態を使用して、何かがすでにログに記録されたときを追跡し、コードがループで繰り返し呼び出される非常にきめ細かいケースについて、ログへの後続の試行をスキップできます。
とにかく、これが役に立てば幸いです。私は過去にこのような誘惑に遭遇し、私と私のチームの間での過去の経験の結果として、GPUコーディング（GPGPUとシェーダー）を取り巻くパラノイアが少しあります（他のチームメンバーが実際にこれらに対処しているのを見ていることもあります）リリース後期と後期には、アンチエイリアスされたラインのレンダリングでクラッシュする特定のRadeonモデルでのATIの不具合のように、後で報告され、利用可能な回避策の解決策のみで既知の問題としてマークされたようなクリープがありました。
ロギングはそこに私たちのお尻を救ったものであり、聞いたことのないGPUを搭載したその10,001番目のあいまいなプロトタイプマシンの問題を頻繁に見ることができ、コードの最後の行ですぐに障害が2になっている場所を正確に見つけることができましたまたは疑わしいとして3行のコード、例えば精巧なシェーダー内にある場合、GPUシェーダー内でログを記録することはできないため、SOLのようになりますが、少なくともログを使用してwhichシェーダーは、調査を開始するためにすぐに問題を抱えていました。