ScalaCheckについて

パート1.はじめに

ScalaCheckは、Scalaでの単体テストの作成をはるかに簡単にする組み合わせライブラリです。 Haskell言語用のQuickCheckライブラリに最初に実装されたプロパティベースのテストアプローチを使用します。 QuickCheckには多くの実装があります： Java 、 C 、および他の言語とプラットフォーム用。 このアプローチを使用すると、テストの開発時間を大幅に短縮できます。

この一連の記事は、 以前のパーボイルドと多くの点で似ているため、物語の構造は似ています。 このすべてがなぜ必要なのかを説明します。次に、プロパティとジェネレーターのプリズムを通して世界を見ることを学び、さらに複雑なものに進みます。 に興味がありますか？ 猫をお願いします。

サイクル構造

• はじめに
• 発電機
• プロパティ
• 最小化と状態テスト
• 統合と設定

はじめに

単体テストは、ソフトウェア開発で最も重要なアプローチの1つです。 プログラムがコンパイル中に型システムのレベルでチェックに合格しても、論理エラーが含まれていないという意味ではありません。 つまり、プログラミング言語がどれほど強力であっても、コードのテストは不可欠です。 ただし、テストのコストは非常に高くなります。費やされる工数に加えて、単体テストの日常的な記述に非人道的な努力をする必要があります。 このため、多くの顧客はテストを節約します。多くのプログラマーはこれを非常に喜んで使用しています。

同意し、膨大な数のケースをカバーし、同じタイプの構文構造を毎日書くことは疑わしい喜びです。 残念ながら、関数型言語のタイプセーフコードでさえテストする必要があります。 また、機能パラダイムを適用することで単体テストが大幅に容易になりますが（副作用がないため、少数のエッジケースを考慮して状態テストを完全に忘れることができます）、テストコードの量は大幅に削減されません。 さらに、手動テストはコードにある程度の自信を与えますが、時間の経過とともに見落とした特定のケースが見つからないことを保証することはできません。

ScalaCheckのアプローチにより、次の抽象化レベルに移行し、このルーチンの重要な部分を回避しながら、テストコードの可読性を高め、サイズを小さくすることができます（保守性にプラスの影響を与えます）。 テストによるコードのカバレッジも著しく増加します。 そして、これを達成するために、いくつかの新しい概念に精通する必要があります。

プロパティ指向テスト

プロパティとは

まず、プロパティとは何かを見てみましょう。 簡単に言えば、プロパティは、テストされた関数の入力値とそれらで得られた結果を関連付ける論理ステートメントです。 さらに、ここでいう「プロパティ」という言葉は、日常のプログラマーの意味（特定のオブジェクトに属するデータ）ではなく、特定のオブジェクトセットに対して完全に有効な特定の法則としての数学的な意味で理解する必要があります。 たとえば、実数の代数における結合性または分配性の特性を思い出してください。

プロパティをテストするとき、テストされる関数の実装の詳細は気にしませんが、

ただし、その入力および出力データ、仕様のみ。 たとえば、ライプニッツ言語で書かれた次の単純なプロパティを例にとってみましょう。

∀x ∈ ℝ: x ≠ 0 ⟹ x² > 0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Leibnizkyを理解していない場合は、絶望しないでください。すべてがScalaに置かれます。

ScalaCheckを使用すると、ほとんど元の数学的形式で記述できます。

 forall { x: Double => (x != 0) ==> x * x > 0 }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ロシア語では、「ゼロに等しくない実数xの場合、x²は常にゼロより大きくなります。」

著者は、 Double



型が少しtheでないことをよく知っていますが、

言葉遣いの絶対的な正確さの表現の簡素化は犠牲にしなければならないでしょう。

ご覧のとおり、このプロパティは、JUnitの従来のアサーションテストよりも高いレベルの抽象化を表します。 ただし、最終的にはすべてがそれらに帰着します。ScalaCheckは、プロパティの抽象的な記述に基づいて、手で書くものと同等の品質の個別値の非常に具体的なテストを生成します。

