単体テストのタイムアウトを使用してメソッドのパフォーマンスを測定することをお勧めしますか？
特定のアクションの最大実行時間を指定する非機能要件があるプロジェクトでは、QAは、要件で指定されているハードウェアと負荷の両方の正確な負荷の下で、正確なハードウェアを使用して専用マシンでこのアクションのパフォーマンスを確認する必要があります。 一方、ソースコードに誤った変更を加えると、パフォーマンスに深刻な影響を与える可能性があります。早くこのマイナスの影響に着目、前のソースコードは、ソースコントロールに到達し、QA部門によって検証され、問題の報告QA部門によって失われた時間の点で有益であり、開発者が後でそれをいくつかのコミットを固定できます。 これを行うには、良いアイデアですか？ ユニットテストを使用して、同じアクション²をn回実行するのにかかった時間を把握するには、 C＃の属性を介してテストごとのタイムアウトを使用するには[TestMethod, Timeout(200)]？ このアプローチにはいくつかの問題が予想されます。 概念的には、ユニットテストは実際にはそのためのものではありません。コードのごく一部をテストするだけであり、機能要件のチェック、統合テスト、パフォーマンステストのいずれでもありません。 Visual Studioの単体テストタイムアウトは、初期化とクリーンアップがこれらのテストに存在しないか、結果に影響を与えるには短すぎることを考慮して、実際に測定されると予想されるものを測定しますか？ この方法でパフォーマンスを測定するのはいです。ハードウェア、負荷などに関係なく、任意のマシン¹でベンチマークを実行することは、あるデータベース製品が別のデータベース製品よりも常に高速であることを示すベンチマークを実行するようなものです。一方で、これらの単体テストが決定的な結果になることや、QA部門で使用されるものになることは期待していません。これらの単体テストは、期待されるパフォーマンスについての一般的なアイデアを提供するためだけに使用され、基本的に、開発者に最後の変更が何かを壊し、パフォーマンスに重大な影響を与えることを開発者に警告します テスト駆動開発（TDD）は、これらのテストでは不可能です。コードの実装を開始する前に、そもそもどのように失敗しますか？ パフォーマンステストが多すぎると、テストの実行に必要な時間に影響するため、このアプローチは短いアクションのみに制限されます。 これらの問題を考慮すると、QA部門による実際のパフォーマンスメトリックと組み合わせた場合、このような単体テストを使用することは依然として興味深いと思います。 私が間違っている？これに単体テストを使用することを完全に受け入れられないようにする他の問題はありますか？ 私が間違っている場合、ソースコードがソース管理に到達してQA部門によって検証される前に、ソースコードの変更がパフォーマンスに深刻な影響を与えたことを開発者に警告する正しい方法は何ですか？ ¹実際、ユニットテストは、同等のハードウェアパフォーマンスを備えた開発者のPCでのみ実行されることが期待されています。 ²アクションとは、実行に数ミリ秒かかるかなり短いコードのことです。