Javaでのテスト。 スポックフレームワーク

JUnitとTestNGを例として使用した以前の記事では、 テスト駆動開発（TDD）とデータ駆動テスト（DDT）について言及しました。 しかし、積極的に人気を得ている別のアプローチ、 行動駆動型開発（BDD）があります。 これはTDDテクノロジのこのような開発であり、テストは一部のシステムコンポーネントのテストではなく、機能要件として見なされます。 TDDがテストやメソッドなどの概念を使用する場合、BDDの場合は仕様と要件です。 この手法については、すでに以前にhabrで話しました：

• ユニットテストの進化
• 極端なプログラミング、行動駆動型開発およびRSpecに精通している

このアプローチは、JUnitとTestNGの両方を使用して適用できます。 ただし、BDD専用に調整された他のツールがあります。 この記事では、このようなフレームワークについて説明します。 これはSpock Frameworkと呼ばれ、BDDの原理だけでなくGroovyの利点も兼ね備えています。 はい、はい、Groovy。 Groovyが使用されますが、Javaコードのテストにも使用されます。 使用例は、Spring、Grails、Tapestry5です。 面白い？ 次に読み進めてください。

行動駆動開発

それで、それが何であるかを思い出させてください。 例を考えてみましょう。 antパターンで動作するユーティリティはありますか（これらはファイルを取得するためのものです）。 -任意の1文字のみ、*-任意の数の任意の文字、**-任意のパス。 次のようになります。

public abstract class PathUtils { public static boolean matchAntPath(final String path, final String pattern) { // ... } public static boolean matchAntPattern(final String path, final String pattern) { // ... } } 

どちらのメソッドも、渡された文字列がパターンに一致するかどうかをチェックしますが、 matchAntPatternメソッドはパスを考慮せずにローカルパターンのみを考慮し、 matchAntPathは完全なパスを取ります。 TDDの原則に従って、入力データのセットと期待される結果のセットを使用して、各メソッドのテストが作成されます。

 public class TestPathUtils extends Assert { @Test(dataProvider = "matchAntPatternData") public void testMatchAntPattern(final String pattern, final String text, final boolean expected) { final boolean actual = PathUtils.matchAntPattern(text, pattern); assertEquals(actual, expected); } @Test(dataProvider = "matchAntPathData") public void testMatchAntPath(final String pattern, final String path, final boolean expected) { final boolean actual = PathUtils.matchAntPath(path, pattern); assertEquals(actual, expected); } } 

おそらく、例外をスローする必要がある場合、誤ったパラメーターのテストもここに追加されます。 それでは、BDDの観点から見てみましょう。
テストは単なるテストではなく、仕様であり、メソッドではなく要件で構成されています。 PathUtilsの要件を強調表示します。

• シンボル？ テンプレート内のチェック対象の文字列内の任意の文字と同等である必要があります
• シンボル？ テンプレートでは、チェック対象の文字列の1文字と1文字のみに相当する必要があります
• パターン内の*文字は、チェック対象の文字列内の任意の文字と同等でなければなりません
• パターンの*文字は、チェックする文字列の任意の数の文字と同等である必要があります
• チェックするテンプレートと文字列の値はnullであってはなりません

さらに、各要件には独自の検証スクリプトがあり、通常は、そのときに指定された用語が使用されます。 与えられた-スクリプトの開始の設定、いつ-理由、そして-スクリプトの条件。 例：

 Given: PathUtils --- When: matchAntPattern(null, "some string") --- Then: NullPointerException should be thrown 

したがって、テストは次のようになります。