プロパティは理論ではありません

JUnit4には、 理論と呼ばれる興味深いメカニズムがあります。 （ああ、それらは仮説とも呼ばれます...）理論はScalaCheckと非常によく似た方法で機能しますが、ランダムな入力データを生成して最小化（ 縮小 ）を実行する方法がわかりません。

悲しいかな、私は理解できる用語「縮小」のより良い翻訳を発明しませんでした

「最小化」よりもロシア語に。 あまり正しく聞こえませんが、より良いです、

私の他の試みより。

それでは、JUnitビューの理論とは正確には何ですか？ まず第一に、これは特別なタイプの単体テストです。 理論は、テストデータの特定のセット（それらはデータポイントと呼ばれます ）からの各要素に対して何らかの条件が真であるかどうかをチェックします。 これにより、検証ロジックを一度プログラムしてから、さまざまなデータセットですばやく実行できます。

メソッドを理論にするには、それに応じて注釈を付ける必要があります。 @Theory



追加し@Theory



。 入力データには@DataPoint



として注釈が付けられ@DataPoint



。 これは、ランナーがテストを複数回（各データポイントに1回）実行することを推測するのに十分です。 以下は、JUnitのドキュメントからうっかり借用された小さな例です。

 @RunWith(Theories.class) public class UserTest { //    — . @DataPoint public static String GOOD_USERNAME = "optimus"; //    — ,     . @DataPoint public static String USERNAME_WITH_SLASH = "optimus/prime"; @Theory public void filenameIncludesUsername(String username) { assumeThat(username, not(containsString("/"))); assertThat(new User(username).configFileName(), containsString(username)); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このメカニズムは、ScalaCheckで使用されるメカニズムに似ています。 2つの小さな違いのみがあります。

• ScalaCheck自体がテストデータを生成します。
• テストが一部のデータセットでクラッシュした場合、ScalaCheckは反例で簡単に終了しようとします。さらに単純な特殊なケースを選択して、さらにデバッグを促進します。

これらの違いにより、ScalaCheckは、コードサイズとテスト数の両方の面で理論を打ち破ることができます。 しかし、まだ理論についてもっと知りたい場合は、次のことができます。

ここでそれらについて読んでください 。

プロパティベースのアプローチの長所と短所

読者の疑いに反して、ScalaCheckはScalaTestや悪名高いJUnitに完全に取って代わるものではなく、単体テストプロセスに次のような追加の利点をもたらすために作成されました。

• 簡潔さ：コードが少ない-標準（アサーションベース）アプローチと比較してカバレッジが高い
• 高レベル：特定のケースではなく、入力全般に焦点を当てています。
• 最小化：何かが壊れている場合、それらは正確にどこを見つけるのに役立ちます（または私たちは自分自身を助けます）。
• コンポーネントごとにテストするよりも、ユニットとしてテストする方が簡単なエンティティの存在。

ただし、プロパティ指向のテストは特効薬ではありません。

このアプローチには欠点もあります。

• 抑制された機能のテスト時間は、あなたが憧れの月にmoonえるようにします。 （可能ですが、これはプラスです。私の実践では、ScalaCheckの実装により、すべてのプロジェクト参加者が最適化について考えるようになった場合を知っています。）
• 誤った安心感。 ScalaCheckを使用すると、テストですべてをカバーできたと簡単に信じられますが、まったくそうではないことがよくあります。
• 境界条件の影響を受けない。
• テストセットの均一なランダム分布。 一般に、これは良いことですが、必ずしも便利ではありません。

いつ使用しますか？

ScalaCheckは、他のテストフレームワークと同様に使用できます。 少し違った考え方をする必要がありますが、結局、ScalaCheckはほとんどすべてのテストを書くことができます-常に最も効果的で便利で読みやすい方法ではありません。 ただし、ScalaCheckが本当に優れている領域があります。

• 入力データに非常に敏感なコード。
• 状態マシンまたは状態依存システム。
• パーサー（私は個人的にScalaCheckを使用しています）;
• さまざまなデータコンバーター ：
  
  
  • バリデーター
  • 分類子;
  • アグリゲーター
  • 選別機など
• Spark RDD、およびHadoopのマッパーとレデューサー。

スカラチェック

ライブラリ機能

ScalaCheckは次のとおりです。

• コンパクトライブラリ（コード付き20ファイル未満）;
• 追加の依存関係の欠如;
• 内部状態のテストのサポート（ステートフルテスト）;
• 擬似乱数ジェネレータとしてjava.util.Random
  
  
  
  を使用することを拒否します（さらに、ScalaCheckは、returnを使用した検索を使用して、ランダムなテストセットが繰り返されないことを慎重に確認します）。
• scala-jsおよびdottyのサポート。

java.util.Random



内では、 線形合同法が使用されます

擬似ランダムシーケンスの生成（以降-LCG）。 もっとできる

公式文書をお読みください。 LCGは十分に提供しません

擬似乱数生成の品質。ほとんどの場合に使用されます

ライブラリは、シンプルさと高いパフォーマンスのみに依存しています。

ScalaCheckは独自のジェネレーターを使用します。

深刻な統計アプリケーション。 ジェネレーターの詳細を確認できます

こちら 。

準備作業

プロパティ指向のテスト、特にScalaCheckが必要かどうかを決定したら、準備作業を始めましょう。 プロジェクトに次の依存関係を追加します（読者の皆さん、既にScala 2.12に切り替えていることを願っています）。

 <!--  sbt  gradle,  ,   Maven. --> <dependency> <groupId>org.scalacheck</groupId> <artifactId>scalacheck_2.12</artifactId> <version>1.13.4</version> </dependency>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、最新バージョンを使用していることを前提としています。 Scala 2.12と組み合わせてライブラリの古いバージョンを使用すると問題が発生します。 注意してください。

前述のように、ScalaCheckは、プロパティとジェネレーターという2つの主要な概念に基づいて構築されています。 プロパティは、ロシアのブログを含む多くのブログでよく取り上げられています。 したがって、ジェネレーターにもっと注意を向けようとします。 このパートでは、プロパティとジェネレータの両方について簡単に説明します。

プロパティについて少し

プロパティは、テストされた最小モジュールです。 org.scalacheck.Prop



クラスのインスタンスによって提示されます。 最も簡単な例：

 import org.scalacheck.Prop val propStringLengthAfterConcat = Prop forAll { s: String => val len = s.length (s + s).length == len + len } //      ,    //  val propDivByZero = Prop.throws(classOf[ArithmeticException] {1/0}) //    ,       //     ,    //  IndexOutOfBoundsException val propListIndexOutOfBounds = Prop forAll { xs: List[Int] => Prop.throws(classOf[IndexOutOfBoundsException]) { xs(xs.length + 1) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ジェネレーターについて

実際には、ジェネレータはプロパティ以上に作成する必要があります。 それらを使用するには、 org.scalacheck.Gen



をインポートする必要があります。

 import org.scalacheck.Gen // ,       //  . val binaryDigit = Gen.choose(0, 1) val octDigit = Gen.choose(0, 7) // ,       //   . val vowel = Gen.oneOf('a', 'e', 'i', 'o', 'u')
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ScalaCheckには、標準タイプ用の既製のジェネレーターのセットもあります。

 // ,    . val alphaLower = Gen.alphaLowerChar // ,    (  // ,      ,   //      ). val identifier = Gen.identifier // ,      Long. val natural = Gen.posNum[Long]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

map



を適用することで既存のジェネレーターを組み合わせて理解することもできます。

 val personGen = for { charValue <- Gen.oneOf("Jason", "Oliver", "Jessica", "Olivia") ageValue <- Gen.posNum[Int] } yield Person (name = nameValue, age = ageValue)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プロパティとジェネレータの両方については、次の記事で詳しく検討します。 シリーズの次の記事はジェネレーターについてです。 読んでくれてありがとう、連絡を取り合う。