問題タブ [quickcheck]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
2 に答える
359 参照

haskell - 任意から生成された結果を印刷する方法は?

quickCheckResult のみを受け入れsomething -> Bool、次にいくつかの例を模倣して、合格します

[色]のブラケットの機能は何ですか? なぜColour -> Boolですか?任意のインスタンスをquickCheckResultに渡す方法は?

[更新]私の目標は、以下が実行できることです

3.QuickCheck.Functionの使い方(更新)

解析エラー (インデントが正しくない可能性があります)

0 投票する
2 に答える
424 参照

haskell - QuickCheck で関数合成の可換性を偽る方法

  1. 次のコードの CoArbitrary に渡す ex は何ですか?

  2. Test.QuickCheck.Function で Function を使用して、命題で f と g を表す方法は?

  3. と書くのは正しいですか、そうでない場合、どのように?

    where types = [f, g] :: [関数]

  4. バリアントは Function を受け入れることができますか? 私が知っているように、生成関数は><またはQuickCheckのソースコードに記載されているバリアントをよく使用します

エラー:

[更新しました]

CoArbitrary http://www.google.com.hk/url?sa=t&rct=j&q=QuickCheck+meiser.pdf&source=web&cd=1&ved=0CBwQFjAA&url=http%3A%2F%2Fwww.st.cs は実装されていません。 uni-saarland.de%2Fedu%2Fseminare%2F2005%2Fadvanced-fp%2Fslides%2Fmeiser.pdf&ei=hhfHTo_ZDdCciAethMjqDw&usg=AFQjCNFF467CXacWGMkN8jvgqatkcLcVcg

別の記述は、関数の例を模倣し、ghci の '=' でエラーを解析 let prop_commutative (Fun _ f) (Fun _ g) = (f.g) == (g.f) できます。

コード:

0 投票する
2 に答える
924 参照

haskell - クイックチェックに失敗した値を見つける

ある値が QuickCheck のテストに失敗した場合、それをデバッグに使用したいと考えています。次のようなことができる方法はありますか?

私のデータが可能であれば、read何らかの方法でハッキングして IO からデータを取得できたかもしれませんが、そうではありません。

0 投票する
1 に答える
392 参照

optimization - この冪等性の一般化の名前は何ですか?

関数の一般的に有用なプロパティの多くには、簡潔な名前が付いています。たとえば、結合性交換性推移性などです。

これらのプロパティなどの簡略定義を提供するQuickCheckで使用するライブラリを作成しています。

私が質問しているのは、単項関数の冪等性です。関数 f はべき等 iif ∀x です。fx == f (fx)。

このプロパティには興味深い一般化があり、同様に簡潔な名前を見つけるのに苦労しています。名前を提案することで人々の名前の選択に偏りが生じるのを避けるために、名前を P とし、次の定義を提供します。

関数 f は g iif ∀x に関して P 特性を持ちます。fx == f (gx)。これは、冪等性を P に関して再定義することにより、冪等性の一般化として見ることができます。関数 f は、それ自体に関して P プロパティを持っている場合、冪等性です。

これが有用なプロパティであることを確認するには、多くの一般的な最適化を実装するために使用できる書き換えルールを正当化することを観察してください。これは、 g が何らかの正規化関数である場合に発生することがよくありますが、常に発生するわけではありません。いくつかの例:

この物件の名前は?

0 投票する
1 に答える
704 参照

testing - Haskell: (リアクティブ) FSM をクイックチェックでテストする方法は?

現在取り組んでいる小さなサッカー ゲーム用の有限ステート マシン モジュールを作成しました。FSM (基本的にその状態と遷移) を設定するためのインターフェイスを提供します。状態ごとに、開始時と終了時に起動される関数を提供できます。または、FSM が同じ状態のままである間にこれらの関数がいくつかのメッセージを返します。また、時変状態を生成し、時間の経過とともに発生するメッセージを収集するリアクティブ インターフェイス (Yampa) も提供します。コードはData/FSM.hsにあります。

このモジュールをテストする良い方法を探しています。純正なので、クイックチェックしてみようと思いました。私はクイックチェックの経験がないので、ヒントをいただければ幸いです。これまでの私の基本的な理解: FSM を多かれ少なかれランダムに構築するいくつかの関数を提供し、それらに対していくつかの (再び多かれ少なかれランダムな) 遷移を実行します。しかし、そのようにテストを構築する方法がよくわかりません...

0 投票する
2 に答える
1292 参照

