任意のリストに対して動作する抽出と呼ばれる関数をテストしています。

たとえば、次のようにテストしたい

しかし、これはコンパイルされません。runまたはの型を指定する必要prop_lenがあります。QuickCheck は を生成できないため[a]、具体的なものを生成する必要があります。だから私は選んだInt：

aのタイプで指定する代わりに、QuickCheck を選択する方法はありますrunか?

Quickcheckとそのバリアント ( Javaにもある) は興味深いようです。ただし、学術的な関心は別として、実際のアプリケーションのテスト (たとえば、GUI アプリケーションまたはクライアント/サーバー、または StackOverflow 自体を使用することさえ) で本当に役立ちますか? 同様のテスト ジェネレーターを使用した経験があれば、歓迎します。

プログラマーとして、私はTDDの哲学に真摯に取り組み、自分が書いた重要なコードに対して広範な単体テストを行うように努力してきました。この道は時々苦痛になることがあります（複数の単体テストの変更をカスケードする原因となる動作の変更、大量の足場が必要です）が、全体として、変更のたびに実行できるテストなしでプログラミングすることを拒否し、コードのバグははるかに少なくなります結果。

最近、私はHaskellで遊んでいます、そしてそれは常駐テストライブラリ、QuickCheckです。TDDとは明らかに異なる方法で、QuickCheckは、コードの不変条件、つまり、入力のすべて（または実質的なサブセット）を保持する特定のプロパティのテストに重点を置いています。簡単な例：安定ソートアルゴリズムは、2回実行した場合でも同じ答えが得られ、出力が増加し、入力の順列である必要があります。次に、QuickCheckは、これらの不変条件をテストするためにさまざまなランダムデータを生成します。

少なくとも純粋関数（つまり、副作用のない関数-そして正しくモックを作成すればダーティ関数を純粋関数に変換できる）の場合、不変テストはそれらの機能の厳密なスーパーセットとして単体テストに取って代わる可能性があるように思われます。各単体テストは、入力と出力で構成されます（命令型プログラミング言語では、「出力」は関数の戻りだけでなく、変更された状態でもありますが、これはカプセル化できます）。おそらく、手動で作成したすべての単体テスト入力をカバーするのに十分なランダム入力ジェネレーターを作成することができます（そして、それはあなたが考えもしなかったケースを生成するので、いくつか）。境界条件が原因でプログラムにバグが見つかった場合は、ランダム入力ジェネレーターを改善して、そのケースも生成するようにします。

したがって、課題は、すべての問題に対して有用な不変量を定式化できるかどうかです。私はそれがそうだと思います：最初に答えを計算するよりも、それが正しいかどうかを確認するための答えが得られたら、それははるかに簡単です。不変条件について考えることは、アドホックテストケースよりもはるかに優れた複雑なアルゴリズムの仕様を明確にするのにも役立ちます。これにより、問題のケースバイケースの考え方が促進されます。以前のバージョンのプログラムをモデルの実装として使用することも、別の言語のプログラムのバージョンを使用することもできます。最終的には、入力または出力を明示的にコーディングしなくても、以前のすべてのテストケースをカバーできるようになります。

私は気が狂ったのですか、それとも何かに取り組んでいますか？

Atomic特定の型をラッパー値（）との間で変換するための関数を定義する型クラスがありますAtom。Atomic「のすべてのインスタンスについて、任意の値を安全に保存および取得できます」というQuickCheckプロパティを定義したいと思います。プロパティは次のようになります。

ただし、QuickCheckを介してそのプロパティを実行しようとすると、1つのインスタンス（Bool）を選択してテストするだけです。私は現在、テストリストでサポートされている各アトミック型の型シグネチャを定義することでこれを回避していますが、これは冗長でエラーが発生しやすいです。

これを自動的に行う関数を定義しようとしています：

ただし、タイプチェックエラーで失敗します。

複数のタイプに対してQCプロパティをテストするためのより良い方法はありますか？そうでない場合、forallAtomsを機能させることができますか、それとも型システムでサポートされていませんか？

私は実世界の Haskellに取り組んでいます。第 4 章の演習の 1 つは、foldrベース バージョンの を実装することですconcat。私の結果を検証するための既存の実装があるため、これは QuickCheck を使用したテストの優れた候補になると思いました。Arbitraryただし、これには、任意のを生成できる型クラスのインスタンスを定義する必要があります [[Int]]。これまでのところ、これを行う方法を理解できませんでした。私の最初の試みは：

これにより、テストは実行されません。さまざまな断片を見て、Arbitraryインスタンス宣言が必要であると推測し、追加しました

これにより、インスタンス宣言が無効であり、 -XFlexibleInstances を追加すると問題が解決する可能性があると ghci が不平を言うようになりました。{-# OPTIONS_GHC -XFlexibleInstances #-}ディレクティブを追加すると、タイプの不一致と重複インスタンスの警告が発生します。

だから私の質問は、これを機能させるために何が必要ですか? 私は明らかに Haskell の初心者であり、私を助けるリソースが見つかりません。どんなポインタでも大歓迎です。

編集

fconcatテストで最初の方法が次のように定義されて いる場合、QuickCheckの出力に誤解されたようです

実際に関数を正しく実装すると、実際に期待される結果が得られます。ドゥープ！

数独を変更して、それがまだ有効かどうかをチェックする小道具を書こうとしています。

ただし、「oneof」関数の正しい使い方がわかりません。ヒントを教えてください。

ここにいくつかの詳細があります...

私はこの小道具で3時間苦労しているので、どんなアイデアでも大歓迎です！

QuickCheck 1 と QuickCheck 2 の主な違いは何ですか? Haddock のドキュメントを見ると、より多くのモジュールに分割されており、新しい型とクラスcoarbitraryに置き換えられており(これは私には理解しやすいようです)、モナディック コードのテストがサポートされていることがわかります。他に何を知っておくべきですか？FunFunArbitrary

Monadic QuickCheckを使用してIOアクションをテストする簡単な例を教えてもらえますか？

QuickCheck 1の機能verboseCheckは、QuickCheck 2にはないようです（少なくとも、見つかりません）。テスト中にどの値が使用されているかを示す他の方法はありますか？

QuickCheck を使用してテストしたい Happstack.State MACID メソッドのセットがありますが、それを達成するための最もエレガントな方法を見つけるのに苦労しています。私が直面している問題は次のとおりです。

• Evモナド計算を評価する唯一の方法は、またはIOを介し​​てモナド内で行うことです。queryupdate
• 純粋にインメモリ MACID ストアを作成する方法はありません。これは設計によるものです。したがって、IOモナドで実行するということは、各テスト後にクリーンアップする一時ファイルがあることを意味します。
• initialValue状態を除いて、新しい MACID ストアを初期化する方法はありません。Arbitraryステート ホールセールを置き換えるアクセス メソッドを公開しない限り、生成することはできません。
• 上記のすべてに対処するということは、MonadReaderor ( の機能のみを使用するメソッドを記述し、 orの代わりにMonadStateテストを実行することを意味します。これは、メソッド定義内でorなどを使用しないことを意味します。ReaderStateEvgetRandomgetEventClockTime

私が見ることができる唯一のオプションは次のとおりです。

• 使い捨てのディスク上の MACID ストアでメソッドを実行し、各テスト後にクリーンアップし、毎回開始するように調整しinitialValueます。
• ほとんどのコードがMonadReaderorで実行されるようにメソッドを記述し (テストがより簡単です)、必要に応じてorMonadStateを呼び出す、その周りの少量の QuickCheck 不可の接着剤に依存します。getRandomgetEventClockTime

私が見落としているより良い解決策はありますか？