ScalaTest と Scala Specs 単体テスト フレームワークの違いは何ですか?
https://stackoverflow.com/questions/2220815
-
19-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian解決
Specs と ScalaTest はどちらもユーザーが満足している優れたツールですが、いくつかの点で異なります。おそらく Scala のメインのテスト ツールとしてどちらかを選択することになるでしょうが、両方の一部を使用できるため、もう一方を諦める必要はありません。ScalaTest が好きなら FeatureSpec 構文と仕様の Mockito 構文を使用すると、たとえば、両方の jar ファイルをクラスパスに配置して、両方を同時に使用できます。ここでは、仕様と ScalaTest の間で私が気づいた主な設計哲学の違いをキャプチャしてみます。
おそらく、これらのツール間の主な哲学的な違いは、仕様が動作駆動開発 (BDD) 向けに設計されているのに対し、ScalaTest はより一般的なことです。ScalaTest は、BDD などのテスト クラスで好みの動作を得るために組み合わせることができる特性を提供します。また、何か異なる動作が必要な場合は、独自の動作を簡単に定義することもできます。
ScalaTest は BDD をサポートします。 Spec, FeatureSpec, WordSpec, FlatSpec, 、 そして GivenWhenThen 特性に加えて、優れたマッチャー構文を取得するために組み合わせることができる特性もあります。「べき」が好きなら、ShouldMatchers を混ぜてください。「must」が好きなら混ぜてください MustMatchers. 。ただし、BDD は好きだがマッチャー構文は好きではない場合は、マッチャー トレイトを混ぜずに ScalaTest の仕様トレイトの 1 つだけを使用できます。Specs には拡張する Spec クラスがあり、マッチャー式で「must」という単語を使用する必要があります。ここで明らかな大きな哲学的な違いは、ScalaTest ではより多くの選択肢が提供されるということです。この選択領域をナビゲートしやすくするために、ここにデシジョン ツリーを示します。
http://www.scalatest.org/quick_start
マッチャーの構文も ScalaTest と仕様間で異なります。ScalaTest では、演算子表記でどこまでできるかを試した結果、単語の間にスペースが入った、英語の文章に非常によく似たマッチャー式が完成しました。仕様マッチャー構文は、キャメルケースを使用して単語をさらに実行します。
仕様には ScalaTest よりも多くのマッチャーがあり、それは設計姿勢の違いを反映していると思います。実際、私が構築してリリースを検討したマッチャー構文のおそらく 2/3 をカットしました。将来のリリースではさらにマッチャーを追加する予定ですが、追加する前にユーザーが実際に何かを望んでいることを確認したいと思いました。ただし、ScalaTest のマッチャーには動的プロパティ マッチャー構文が含まれており、その余裕の一部を占めています。たとえば、Specs では次のように書くことができます。 java.io.File:
file must beDirectory
これにより、 isDirectory そしてそれが真実であることを確認してください。ScalaTest には特別なマッチャーはありません。 java.io.Files 現時点では、ただし ScalaTest では、次のような動的チェックを使用できます。
file must be a ('directory)
after にシンボルを渡すときはいつでも be, 、リフレクションを使用して (この場合) という名前のメソッドまたはフィールドを検索します。 directory またはという名前のメソッド isDirectory. 。を定義して、これを静的にする方法もあります。 BePropertyMatcher (通常、必要なコードは 2 行または 3 行だけです)。したがって、ScalaTest では基本的に、少ない API でより多くの機能を提供しようとしています。
スペックとスカラテストの別の一般的な設計態度の違いには、暗黙的な変換が含まれます。デフォルトでは、ScalaTest を使用する場合、暗黙的な変換は 1 つだけ行われます。 === すべてのオペレーター。(必要に応じて、1 行のコードでこの暗黙的な変換を「オフ」にすることができます。そうする必要がある唯一の理由は、独自の機能を持つ何かをテストしようとしている場合です。 === ScalaTest では他にも多くの暗黙的な変換が定義されていますが、それらを使用するには、トレイトを組み込むかインポートを実行することによって、明示的にコードに変換を「招待」する必要があります。クラスを延長するとき Specification 仕様では、デフォルトで数十の暗黙的な変換が行われると思います。それが実際にどの程度重要になるかはわかりませんが、人々は独自のインプリシットを使用するコードをテストしたいと思うでしょう。場合によっては、テスト フレームワークのインプリシットと運用コードのインプリシットとの間に競合が発生する可能性があります。そうなると、仕様よりも ScalaTest で問題を回避する方が簡単かもしれないと思います。
私が気づいた設計姿勢のもう 1 つの違いは、オペレーターの快適さです。私の目標の 1 つは、ScalaTest を使用する他の人のテスト コードを見たプログラマーが、ScalaTest ドキュメントで何も調べなくても、その意味を推測できるようにすることでした。ScalaTest クライアント コードが完全に明らかになるようにしたかったのです。この目標が明確に表れた 1 つの方法は、ScalaTest が演算子に関して非常に保守的であることです。ScalaTest では 5 つの演算子のみを定義します。
===, 、つまり等しいことを意味します>, 、より大きいことを意味します<, 、 未満>=, 、以上<=, 、以下。
それでおしまい。したがって、これらのことは、意味するところとほぼ同じように見えます。他の人のコードに次のようなコードが含まれている場合:
result should be <= 7
これが何を意味するかを推測するために API ドキュメントを参照する必要がなくなることを願っています。 <= 手段。対照的に、演算子を使用すると仕様ははるかに自由になります。それは何も悪いことではありませんが、違いがあります。演算子を使用するとコードをより簡潔にすることができますが、その代償として、次のようなものを見つけたときにドキュメントを参照する必要がある場合があります。 ->-, >>, |, |>, !, 、 または ^^^ (これらはすべて仕様において特別な意味を持っています) 同僚のテストコードにあります。
もう 1 つの哲学的な違いは、フィクスチャを共有する必要がある場合に ScalaTest で関数型スタイルを使用することを少しだけ簡単にしようとしているのに対し、Specs はデフォルトで関数型スタイルの伝統を引き継いでいることです。 setUp そして tearDown JUnit によって普及したアプローチで、各テストの前に変数を再割り当てします。ただし、そのようにテストしたい場合は、ScalaTest を使用すると非常に簡単です。混ぜるだけでいいのです BeforeAndAfter 特性。
ScalaTest についてさらに詳しく知りたい場合は、2009 Devoxx カンファレンスで私が行った「Get Higher with ScalaTest」プレゼンテーションをここでご覧ください。
http://parleys.com/play/514892260364bc17fc56bde3/chapter0/about
他のヒント
主な違いは次のとおりです (主に仕様の観点から:-)):
ScalaTest は、仕様よりも多くの「テスト スタイル」を提供します (次のセクションの各箇条書きにアクセスできます)。 クイックスタート 各スタイルの詳細を確認するにはページを参照してください)
ScalaTest と仕様には異なるマッチャーのセットがあります。比較できます ここ ScalaTest と ここ スペック的には。その側面から見ると、仕様には、仕様を作成する際に便利な小さな機能がたくさんあります。XML マッチャー、マッチャーの構成 (マッチャーを変換して再利用する簡単な方法)、正確な失敗、長い文字列の詳細な違いなど。
Mockito には、仕様上優れた BDD サポートが与えられています。 モキト
スペックはある データテーブル これにより、多数の小さな例を一種のテーブルにグループ化できます (演算子がテーブルの区切り文字として使用されることに耐えられる場合)
仕様では、libidum および 自動的にクリーンアップされる あらゆるレベルで
これは確かに非常に部分的で偏った比較であり、他にも多くの違いが存在します (ライブラリはまだ進化中です...)。
結局のところ、それはテスト/仕様のスタイルに大きく依存すると思います。それが単純であれば (単純な仕様構造、セットアップ、期待事項など)、両方のライブラリは非常に似たものになるでしょう。それ以外の場合、物事がどのように行われるべきかについては、どちらも独自の見解を持っています。この最後の例として、タグ付けを見てみましょう。で スカラテスト そしてで スペック.
これがお役に立てば幸いです。
私の知る限り、いくつかの高度に特殊な機能を除けば、最終的にはスタイルに応じた個人的な好みになります。
IDEのサポートもポイントになるかもしれない
私は JUnit を介して Eclipse で仕様を動作させようとしてきましたが、公式の解決策は少し「ハック的」であることがわかりました。仕様設定: http://code.google.com/p/specs/wiki/RunningSpecs#Run_your_specation_with_JUnit4_in_Eclipse
ScalaTest との統合 (これも JUnit 経由) は、ハック性が少し低いように思えます。それでも、JUnit や Java ほどうまく機能するものはありません。
ScalaTest のセットアップ: http://groups.google.com/group/scalatest-users/web/running-scalatest-from-eclipse
1 つの決定要因がコンパイル時間である場合、 scalatest の方がパフォーマンスが良いようです。
現在、プロジェクトで spec2 を使用していますが、テストでのコンパイル時間が遅いという問題があります。scalatest への移行に関する POC を終えたところ、一部のソースで 2 つのフレームワークを切り替えるだけでコンパイル時間が約 0.82 倍短縮されたことがわかりました。
