Pex のアイデア (静的コード分析による単体テストの自動生成) は気に入っていますが、ツールによって実際に生成されるテストは恐ろしく、醜く、Pex モジュールに密結合されており、読みにくく、理解しにくいなどです。
そのようなツールは、(現在の状態で) 保守の容易さに重点を置かなければならないエンタープライズ環境での使用に本当に適しているでしょうか?
または、Pex の使用目的を誤解していますか?
4 に答える
1
私は大規模な金融機関でpexを使用したことがあり、その使用をお勧めしますが、これは非常に特殊な場合に限られます。pexはそれが何をするかについては優れていると思います（ここで他の場所で説明されているように、エッジケースを見つけるためのホワイトボックステスト）が、テストは非常に緊密に結合されているため、それほど長くはありません。
基本的に、pexはカバレッジの生成に優れています。テストがなく、高速が必要な場合は、Pexを使用してください。ただし、それを再度使用する代わりに、手書きのテストで合意されたカバレッジメトリックを満たすために、新しいコードの標準を適用することをお勧めします。
このようにして、pexによる脆弱なテストは、時間の経過とともに、より柔軟で高品質のテストに置き換えられます。
于 2012-09-06T16:20:02.200 に答える
1
確かに、あなたは使用目的を誤解しています。
Pex はホワイト ボックス テスト ツールです。テストするコードの分析に基づいてテスト ケースを生成します。これは、エッジ ケースを検出してテストするためです。したがって、基本的に、自動生成されたテストを変更することさえすべきではありません。
通常の単体テストを Pex に置き換えることはできません。単なる追加ツールです。
于 2012-09-06T13:00:31.600 に答える
1
これは主観的な質問のようです...
はい、特定のフレームワーク/API で記述されたテストは、多くの場合、そのフレームワークに密接に結合されています。Pex の意図は、「読み取り可能な」テストを生成することではなく、特定の一連の制約に対するコード カバレッジを確保することです。それがあなたの製品にとって価値があるなら、それは適切です - そして確かに、特定のチームと特定のコードベースにとって、これが価値を提供することに賭けたいと思います.
企業はそれぞれ異なりますが、テスト ツールの適合性を決定するのは製品とそのコードです。問題の組織に関係なく、特定のコードベースに対する Pex の価値を疑問視することをお勧めします。
于 2012-09-06T13:05:41.923 に答える
0
Pex は、外部に依存しない複雑なアルゴリズムのテストに非常に役立ちます。たとえば、SQL ステートメントやファイル アクセスでエッジ ケースを見つけるのには役立ちません。ただし、エッジ ケースを見つけてコード カバレッジを増やすには、通常の単体テストに加えて非常に役立ちます。
于 2012-09-06T13:01:43.067 に答える