haskell - QuickCheck から適切な (小さい) シュリンクを取得するにはどうすればよいですか?

次のようなネストされたリストで QuickCheck を実行しようとしています。

したがって、式はリテラルのリストであり、それぞれのリテラルには述語といくつかの引数が含まれています。predicate/arguments は、それぞれ文字列形式の制約の論理和である値です。これにより、リストのリストのリストのリストが得られます。

QuickCheck プロパティの 1 つが失敗した場合、理解できないページいっぱいの出力が得られる傾向があります。縮小を試す前に、小さな (小さな) 値のセットしか生成できない任意のインスタンスを用意することで、これを回避していました。私のタイプごとに縮小機能を実装すると、少しは役立つようですが、私が望むほどではありません。まだページ一杯の出力が得られます。

私がシュリンクに求めているのは、リテラルの小さなリストであり、各リテラルには小さな値のリストがあり、制約がほとんどなく、それぞれが可能な限り短いものであると思います。しかし、私の現在の取り組みでは、少なくともこれらのリストのいずれかが大きくなりすぎて、出力がひどいものになってしまいました。シュリンクの実装を調整しようとすると、QC に非常に長い時間がかかるようになり (シュリンクの検索?)、効果的にシュリンクするための努力が妨げられます。

このようにネストされたデータがある場合、QuickCheck の失敗を理解する機会をどのように改善しますか?

0 投票する
2 に答える
898 参照

haskell - 障害時のQuickCheck終了ステータス、およびcabal統合

いくつかのクイックチェックテストをcabalと統合する方法を理解しようとしています。この要点quickCheckは、関数が失敗するとゼロ以外のステータスを返すことを示唆していますが、その動作は得られないため、テスト全体exitcode-stdio-1.0を呼び出したくない限り、cabalのテストスイートタイプを使用してもうまくいかないようですerror

カバールのユーザーガイドにもdetailed-1.0テストスイートが記載されていますが、AFAICTはまだ存在していません。それでもそうですか?

このような回答から、多くの人がテストフレームワークパッケージを使用しているようです。それは私にとってやり過ぎですが、それは私が使うべきものですか?

私はこの状況に少し不満を残しています。

私が使用しているもののバージョン:

0 投票する
3 に答える
2945 参照

testing - RustでLisp(適用)または(カレー)をエミュレートするにはどうすればよいですか?

QuickCheckをRustに移植for_allしていますが、型アノテーションがどうあるべきかわからない場合を除いて、すべてを記述しました。

for_all一般に、プロパティラムダとジェネレータラムダのコレクションを受け入れることを私は知っています。プロパティを入力として提供するランダムなテストケースを作成するために、ジェネレーターを評価します。

+++ OK, passed 100 tests.プロパティがtrueを返す場合は出力する必要があり、そうでない場合は、*** Failed!問題のあるテストケース値を出力して出力する必要があります。

0 投票する
1 に答える
188 参照

quickcheck - scalacheck は quickcheck にどのような機能を追加しますか?

すべてのscalacheckのものは言う:

Haskell QuickCheck にはない機能で進化し、拡張されています。

それで、それらの機能は何ですか?

0 投票する
2 に答える
435 参照

testing - QuickCheck がすべての例外をキャッチしないようにするにはどうすればよいですか?

QuickCheck ライブラリは、プロパティのテスト時にスローされるすべての例外をキャッチするようです。特に、この動作により、QuickCheck の計算全体に時間制限を設けることができなくなります。例えば:

QuickCheck はすべての例外をキャッチするため、timeoutブレークします: 実際に計算を中止するわけではありません! 代わりに、QuickCheck はプロパティが失敗したものとして扱い、失敗の原因となった入力を縮小しようとします。この縮小プロセスは時間制限付きで実行されないため、計算に使用される合計時間が規定の時間制限を超えます。

withinQuickCheck のコンビネータを使用して計算時間を制限できると考える人もいるかもしれません。(within指定された制限時間内に終了しない場合、プロパティは失敗したものとして扱います。)ただし、withinQuickCheckは失敗の原因となった入力を縮小しようとするため、プロセスに時間がかかる可能性があるため、私が望むことはできません。長すぎる。(代わりに機能するwithinのは、指定された制限時間内に終了しなかったために失敗したプロパティへの入力を QuickCheck が縮小しようとするのを防ぐバージョンです。)

QuickCheck がすべての例外をキャッチしないようにするにはどうすればよいですか?