GitHubに、Appveyor CI +コードカバレッジを備えたオープンソースC#.NETプロジェクトがあります。
ReleaseやDebugのような設定があります。 x86、x64、およびAny CPのようなプラットフォームもあります。
これは次の結果になります:
Configuration | Platform | Tests
--------------+----------+--------
Release | x86 | 100/100
Release | x64 | 100/100
Release | Any CPU | 100/100
Debug | x86 | 100/100
Debug | x64 | 100/100
Debug | Any CPU | 100/100
単体テストは、アプリケーションが開発段階にあるときに、これら2つの次元のすべての組み合わせ(6つ)で常に実行する必要がありますか?すなわち。主に開発者だけがその過程にあり、多くの変更が行われています。
私の直感では、Debug構成と1つのプラットフォームのみをテストする必要があるとしています。
私の見解では、Debug構成はより多くの情報を提供し、C#は非常に高水準の言語であり、VM(CLR)で実行されているため、テストする必要はありません-x64とx86は別々に。
.NETフレームワークバージョンには、3番目の次元もあります。そして4番目はOSです。
アプリケーションの開発時に必要なものと不要なものについて、ベストプラクティスビューはありますか?
もちろん、出荷時にはすべてのテストが実行されます。可能なナイトリー/ウィークリー/ etcビルドと同じです。
これは、「現場での一般的な見方」とは何の関係もありません。これが最も意味のあることです。
1つの構成と1つのプラットフォームのみを使用して単体テスト(または任意の種類の自動テスト)を実行しても問題はありません。もちろんパフォーマンスのために)。
理想的な世界では、テストの実行に必要な構成は1つだけです。ただし、特定の種類のコード構造またはステートメントは、「デバッグ」と「リリース」で、または「x86」と「x64」で異なる動作をする傾向があります。明らかなものがあります
分解テストのように#if DEBUG
、次のような明白なものではありません
浮動小数点精度の微妙な違い。
あなたのケースに何が当てはまるかを見つけるために、利害関係のあるコードベースの経験を得る私見が唯一の賢明な方法です。これは、検査によって、または別の構成を使用してテストを実行することによって行われる場合があります。また、コードベースのサイズによっては、多少時間がかかります。大規模なコードベースでは、1つの構成でテストするだけでは不十分な部分やコンポーネントがあり、他の部分(できればより大きな部分)ではテストに必要な構成以上のものはないことがわかるでしょう。
単体テストにどの構成を好むべきかを尋ねると、私見は明白です
チームがコードコンパイルテストデバッグサイクルで使用する構成/プラットフォームは、ユニットテストを常に実行するためのものである必要があります。
チームが展開に使用する構成/プラットフォームは、特に動作が異なると思われる場合は、展開前にテストする必要があります。
また、チーム内のすべての人が潜在的な違いを認識していること、および#if DEBUG
ステートメントは、テストに関連する可能性のある動作を変更しないように非常に慎重になっています。
単体テストは、正しいアルゴリズムが使用されていること、および修正されたバグの回帰がないことを確認するためのものです。最初は通常デバッグモードでテスト可能である必要がありますが、2番目はそうでない可能性があります-特定のビルドでのみ発生するエラー(たとえば、最適化されたリリース、または異なるレベルの最適化)がある場合、明らかにその中で再テストする必要がありますビルド。
リリースについては、少なくとも2つの点で異なる可能性があり、テストすることをお勧めします。
コードがそれを使用している場合、条件付きコンパイルシンボルが変更されることがあります。
特にビルドシステムのどこかにバグがある場合、最適化によって動作が変わる可能性があります。
少なくとも、選択したビルド構成をテストして出荷する必要があります。それがCPUの場合|リリースし、それを最小限にテストします。
(ターゲット環境にはさらに複雑さもあります。ANYCPUは、32ビットマシンと64ビットマシンで異なる動作をする可能性があります。)