 public class PathUtilsSpec extends Assert { @Test public void question_character_should_mean_any_character() { assertTrue(PathUtils.matchAntPattern("abb", "a?b")); assertTrue(PathUtils.matchAntPattern("a1b", "a?b")); assertTrue(PathUtils.matchAntPattern("a@b", "a?b")); assertTrue(PathUtils.matchAntPath("abb", "a?b")); assertTrue(PathUtils.matchAntPath("a1b", "a?b")); assertTrue(PathUtils.matchAntPath("a@b", "a?b")); // ... } @Test public void question_character_should_mean_only_one_character() { assertFalse(PathUtils.matchAntPattern("ab", "a?b")); assertFalse(PathUtils.matchAntPattern("aabb", "a?b")); assertFalse(PathUtils.matchAntPath("ab", "a?b")); assertFalse(PathUtils.matchAntPath("aabb", "a?b")); // ... } @Test public void asterisk_character_should_mean_any_character() { assertTrue(PathUtils.matchAntPattern("abb", "a*b")); assertTrue(PathUtils.matchAntPattern("a1b", "a*b")); assertTrue(PathUtils.matchAntPattern("a@b", "a*b")); assertTrue(PathUtils.matchAntPath("abb", "a*b")); assertTrue(PathUtils.matchAntPath("a1b", "a*b")); assertTrue(PathUtils.matchAntPath("a@b", "a*b")); // ... } @Test public void asterisk_character_should_mean_any_number_of_characters() { assertTrue(PathUtils.matchAntPattern("ab", "a*b")); assertTrue(PathUtils.matchAntPattern("aabb", "a*b")); assertTrue(PathUtils.matchAntPath("ab", "a*b")); assertTrue(PathUtils.matchAntPath("aabb", "a*b")); // ... } @Test public void double_asterisk_character_should_mean_any_path() { assertTrue(PathUtils.matchAntPath("aaa/bbb", "aaa/**/bbb")); assertTrue(PathUtils.matchAntPath("aaa/ccc/bbb", "aaa/**/bbb")); assertTrue(PathUtils.matchAntPath("aaa/c/c/c/bbb", "aaa/**/bbb")); // ... } } 

次に、Spock Frameworkについて詳しく説明します。

主な機能

先ほど言ったように、スクリプトはGroovyで書かれています。 それは良いですか悪いですか？ Groovyは初心者でも15分で読むことができます-簡単な概要です。

仕様はspock.lang.Specificationから継承する必要があります。 フィールド、フィクスチャメソッド、機能スクリプト、ヘルパーメソッドを含めることができます。

デフォルトでは、フィールドはスクリプト間で共有されません。 あるシナリオからのフィールドの変更は、別のシナリオからは見えません。 共有するには、 @Sharedを使用して注釈を付けることができます。

インストール方法は次のとおりです。

• setup（） -各スクリプトの前に実行される、JUnitの@Beforeの類似物
• cleanup（） -JUnitの@Afterに相当し、各スクリプトの後に実行されます
• setupSpec（） -JUnitの@BeforeClassの類似物。仕様の最初のスクリプトの前に実行されます
• cleanupSpec（） -仕様の最後のスクリプトの後に実行される、JUnitの@AfterClassに類似

他のテストフレームワークと同様に、これらのメソッドは、各スクリプトに同じインストールコードを記述しないようにするために使用されます。

要件シナリオは、仕様の主要部分です。 ここでコンポーネントの動作が説明されます。 文字列リテラルを使用して呼び出すのが慣習であり、任意の文字を使用できます。主なことは、この名前がこのスクリプトの機能をできるだけ明確に説明することです。 たとえば、この場合：

 class PathUtilsSpec extends Specification { def "? character should mean any character"() { // ... } def "? character should mean only one character"() { // ... } def "* character should mean any character"() { // ... } def "* character should mean any number of characters"() { // ... } def "** character should mean any path"() { // ... } } 

各シナリオはブロックで構成されており、ラベルで示されています。

• setupはsetup（）インストール方法と同じで、特定のシナリオにのみ適用されます。 残りのブロックの前に配置する必要があり、繰り返さないでください。 セットアップラベルが欠落している可能性があります。setupの代わりに指定することもできます 。これは、読みやすくするために行われます（特定の場合）
• cleanupはcleanup（）メソッドと同じで、特定のスクリプトにのみ適用されます。 whereブロック（存在する場合）の前のスクリプトの最後にある必要があり、繰り返さないでください
• when-thenは実行の理由と条件です。 when部分では、変数が通常宣言され、必要なアクションが実行され、その部分でいくつかの条件がチェックされます。 これには、条件のチェック、例外のスローのチェック、またはモックオブジェクトで実行されるメソッドの待機があります。 このブロックは繰り返すことができますが、フレームワークの作成者は関与しないことを推奨しています。適切なスクリプトには、1〜5個のこのようなブロックを含める必要があります
• expectは、アクションと検証が同じ式に含まれる簡略化されたwhen-thenブロックです
• テスト用のデータセットを作成するために設計されたTestNGの@DataProviderの類似物

さて、すべての詳細について。 別の例を考えてみましょう。 ファイルを検索するために設計されたPathSearcherは 、ファイルのフィルターとしてantパターンを使用します。

 public class PathSearcher { public PathSearcher(final String path) {...} public PathSearcher include(final String... patterns) {...} public PathSearcher exclude(final String... patterns) {...} public Set<String> search() {...} } 

「ファイルシステム上のファイルを検索する必要があります」という要件を記述します。

