122

どちらも、Scala で書かれた Scala 用の BDD (Behavior Driven Development) 対応ユニット テスト フレームワークです。また、Specsの 構築には、 ScalaTestフレームワークも含まれる場合があります。しかし、Specs が提供する ScalaTest が提供しないものは何でしょうか? 違いは何ですか？

4

5 に答える 5

175

Specs と ScalaTest はどちらもユーザーに満足してもらえる優れたツールですが、いくつかの点で異なります。おそらく、どちらかを Scala のメインのテスト ツールとして選びたいと思うでしょうが、もう一方をあきらめる必要はありません。両方の部分を使用できるからです。たとえば、ScalaTest のFeatureSpec構文と仕様の Mockito 構文が気に入った場合は、両方の jar ファイルをクラスパスに配置して、両方を同時に使用できます。ここでは、spec と ScalaTest の間で気付いた主な設計哲学の違いを捉えようとします。

おそらく、ツール間の主な哲学的な違いは、仕様が動作駆動型開発 (BDD) 向けに設計されているのに対し、ScalaTest はより一般的であることです。ScalaTest は、BDD を含むテスト クラスで好みの動作を得るために組み合わせることができるトレイトを提供します。また、別のものが必要な場合は、独自の動作を簡単に定義することもできます。

SpecScalaTest は、 、FeatureSpec、WordSpec、FlatSpec、およびGivenWhenThentraitを通じて BDD をサポートし、また、組み合わせて適切なマッチャー構文を取得できる Trait も備えています。「should」が好きなら、ShouldMatchers を混ぜます。"must" が好きなら を混ぜますMustMatchers。しかし、BDD は好きだがマッチャー構文は好きでない場合は、マッチャー トレイトを混ぜずに ScalaTest の Spec トレイトの 1 つだけを使用できます。Specs には拡張する Specification クラスがあり、マッチャー式で「must」という単語を使用する必要があります。ここで明らかな哲学上の大きな違いは、ScalaTest がより多くの選択肢を提供することです。この選択スペースを簡単にナビゲートできるようにするために、ここに決定木を示します。

http://www.scalatest.org/quick_start

マッチャーの構文も ScalaTest と spec で異なります。ScalaTest では、演算子表記法をどこまで使用できるかを試してみたところ、英文と非常によく似た、単語間にスペースが入ったマッチャー式に行き着きました。仕様マッチャー構文は、キャメル ケースを使用して複数の単語を組み合わせます。

Specs は ScalaTest よりも matcher が多く、それは設計姿勢の違いを反映していると思います。実際、私が構築してリリースを検討したマッチャー構文のおそらく 2/3 を削減しました。今後のリリースでマッチャーをさらに追加する予定ですが、追加する前に、ユーザーが実際に何かを望んでいることを確認したかったのです。ただし、ScalaTest のマッチャーには、動的プロパティ マッチャーの構文が含まれており、そのスラックの一部を占めています。たとえば、 Specs では、次のように記述できますjava.io.File。

file must beDirectory

これにより、が呼び出され、isDirectoryそれが true であることを確認します。現在、ScalaTest には特別なマッチャーはありませんjava.io.Filesが、ScalaTest では次のような動的チェックを使用できます。

