問題タブ [scalacheck]

Playframework 2.3.x で specs2 で ScalaCheck を使いたいのですが、build.sbt

ただし、これはコンパイル中にエラーを返すことがわかりました

のバージョンがPlayframeworkspecs2-scalacheckの依存関係と互換性がない可能性があると思いました。ただし、どちらにも存在しない Playframeworkorg.specs2の正確なバージョンはわかりません。specs2build.sbtplugin.sbt

誰かがこれについてアイデアを持っていますか?

私は ScalaCheck を試していますが、ScalaTest のユーザー マニュアルにある最初の例をビルドする方法がわかりません。以下は、いくつかのインポートが先行し、いくつかのライブラリ クラスから拡張されたクラス内にラップされる必要があると確信しています。ユーザーズマニュアルのページには「ミックスイン」と書かれてPropertyChecksいますが、ミックスするのに適切なクラスの例は示されていません:

さまざまな組み合わせを試してきましたが、これまでに得た最良の結果は、次のようなコンパイル エラーです。

テスト、インポート、およびすべての完全なソース ファイルは何ですか?

テスト中は、Unicode 文字を修飾したいと考えています。範囲が広い場合もあれば、範囲が狭い場合もあります。いくつかの特定のジェネレーターを作成しました。

latinUnicodeCharacterジェネレーターは、標準ラテン文字 (「A」、「B」など) から高次ラテン文字 (ゲルマン/北欧など) までの範囲の文字を選択します。これは、名前などのラテン語ベースの文字入力をテストするのに適しています。

はlatinUnicodeGenerator、長さが 21 ～ 40 文字の文字列を作成します。これらの文字列には、横方向のスペース (単なるスペース文字ではなく、他の「横方向のスペース」) が含まれます。

最後の例 はlatinUnicodeGeneratorNoWhitespace、電子メール アドレスなどに使用されます。ラテン文字は必要ですが、スペースや制御コードなどは必要ありません。問題:最終結果をマッピングStringして制御文字を除外しているため、String縮小され、全体の長さが 21 文字未満になることがあります (場合によっては)。

問題は、どうすれば実装できますlatinUnicodeGeneratorNoWhitespaceが、常に 21 ～ 40 文字の文字列を取得できるようにジェネレーター内で実行できますか?

ScalaCheck コードで、非常にまれですが、再現可能な MalformedInputException が発生します。

私はそれを完全に特定することも、「時折」を除いて確実に再現することもできませんでしたが、問題を引き起こしていると思われるコードは次のとおりです。

そして、ここに私が見た例外があります:

誰がそれを引き起こしているのか、そしてそれを確実に防ぐ方法をもっと重要に考えていますか?

いくつかのオブジェクトをランダムな入力値でテストするために、scalatest で scalacheck を使用したいと考えています。まず、簡単なサンプルを 1 つ試してみましたが、Eclipse 経由または sbt 経由で起動するとエラーが発生します。コードは次のとおりです。

実行時に、次のエラーが発生します。

scalatest_2.11-2.2.1 と scalacheck_2.11-1.12.3 を scala 2.11.6 で使用しています。

GeneratorDrivenPropertyChecks の代わりに TableDrivenPropertyChecks を使用して別のテストを行うと、うまくいきます。

ドキュメントやグーグルでヘルプが見つかりません。コードエラーですか、バグですか、それともバージョンの問題ですか? 誰かが解決策を見つけるのを手伝ってくれますか?

scalacheck でシャッフルされたシーケンスを生成しようとしています。Scalacheck には、それを直接行うためのジェネレーターが用意されていません。また、オンラインで簡単な答えを見つけることができませんでした。少し考えた後、以下は私がやった方法です。役に立つかどうか他の人が見つけてくれることを願っています。

私はいくつかの古いユニット テストをプロパティ ベース テスト (PBT) に置き換えようとしてscalaいscalatest - scalacheckます。テストしたいメソッドがある場合、単純化された状況は次のとおりです。

通常、次のような単体テストを作成します。

したがって、テストごとに、期待する出力を書きますが、問題ありません。さて、PBT では、次のようになります。

すべての入力に対して true になるテストを作成しようとすると、テストでStringメソッドのロジックを再度作成する必要があることに気付きます。この場合、テストは次のようになります。

つまり、出力が正しいことを確認するために、テストで実装を作成する必要がありました。これから抜け出す方法はありますか？私は PBT を誤解していますか?代わりに、次のような他のプロパティをテストする必要があります。

• 「文字列はオリジナルと同じ長さでなければなりません」
• 「文字列には元のすべての文字が含まれている必要があります」
• 「文字列に小文字を含めないでください」...

それももっともらしいですが、かなり不自然で明確ではないように思えます。PBT の経験が豊富な人は、ここで光を当てることができますか?

編集: @Eric のソースをたどってこの投稿にたどり着きました。(カテゴリの適用でもう一度times): ( F#)内のメソッドをテストするために 、まさに私が意味することの例があります:

著者は、最終的に次のようなテストを作成します。

したがって、そのメソッドをテストするために、メソッドのコードがテストで複製されます。この場合、乗算と同じくらい些細なことですが、より複雑なケースに推定されると思います。

scalacheck出力から実行する場合sbt console、列幅は 76 文字に制限されます。

その制限を増やす方法はありますか？