 class PathSearcherSpec extends Specification { def "it should search files under the file system"() { given: def searcher = PathSearcher.create(inClasspath("test1")) when: def results = searcher.search(); then: results.containsAll(["1.txt", "2.txt"]); results.size() == 2 } private String inClasspath(path) { return ClassLoader.getSystemResource(path).toExternalForm() } } 

そのため、 クラスパスからtest1フォルダーを検索する検索エンジン、検索、実行条件を確認する-検索エンジンはファイルを見つける必要があります。 inClasspathは、 classpathからファイルの絶対パスを返すヘルパーメソッドです。

PathUtilsの別の例「チェックするテンプレートと文字列の値はnullにできません」

 class PathUtilsSpec extends Specification { def "null parameter values are not allowed"() { when: PathUtils.matchAntPattern(null, "some string") then: thrown(NullPointerException) when: PathUtils.matchAntPattern("some string", null) then: thrown(NullPointerException) when: PathUtils.matchAntPath(null, "some string") then: thrown(NullPointerException) when: PathUtils.matchAntPath("some string", null) then: thrown(NullPointerException) } } 

ここに、 スローされた（...）メソッドがあります。これは、指定された例外の予想です。notThrown（...）メソッドとnoExceptionThrown（）もあります。 それらは、特定の例外がスローされることを確認するためのものです。 また、その部分では、モックオブジェクトのいくつかのメソッドへの期待があるかもしれませんが、それらについては後で詳しく説明します。 別の例：

 class PathUtilsSpec extends Specification { def "? character should mean any character"() { expect: PathUtils.matchAntPattern("abb", "a?b") PathUtils.matchAntPattern("a1b", "a?b") PathUtils.matchAntPattern("a@b", "a?b") PathUtils.matchAntPath("abb", "a?b") PathUtils.matchAntPath("a1b", "a?b") PathUtils.matchAntPath("a@b", "a?b") } } 

この例からわかるように、 いつ 、そしてその後の両方の部分を1つの条件に結合できる場合、 expectブロックを使用する方が便利です。 このシナリオは、 whereブロックを使用してパラメーター化可能にすることで改善できます。

 class PathUtilsSpec extends Specification { def "? character should mean any character"() { expect: PathUtils.matchAntPattern(text, pattern) PathUtils.matchAntPath(text, pattern) where: pattern | text "ab?" | "abc" "ab?" | "ab1" "ab?" | "ab@" "a?b" | "abb" "a?b" | "a1b" "a?b" | "a@b" "?ab" | "aab" "?ab" | "1ab" "?ab" | "@ab" } } 

または：

 class PathUtilsSpec extends Specification { def "? character should mean any character"() { expect: PathUtils.matchAntPattern(text, pattern) PathUtils.matchAntPath(text, pattern) where: pattern << ["ab?", "ab?", "ab?", "a?b", "a?b", "a?b", "?ab", "?ab", "?ab"] text << ["abc", "ab1", "ab@", "abb", "a1b", "a@b", "aab", "1ab", "@ab"] } } 

または：

 class PathUtilsSpec extends Specification { def "? character should mean any character"() { expect: PathUtils.matchAntPattern(text, pattern) PathUtils.matchAntPath(text, pattern) where: [pattern, text] << [ ["ab?", "abc"], ["ab?", "ab1"], ["ab?", "ab@"], ["a?b", "abb"], ["a?b", "a1b"], ["a?b", "a@b"], ["?ab", "aab"], ["?ab", "1ab"], ["?ab", "@ab"] ] } } 

またはこのように：

 class PathUtilsSpec extends Specification { def "? character should mean any character"() { expect: PathUtils.matchAntPattern(text, pattern) PathUtils.matchAntPath(text, pattern) where: [pattern, text] = sql.execute("select pattern, text from path_utils_test") } } 

例からすべてが明らかであると思うので、私はこれに焦点を合わせません。 whereブロックでは、 @Sharedとしてマークされていないフィールドは使用できないことに注意してください 。

相互作用

とりわけ、フレームワークを使用すると、追加の依存関係なしにモックオブジェクトを操作できます。 インターフェイスおよび非最終クラスのmokaを作成できます。 作成は次のようになります。

  def dao1 = Mock(UserDAO) UserDAO dao2 = Mock() 

このようなオブジェクト自体の戻り値またはメソッドをオーバーライドできます。 著者はこの相互作用を呼び出します。

  dao1.findAll() >> [ new User(name: "test1", description: "Test User"), new User(name: "test2", description: "Test User"), new User(name: "test3", description: "Test User") ] dao2.findAll() >> { throw new UnsupportedOperationException() } 

相互作用は、ローカル（ thenブロックで定義）およびグローバル（他の場所で定義）です。 ローカルはそのブロックでのみ使用でき、グローバルは定義のポイントからどこでも使用できます。 また、ローカルインタラクションの場合、それらのパワーを指定できます。これは、メソッド呼び出しの予想数です。

