私はPexとの考え方が大好きです - 静的コード解析によるユニットテストを自動生成する - しかし、実際にツールによって生成されたテストは恐ろしいです、醜い、しっかりとPexのモジュールに結合され、読んで理解するのが難しいなどPex（およびその出力）はエンタープライズ環境に適していますか？
されていますメンテナンスの容易さが重視されるエンタープライズ環境での使用に適したツール（現在の状態で）
また、私はPexの使用目的を誤解していますか？
実際、あなたは誤った使い方をしています。
Pexはホワイトボックステストツールです。テストするコードの分析に基づいてテストケースを生成します。この理由は、エッジケースを検出してテストすることです。。基本的には、自動生成されたテストを変更すべきではありません。
あなたの通常の単体テストは、Pexで置き換えることはできません。単なる追加ツールです。
Pexは、外部に依存しない複雑なアルゴリズムをテストするのに非常に便利です。たとえば、SQLステートメントやファイルアクセスで、大文字と小文字を区別するのに役立つものではありません。ただし、エッジケースを見つけてコードカバレッジを高めるために、通常の単体テストに加えて非常に便利です。
これは主観的な問題だ...
私ははい、与えられたフレームワーク/ APIで書かれたテストは、多くの場合、しっかりとそのフレームワークに結合されていることを言うと思います。 Pexの意図は、 "可読"テストを生成することではなく、与えられた制約セットに対するコードカバレッジを保証することです。それがあなたの製品にとって貴重なものなら、それは適切です。そして、確かに私は与えられたチームとコードベースに対して、これが価値を提供することを賭けるでしょう。
すべての企業は異なりますが、テストツールの適性を規定するのは製品とそのコードです。疑問に思うことは、問題の組織に関係なく、与えられたコードベースのPexの価値であることを私は示唆しています。
私は大手金融機関でpexを使用しており、その使用を推奨しますが、非常に特殊なケースの場合にのみ使用します。私はpexはそれが何であるか（ここでは他の場所で説明されているように、エッジケースを見つけるためのホワイトボックステスト）は良いと思っていますが、テストは非常に緊密に結合されているため長寿なものではありません。
基本的にpexは、カバレッジを生成するのに優れています。テストがなく、速くしたい場合は、Pexを使用してください。しかし、もう一度使用するのではなく、手書きテストで合意されたカバレッジメトリックを満たすための新しいコードの基準を適用することをお勧めします。
このようにして、pexの脆弱なテストは、時間の経過とともにより柔軟で高品質のテストに置き換えられます。
Visual Studio 2012では、PexがFakesによって（一部）置き換えられています。http://msdn.microsoft.com/en-us/library/hh549175.aspx –