すべてが個別に機能するJUnitテストがたくさんあります。それぞれが真のスタンドアロンユニットテストであり、テスト対象の単一クラスです。コンテキストは必要ありません。 Eclipseで、またはmaven/surefire-pluginを介して、それらをすべて個別に実行することも、すべて一緒に実行することもできます。
その後、Spring Contextなどを活用し、SpringJUnit4ClassRunnerを使用する新しい統合テストを追加しました。このテストをスイートに追加するとすぐに、このクラスが失敗した後にテストケースが実行されます。
@RunWith(SpringJUnit4ClassRunner.class)
@SpringApplicationConfiguration(classes = IntegrationTestConfiguration.class)
@DirtiesContext(classMode=ClassMode.AFTER_EACH_TEST_METHOD)
@ActiveProfiles("test")
public class ImportServiceIntegrationTest {
...
}
これに大きな価値があるかどうかはわかりませんが、ここにも構成クラスを投稿しています。
@EnableAutoConfiguration(exclude = { WebMvcAutoConfiguration.class,
DispatcherServletAutoConfiguration.class,
EmbeddedServletContainerAutoConfiguration.class,
WebSocketAutoConfiguration.class })
@ComponentScan(basePackages = "com.rtc.synchronize",
excludeFilters = @ComponentScan.Filter(type = FilterType.REGEX, pattern="com\\.rtc\\.synchronize\\.config\\.AppConfig"))
@EnableJpaRepositories("com.util.veracode.rtc.synchronize")
@EntityScan("com.util.veracode.rtc.synchronize")
public class IntegrationTestConfiguration {
}
私の実際の@Configuration
クラスが役立つ場合は、それらも投稿できますが、簡潔にするために、それらを避けました(それらがどれほど役立つかは完全にはわかりません)。
テストクラスが終了した後、JVMに何か(静的データ)が維持されているのではないかと思います。
次の構成でSpringCacheアノテーションを使用しています。
@Configuration
@EnableCaching(mode=AdviceMode.ASPECTJ)
public class CacheConfig extends CachingConfigurerSupport{
/**
* EhCache configuration. Used to minimize calls to Veracode
*
* @return
*/
@Bean(destroyMethod="shutdown")
public net.sf.ehcache.CacheManager ehCacheManager() {
...
...
}
...
}
統合テストクラスが終了するとすぐに、後続のテストで次のエラーがスローされます。
Java.lang.IllegalStateException: The workItems Cache is not alive (STATUS_SHUTDOWN)
at net.sf.ehcache.Cache$CacheStatus.checkAlive(Cache.Java:4097)
at net.sf.ehcache.Cache.checkStatus(Cache.Java:2788)
at net.sf.ehcache.Cache.get(Cache.Java:1744)
at org.springframework.cache.ehcache.EhCacheCache.get(EhCacheCache.Java:65)
at org.springframework.cache.interceptor.AbstractCacheInvoker.doGet(AbstractCacheInvoker.Java:68)
at org.springframework.cache.interceptor.CacheAspectSupport.findInCaches(CacheAspectSupport.Java:461)
at org.springframework.cache.interceptor.CacheAspectSupport.findCachedItem(CacheAspectSupport.Java:432)
at org.springframework.cache.interceptor.CacheAspectSupport.execute(CacheAspectSupport.Java:333)
at org.springframework.cache.interceptor.CacheAspectSupport.execute(CacheAspectSupport.Java:299)
at org.springframework.cache.aspectj.AbstractCacheAspect.ajc$around$org_springframework_cache_aspectj_AbstractCacheAspect$1$2bc714b5(AbstractCacheAspect.aj:74)
at com.synchronize.repository.rtc.WorkItemRepositoryImpl.findById(WorkItemRepositoryImpl.Java:192)
at com.synchronize.repository.rtc.WorkItemRepositoryImpl.findById(WorkItemRepositoryImpl.Java:192)
at com.synchronize.repository.rtc.WorkItemRepositoryImpl.getState(WorkItemRepositoryImpl.Java:179)
at com.synchronize.repository.rtc.WorkItemRepositoryImplTest.testGetState(WorkItemRepositoryImplTest.Java:178)
したがって、Springが完了後に何かをクリーンアップしていないことは私にはかなり明白です(私の後続のクラスはSpringコンテキストをロードしません-それは単純なVanilla Junitテストです!)。
Surefire-plugin定義に<resueForks>false</reuseForks>
を追加すると、すべてのテストに合格しますが、その解決策/回避策に満足していません。ビルドが遅くなり、Eclipseでは尊重されません。つまり、プロジェクト全体に対してJUnitテストランナーを1回のショットで実行するだけで、失敗することはありません。
テストケースが完了したら、SpringがJVMから自動的にクリアされるようにするために、何か特別なことをする必要がありますか?統合テスト後にSpring構成がぶら下がっているのはなぜですか?
私のテストスイートで、一部のAspectJベースの実装には、いくつかのSpring Beanを参照する静的フィールドがあり、プロファイルまたは完全なSpringテストコンテキストが変更されても、この参照は更新されないことに気付きました(Spring-Securityでこれを観察しましたが、おそらくあります@Cache
に関する同様の問題)
私の回避策は、異なるディレクトリ(たとえば、src/test/javaSecurity
)で使用されているスプリング構成によってテストケースをグループ化し、名前付けパターンを使用してそれらを分離することです。 -分離されたディレクトリ/ソースフォルダはEclipseに使用されるので、ディレクトリルートフォルダをクリックして、このソースフォルダですべてのテストを実行するようにEclipseに指示できますか。 -ネーミングパターンは、mavenでテストを実行するために使用されます(surefireには、実行されたテストをクラスのネーミングパターンで選択する機能がありますが、ルートフォルダーでは選択しないため)
src/test/Java
、パターン:*Test
-スプリングセキュリティのないスプリング構成のテストが含まれていますsrc/test/javaSecurity
、パターン:*SecurityTest
有効なSpringセキュリティを必要とするSpringテストmaven
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<id>add-security-test-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-test-source</goal>
</goals>
<configuration>
<sources>
<source>${basedir}/src/test/javaSecurity</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.Apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<executions>
<execution>
<id>normal-test</id>
<phase>test</phase>
<goals>
<goal>test</goal>
</goals>
<configuration>
<excludes>
<exclude>**/Abstract*.Java</exclude>
<exclude>**/*SecurityTest.Java</exclude>
</excludes>
<includes>
<include>**/*Test.Java</include>
<include>**/*Tests.Java</include>
</includes>
<reportsDirectory>${project.build.directory}/surefire-reports/normaltest</reportsDirectory>
</configuration>
</execution>
<execution>
<id>security-tests</id>
<phase>test</phase>
<goals>
<goal>test</goal>
</goals>
<configuration>
<excludes>
<exclude>**/Abstract*.Java</exclude>
</excludes>
<includes>
<include>**/*SecurityTest.Java</include>
</includes>
<reportsDirectory>${project.build.directory}/surefire-reports/security-test</reportsDirectory>
</configuration>
</execution>
</executions>
<configuration>
<!-- just needed to prevent some bugs -->
<excludes />
<includes>
<include>nothing</include>
</includes>
<reportsDirectory>${project.build.directory}/surefire-reports/nothing</reportsDirectory>
</configuration>
</plugin>