22

Pexを使用したことがある方は、ツールとしての Pex の長所と短所は何だと思いますか?

また、一般的に、 TDD/単体テストを補完する「自動化された探索的テスト」の長所と短所は何だと思いますか?

4

5 に答える 5

14

Pexを使用すると、パラメーター化された単体テストを作成できます。その意味で、それはTDD /単体テストフローに完全に適合します。テストを作成し、Pexに「探索」させ、失敗したテストを見つけ、コードを修正します。

大きな利点は、ハードコードされた2つの値だけでなく、入力のクラスに対してテストを表現できることです。これにより、テストを作成する際の表現力が高まり、コードが満たすべき不変条件/期待について考える必要があります（つまり、アサーションを作成するのが難しくなります）。

于 2008-09-16T23:53:55.940 に答える
12

探索的テストツールとしてのPexは本当に興味深いと思います。そういう意味では、QAに渡して使ってみたいと思います。

TDDは設計活動であるため、TDDツールとしてはいくつかの作業が必要です。しかし、私はペリが向かっている方向が好きです。自動化された支援設計については、言いたいことがあります。たとえば、TDDが設計ツールであるという理由だけで、設計中に自動ツールで潜在的なエッジケースを指摘できない理由はありません。最初から品質を構築します。

PeliがTDDスタイルのワークフローでPexを使用しているこの投稿を確認してください。http://blog.dotnetwiki.org/TDDingABinaryHeapWithPexPart1.aspx

于 2008-09-12T18:11:38.230 に答える
6

Theories (google David Saff) の記述に関する文献を探します。これは単体テストを記述するためのより一般的な方法であり、Pex を理論探索ツールとして使用すると、これまでの経験から生産性が大きく変化することがわかりました。TDD での Pex の経験を詳述したブログ投稿を書きました。

そして私が言ったように - 私はそれをステロイドの TDD と見なします! TDD に取って代わるものではありませんが、活動を強化します。

于 2009-01-11T23:08:05.837 に答える
5

私は本当にペックスに夢中です。特にチームが小さく、メソッドを作成する人がテストを作成する人と同じである場合は特に、夢にも思わないようなエデグケースのテストを提供します。

それはまたあなたの方法が従う契約上の義務を提供します。

于 2008-11-07T01:34:07.893 に答える
3

テスト ファースト開発では、テスト容易性のためにコードを構造化します。この点で、Pex はコード内の巧妙で厄介なパスを見つけて、単純なカバレッジ メトリクスを超えて支援します。

Moles を使用した Pex の主な利点は、ブラウンフィールド開発を行う際に副作用を追跡できることです。Pex を 1 回実行して出力を保存し、コードの変更を適用してから、Pex を再度実行して何が壊れているかを確認します。

于 2010-07-23T16:30:16.400 に答える