3

Specs2 は、Acceptance 仕様 (必要に応じて Unit 仕様も) を扱う際に機能的なスタイルを促進します。

古いスタイル (変更可能なスタイル) を使用するリスクは、仕様Specs2 の哲学で言及されており、潜在的な望ましくない副作用に関係しています。

知っておくべき重要事項は次のとおりです。

副作用は仕様フラグメントを構築するためにのみ使用され、変数を変更することによって、失敗が発生するとすぐに例の実行を短絡するためにも使用されます (例外をスローすることによって)。例の本体でフラグメントをビルドしたり、同じ仕様を並行して実行したりすると、空が落ちるはずです。「コンテキスト」管理は、ケース クラスまたはトレイトで行われます (org.specs2.examples.MutableSpec を参照)。

同じ仕様を 2 回以上同時に実行したとしても、各仕様は他の仕様 (分離されたクラスのインスタンス) とは異なるため、同じ仕様を同時に実行する方法がわかりません。

確かに、specFragments（可変変数）：

protected[mutable] var specFragments: Fragments = new Fragments()

（スカラの意味で=>シングルトン）または他の共有のものではなく、a trait呼び出されたで宣言されているため、各のインスタンスのローカル変数です。FragmentBuilderobjectspecFragmentsSpecification

では、どのようなシナリオで同時実行メカニズムが危険にさらされる可能性があるのでしょうか?

Specs2 の機能的スタイルの利点を証明する真のシナリオ (愚かではない) を実際には理解していません。

4

1 に答える 1

5

変更可能な仕様に関する問題は、仕様の実行時ではなく、仕様の構築時にのみ見られます。変更可能な仕様を構築する場合、予期しない副作用が発生しやすい

import org.specs2._

val spec = new mutable.Specification {
  "example" >> ok
}
import spec._

def addTitle {
  // WHOOPS, forgot to remove this line!
  // test, add also an example
  "this is only for testing" >> ok

  "new title".title
}
addTitle

出力は次のとおりです。

new title

+ example
+ this is only for testing

Total for specification new title
Finished in 0 ms
2 examples, 0 failure, 0 error

そうです、ガイドの強調表示された文 (「同じ仕様を同時に実行する」) はあいまいです。複数のスレッドが同じ仕様オブジェクトを構築している場合、仕様自体の構築は安全ではない可能性がありますが、それらがそれを実行している場合はそうではありません (その文ではプロセス全体が「実行」と呼ばれています)。

あなたの他の質問は、「機能的なスタイル」の利点は何ですか? ユーザーの観点から見た主な利点は、すべてのテキストを最初に記述し、すべてのコードを別の場所に配置するという仕様書の別のスタイルであることです。

結論として、仕様の変更可能なスタイルが気に入った場合は恐れないでください。

于 2013-01-23T21:54:37.037 に答える