file must be a ('directory)

after にシンボルを渡すたびに、リフレクションを使用して (この場合) という名前のメソッドまたはフィールド、またはbeという名前のメソッドを探します。a を定義することにより、これを静的にする方法もあります(通常は 2 ～ 3 行のコードしか必要としません)。基本的に ScalaTest では、より少ない API でより多くの機能を提供しようとしています。directoryisDirectoryBePropertyMatcher

spec と ScalaTest の間のもう 1 つの一般的な設計態度の違いには、暗黙の変換が含まれます。デフォルトでは、ScalaTest を使用すると暗黙的な変換が 1 つだけ取得されます。これは、===演算子をすべてに配置するものです。(必要に応じて、1 行のコードでこの暗黙的な変換を「オフ」にすることができます。これを行う必要がある唯一の理由は、独自の===演算子を持つものをテストしようとして競合が発生した場合です。 ) ScalaTest は他にも多くの暗黙的な変換を定義していますが、それらを使用するには、トレイトを混合するかインポートを実行して、コードに明示的に「招待」する必要があります。授業を延長するときSpecification仕様では、デフォルトで何十もの暗黙的な変換が行われると思います。それが実際にどの程度重要になるかはわかりませんが、人々は独自の暗黙を使用するコードをテストしたいと考えており、テスト フレームワークの暗黙と本番コードの暗黙の間に競合が発生する場合があります。そういうときはスペックよりもScalaTestで回避した方が楽かもしれないと思います。

私が気付いた設計姿勢のもう 1 つの違いは、オペレーターの快適さです。私の目標の 1 つは、ScalaTest を使用する他の誰かのテスト コードを見ているプログラマーが、ScalaTest のドキュメントを調べなくても、その意味を推測できるようにすることでした。私は、ScalaTest のクライアント コードが完全に明白であることを望んでいました。その目標が明らかになった 1 つの方法は、ScalaTest が演算子について非常に保守的であることです。ScalaTest では 5 つの演算子のみを定義します。

  • ===、つまり等しい
  • >、つまりより大きいことを意味します
  • <、 未満
  • >=、以上
  • <=、以下。

それでおしまい。したがって、これらのことはほとんど意味のように見えます。他の誰かのコードにある場合:

result should be <= 7

<=それが何を意味するのかを推測するために、API ドキュメントを実行する必要がないことを願っています。対照的に、spec はオペレーターに対してより自由です。それは間違いではありませんが、違いです。->-演算子はコードをより簡潔にすることができますが、トレードオフは、同僚のテスト コードで 、>>、|、|>、!または^^^(これらはすべて仕様で特別な意味を持ちます) のようなものを見つけたときに、ドキュメントに実行する必要がある場合があること です。

もう 1 つの哲学的な違いは、フィクスチャを共有する必要がある場合に ScalaTest で関数型スタイルを使用することを少しだけ簡単にしようと試みていることです。一方、Specs はデフォルトで、JUnit によって普及した vars を再割り当てするsetUpandアプローチの伝統を継承しています。tearDown各テストの前に。ただし、そのようにテストしたい場合は、ScalaTest でも非常に簡単です。BeforeAndAfter特性を混ぜるだけです。

ScalaTest の詳細については、2009 年の Devoxx カンファレンスで私が行った「Get Higher with ScalaTest」のプレゼンテーションをこちらでご覧ください。

http://parleys.com/play/514892260364bc17fc56bde3/chapter0/about

于 2010-02-26T19:26:31.790 に答える
49

主な違いは次のとおりです (主に仕様の観点から :-) ):

  • ScalaTest は、仕様よりも多くの「テスト スタイル」を提供します (クイック スタートページの各箇条書きにアクセスして、各スタイルの詳細を確認できます)。

  • ScalaTest と spec には異なるマッチャーのセットがあります。ScalaTest についてはこちらで、仕様についてはこちらで比較できます。その点では、スペックには、仕様を作成するときに気に入るかもしれない多くの小さな機能があります。xml マッチャー、マッチャー構成 (マッチャーを変換して再利用する簡単な方法)、正確な失敗、長い文字列の詳細な違いなどです。 .

  • Mockito の仕様では、優れた BDD サポートが提供されています: Mockito

  • specs にはDataTablesがあり、テーブルの並べ替えで多くの小さな例をグループ化できます (演算子がテーブルの区切り記号として使用されていることに耐えられる場合)

  • 仕様では、 libidum としてネストされ、すべてのレベルで自動的にクリーンアップされる例を定義できます

これは確かに非常に部分的で偏った比較であり、他にも多くの違いが存在します (そして、ライブラリはまだ進化しています...)。

結局のところ、それはあなたのテスト/指定スタイルに本当に依存していると思います。単純な場合 (単純な仕様構造、セットアップ、期待など)、両方のライブラリは非常に似ているように見えます。それ以外の場合、どちらも物事をどのように行うべきかについてそれぞれの見解を持っています。この最後の例として、タグ付けを見ることができます: in ScalaTestおよびspecs。

これが役立つことを願っています。

于 2010-02-10T14:16:28.350 に答える
5

私の知る限り、いくつかの高度に専門化された機能を除けば、それはスタイルに応じた個人的な好みに帰着します。

于 2010-02-08T16:06:37.270 に答える
2

IDEのサポートは別のポイントかもしれません

JUnit を介して Specs を Eclipse で動作させようとしてきましたが、公式の解決策は少し「ハッキー」であることがわかりました。仕様のセットアップ: http://code.google.com/p/specs/wiki/RunningSpecs#Run_your_specification_with_JUnit4_in_Eclipse

ScalaTest の (これも JUnit を介した) との統合は、ハックが少ないようです。それでも、JUnit や Java ほどうまく機能するものはありません。

ScalaTest のセットアップ: http://groups.google.com/group/scalatest-users/web/running-scalatest-from-eclipse

于 2010-09-16T22:00:14.920 に答える
0

1 つの決定要因がコンパイル時間である場合、scalatest のパフォーマンスが向上するようです。

現在、プロジェクトで specs2 を使用していますが、テストでのコンパイル時間が遅いという問題があります。scalatest への移行に関する POC を終えたばかりで、一部のソースで 2 つのフレームワークを切り替えるだけで、コンパイル時間が約 0.82 倍短縮されることがわかりました。

于 2015-12-15T11:29:58.990 に答える