 class UserCacheSpec extends Specification { def users = [ new User(name: "test1", description: "Test User"), new User(name: "test2", description: "Test User"), new User(name: "test3", description: "Test User") ] def "dao should be used only once for all user searches until invalidated"() { setup: def dao = Mock(UserDAO) def cache = new UserCacheImpl(dao) when: cache.getUser("test1") cache.getUser("test2") cache.getUser("test3") cache.getUser("test4") then: 1 * dao.findAll() >> users } } 

この例では、 UserDAO用のモックと、このモック（セットアップブロック）を使用して実際のUserCacheオブジェクトを作成します。 次に、名前（ when- block）で複数のユーザーを検索し、最後に、準備された結果を返すfindAllメソッドが1回だけ呼び出されることを確認します。
相互作用を説明するには、テンプレートを使用できます。

  1 * dao.findAll() >> users (1..4) * dao.findAll() >> users (2.._) * dao.findAll() >> users (_..4) * dao.findAll() >> users _.findAll() >> users dao./find.*/(_) >> users 

詳細はこちら 。

追加機能

ご覧のとおり、フレームワークにはすでに多くの機能があります。 しかし、他のフレームワークと同様に、機能を拡張する可能性があります。 例は組み込みの拡張機能です。

• @Timeout -JUnitの@Testの タイムアウト属性に相当する、スクリプトの最大タイムアウトを設定します
• @Ignore -JUnitの@Ignoreに相当するスクリプトを無効にします
• @IgnoreRest-注釈付き以外のすべてのスクリプトを無効にします。1つのテストのみをチェックする必要がある場合に役立ちます
• @FailsWith-予想される例外を設定します。これは、JUnitの@Testで 予想される属性の類似物です。
• @Unroll-パラメーター化されたスクリプトは、反復ごとに個別のスクリプトとして指定する必要があることを示します。ここでは、要件名のテンプレートも指定できます。デフォルトでは、 「＃featureName [#iterationCount]」です。

 class InternalExtensionsSpec extends Specification { @FailsWith(NumberFormatException) @Unroll("#featureName (#data)") def "integer parse method should throw exception for wrong parameters"() { Integer.parseInt(data) where: data << ["Hello, World!!!", "0x245", "1798237199878129387197238"] } @Ignore @Timeout(3) def "temporary disabled feature"() { setup: sleep(20000) } } 

他のフレームワークとの統合は、個別のモジュールで行われます。

• Spring-@ContextConfiguration（locations = "application_context_xml"）を使用して仕様に注釈が付けられ、 @ Autowiredを使用してフィールドに依存関係を注入できます。
  
  

   @ContextConfiguration(locations = "context.xml") class SpringIntegrationSpec extends Specification { @Autowired String testSymbol def "test-symbol should be spring"() { expect: testSymbol == "spring" } } 

  
  
• Guice-@UseModules（guice_module_class）を使用して仕様に注釈が付けられ、 @ Injectを使用してフィールドに依存関係を注入できます。
  
  

   public class GuiceModule extends AbstractModule { @Override protected void configure() { bind(String.class).annotatedWith(Names.named("test-symbol")).toInstance("guice"); } } @UseModules(GuiceModule) class GuiceIntegrationSpec extends Specification { @Inject @Named("test-symbol") String testSymbol def "test-symbol should be guice"() { expect: testSymbol == "guice" } } 

  
  
• タペストリー-仕様には@SubModule（tapestry_module_class）を使用して注釈が付けられ、 @ Inject注釈を使用して依存関係をフィールドに挿入できます。
  
  

   public class TapestryModule { public void contributeApplicationDefaults(final MappedConfiguration<String, String> configuration) { configuration.add("test-symbol", "tapestry"); } } @SubModule(TapestryModule) class TapestryIntegrationSpec extends Specification { @Inject @Symbol("test-symbol") String testSymbol def "test-symbol should be tapestry"() { expect: testSymbol == "tapestry" } } 

  
  

最も重要なことは、独自の機能が必要な場合は、独自の拡張機能を追加できることです。 機能を拡張するための主要なクラス：

• IMethodInterceptorは、IMethodInvocationが仕様メソッドをプロキシするための最初のものであり、メソッドを呼び出す前後にコードを追加できます。作業を簡素化するために、 AbstractMethodInterceptorクラスを使用できます。 2番目のメソッドは最初のメソッドから使​​用でき、元の（プロキシ化された）メソッドで動作します
• IGlobalExtension-仕様メタデータ（ SpecInfo ）を操作できます。ここでは、仕様コンポーネント（フィールド、インストール方法、要件スクリプト）のメタデータを表示し、独自のインターセプターを追加できます。
• IAnnotationDrivenExtension-前のものと同じですが、タスクを単純化するだけです。拡張機能が特定の注釈に関連付けられている場合、 AbstractAnnotationDrivenExtensionクラスを使用して作業を単純化できます。

独自の拡張機能を作成するには、 IMethodInterceptorが仕様コンポーネントに追加される可能性が高いIGlobalExtensionまたはIAnnotationDrivenExtension下位クラスを作成する必要があります。 最後に、 spi拡張機能をMETA-INF / services / org.spockframework.runtime.extension.IGlobalExtensionに追加します 、 IAnnotationDrivenExtensionの場合 、注釈は@ExtensionAnnotation（extension_class）を使用して注釈を付ける必要があります。
指定された回数だけスクリプトを実行する拡張機能の例：

 @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.METHOD, ElementType.TYPE}) @ExtensionAnnotation(RepeatExtension.class) public @interface Repeat { int value() default 1; } public class RepeatExtension extends AbstractAnnotationDrivenExtension<Repeat> { @Override public void visitFeatureAnnotation(Repeat annotation, FeatureInfo feature) { feature.addInterceptor(new RepeatInterceptor(annotation.value())); } } public class RepeatInterceptor extends AbstractMethodInterceptor{ private final int count; public RepeatInterceptor(int count) { this.count = count; } @Override public void interceptFeatureExecution(IMethodInvocation invocation) throws Throwable { for (int i = 0; i < count; i++) { invocation.proceed(); } } } 

