Segregate add'l long-running and performance tests

- Add TestGroup#LONG_RUNNING to distinguish from #PERFORMANCE, the
   former being tests that simply take a long time vs the latter being
   tests that are actually dependent on certain actions happening within
   a given time window and are thefore CPU-dependent.

Issue: SPR-9984
This commit is contained in:
Chris Beams
2013-01-03 12:14:17 +01:00
parent acd86a1fd7
commit 68e3b7773c
19 changed files with 217 additions and 58 deletions

View File

@@ -1,5 +1,5 @@
/*
* Copyright 2002-2012 the original author or authors.
* Copyright 2002-2013 the original author or authors.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -27,6 +27,8 @@ import org.springframework.core.io.UrlResource;
import org.springframework.core.type.classreading.CachingMetadataReaderFactory;
import org.springframework.core.type.classreading.MetadataReader;
import org.springframework.core.type.classreading.MetadataReaderFactory;
import org.springframework.tests.Assume;
import org.springframework.tests.TestGroup;
/**
* Unit test checking the behaviour of {@link CachingMetadataReaderFactory under load.
@@ -47,6 +49,8 @@ public class CachingMetadataReaderLeakTest {
@Test
public void testSignificantLoad() throws Exception {
Assume.group(TestGroup.LONG_RUNNING);
// the biggest public class in the JDK (>60k)
URL url = getClass().getResource("/java/awt/Component.class");
assertThat(url, notNullValue());

View File

@@ -26,12 +26,23 @@ import java.util.Set;
*
* @see Assume#group(TestGroup)
* @author Phillip Webb
* @author Chris Beams
*/
public enum TestGroup {
/**
* Performance related tests that may take a considerable time to run.
* Tests that take a considerable amount of time to run. Any test lasting longer than
* 500ms should be considered a candidate in order to avoid making the overall test
* suite too slow to run during the normal development cycle.
*/
LONG_RUNNING,
/**
* Performance-related tests that may fail unpredictably based on CPU profile and load.
* Any test using {@link Thread#sleep}, {@link Object#wait}, Spring's
* {@code StopWatch}, etc. should be considered a candidate as their successful
* execution is likely to be based on events occurring within a given time window.
*/
PERFORMANCE;