SpecsとScalaTestはどちらもユーザーが満足できる優れたツールですが、いくつかの点で異なります。おそらくScalaのメインのテストツールとして1つを選択する必要がありますが、両方を使用できるため、もう1つをあきらめる必要はありません。たとえば、ScalaTestのFeatureSpec構文と仕様のMockito構文が好きな場合は、両方のjarファイルをクラスパスに入れて、両方を同時に使用できます。ここで、仕様とScalaTestの間で気付いた主な設計哲学の違いをキャプチャしてみましょう。
おそらく、ツール間の主な哲学的な違いは、仕様は行動駆動型開発（BDD）用に設計されているのに対し、ScalaTestはより一般的なものです。ScalaTestは、BDDを含むテストクラスで好みの動作を取得するために組み合わせることができる特性を提供します。また、別のものが必要な場合は、独自の動作を簡単に定義することもできます。
ScalaTestそのを通じてサポートBDD Spec、FeatureSpec、WordSpec、FlatSpec、およびGivenWhenThen特性、およびまたあなたが素敵なマッチャー構文を見るには混在させることができるという特徴を持っています。"should"が好きな場合は、ShouldMatchersでミックスします。あなたが「マスト」が好きなら、あなたは混ぜますMustMatchers。しかし、BDDが好きでマッチャー構文が嫌いな場合は、マッチャートレイトを混ぜずに、ScalaTestのSpecトレイトの1つだけを使用できます。Specsには拡張するSpecificationクラスがあり、マッチャー式では「必須」という単語を使用する必要があります。ここで明らかな大きな哲学的な違いは、ScalaTestがより多くの選択肢を提供することです。この選択したスペースをナビゲートしやすくするために、ここに決定木を示します。
http://www.scalatest.org/quick_start
マッチャー構文は、ScalaTestと仕様の間でも異なります。ScalaTestで、演算子表記でどこまで行けるか試してみたところ、単語の間にスペースがあり、英語の文と非常によく似たマッチャー式ができあがりました。Specs Matcher構文は、キャメルケースと一緒に単語を実行します。
SpecsにはScalaTestよりも多くのマッチャーがあり、それは設計の考え方の違いを反映していると思います。私は実際に私が構築してリリースを検討したマッチャー構文のおそらく2/3をカットしました。今後のリリースでさらにマッチャーを追加する予定ですが、ユーザーが何かを追加する前に、ユーザーが実際に何かを望んでいることを確認したかったのです。ただし、ScalaTestのマッチャーには動的プロパティマッチャー構文が含まれており、そのスラックの一部を占めています。たとえば、Specsでは次のように記述できますjava.io.File。
file must beDirectory
これによりが呼び出され、isDirectoryそれがtrueであることを確認します。java.io.Files現在、ScalaTestには特別なマッチャーはありませんが、ScalaTestでは、次のような動的チェックを使用できます。
file must be a ('directory)
after beでシンボルを渡すと、リフレクションを使用して（この場合は）というメソッドまたはフィールド、directoryあるいはというメソッドが検索されisDirectoryます。を定義することにより、これを静的にする方法もありBePropertyMatcherます（通常は2行または3行のコードしか必要ありません）。したがって、基本的にScalaTestでは、より少ないAPIでより多くの機能を提供するようにしています。
仕様とScalaTestの間のもう1つの一般的な設計姿勢の違いには、暗黙的な変換が含まれます。デフォルトでは、ScalaTestを使用するときに暗黙的な変換が1つだけ取得さ===れます。これは、演算子をすべてに適用する変換です。（必要に応じて、この暗黙の変換を1行のコードで「オフ」にすることができます。これを行う必要がある唯一の理由は、独自の===演算子を持つ何かをテストしようとしていて、競合が発生した場合です。 ）ScalaTestは他の多くの暗黙の変換を定義しますが、それらを使用するには、特性を混合するかインポートを行うことによって、それらをコードに明示的に「招待」する必要があります。クラスを拡張するときSpecification仕様では、デフォルトで数十の暗黙的な変換を取得できると思います。それが実際にどれほど重要かはわかりませんが、独自のインプリシットを使用するコードをテストしたいと思う人もいると思います。テストフレームワークのインプリシットとプロダクションコードのインプリシットの間で競合が発生する場合があります。そうなると、仕様よりもScalaTestで問題を回避する方が簡単かもしれません。
私が気づいたデザイン態度のもう1つの違いは、オペレーターの快適さです。私の目標の1つは、ScalaTestを使用する他の誰かのテストコードを見ているプログラマーが、ScalaTestのドキュメントを調べなくても、その意味を推測できることでした。ScalaTestのクライアントコードを一目でわかるようにしたかったのです。目標が明らかになった1つの方法は、ScalaTestが演算子に関して非常に保守的であることです。ScalaTestでは5つの演算子のみを定義しています。
===、つまり等しい>、つまり<、 未満>=、以上<=、以下。
それでおしまい。したがって、これらはほとんど意味のように見えます。他の誰かのコードで見た場合：
result should be <= 7
私の希望は、それが何を<=意味するのかを推測するために、APIドキュメントを実行する必要がないことです。対照的に、仕様は演算子を使用するとはるかに自由になります。何も問題はありませんが、違いです。オペレータは、コードより簡潔を作ることができますが、トレードオフは、あなたがのようなものを見つけたときにドキュメントを実行する必要がありあり ->-、>>、|、|>、!、または^^^あなたの同僚のテストコードに（すべての仕様で特別な意味を持っています）。
他の哲学的な違いの1つは、ScalaTestでフィクスチャを共有する必要があるときに関数スタイルを使用することを少しだけ簡単にしようとしているのに対し、Specsはデフォルトで、JUnitで一般化されている、setUpおよびtearDownvarsを再割り当てするアプローチの伝統を継承しています各テストの前。ただし、その方法でテストしたい場合は、ScalaTestでも非常に簡単です。BeforeAndAfter特性を混ぜるだけです。
ScalaTestの詳細については、2009 Devoxxカンファレンスで私が行った "Get Higher with ScalaTest"プレゼンテーションをご覧ください。
http://parleys.com/play/514892260364bc17fc56bde3/chapter0/about