 class CustomExtensionsSpec extends Specification { @Repeat(10) def "custom extension"() { expect: Integer.parseInt("123") == 123 } } 

テストを実行する

SpockテストはJUnit Launcher（ Sputnik ）を使用して実行されるため、さまざまなIDEで正常に動作します（著者が言うように、私はアイデアの下でのみ確認しました）。 ant、maven、gradleからのテストの起動を構成することもできます。 設定に関するすべての必要な情報は、 ここにあります 。
それを自分用に追加します。Mavenの下で少し設定を確認しました。 著者によって提案されたmaven3の下で動作しませんでした。 私の設定オプションは次のとおりです。

 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>com.example</groupId> <artifactId>testing-example</artifactId> <version>1.0-SNAPSHOT</version> </parent> <groupId>com.example</groupId> <artifactId>testing-spock</artifactId> <version>1.0-SNAPSHOT</version> <packaging>jar</packaging> <name>Testing Spock Framework Example</name> <description> This is an example application that demonstrates Spock Framework usage. </description> <dependencies> <dependency> <groupId>org.codehaus.groovy</groupId> <artifactId>groovy-all</artifactId> <version>${groovy-version}</version> <scope>test</scope> </dependency> <dependency> <groupId>org.spockframework</groupId> <artifactId>spock-core</artifactId> <version>${spock.version}</version> <scope>test</scope> </dependency> </dependencies> <build> <testResources> <testResource> <directory>src/test/groovy</directory> </testResource> <testResource> <directory>src/test/resources</directory> </testResource> </testResources> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <configuration> <includes> <include>**/*Spec.groovy</include> </includes> </configuration> </plugin> <plugin> <groupId>org.codehaus.gmaven</groupId> <artifactId>gmaven-plugin</artifactId> <version>${gmaven-version}</version> <configuration> <providerSelection>${gmaven-provider}</providerSelection> </configuration> <executions> <execution> <goals> <goal>testCompile</goal> </goals> </execution> </executions> <dependencies> <dependency> <groupId>org.codehaus.groovy</groupId> <artifactId>groovy-all</artifactId> <version>${groovy-version}</version> </dependency> </dependencies> </plugin> </plugins> </build> <properties> <groovy-version>1.7.10</groovy-version> <gmaven-version>1.3</gmaven-version> <gmaven-provider>1.7</gmaven-provider> <spock.version>0.5-groovy-1.7</spock.version> </properties> </project> 

おわりに

このすばらしいフレームワークに最近出会ったという事実にもかかわらず、私はそれを実際に使用した経験がありません。それは能力において劣らず、いくつかの面で他のフレームワークを凌evenしていると自信を持って言えます。 私はGroovyでテストを書くのが本当に好きで、BDDにガイドされたテストを書くのが好きでした。 したがって、試してみることをお勧めします。

例はここにあります 。

文学

• 行動駆動開発
• 行動ドライバーの開発
• スポックの基本