1. 28 3月, 2019 1 次提交
  2. 23 3月, 2019 1 次提交
  3. 05 7月, 2016 1 次提交
  4. 27 7月, 2015 2 次提交
  5. 26 7月, 2015 1 次提交
    • S
      Support @Rollback on classes & deprecate @TxConfig · 3f8b5128
      Sam Brannen 提交于
      Since Spring Framework 2.5, @Rollback has been supported on test
      methods, with class-level rollback settings configured via
      @TransactionConfiguration; however, allowing @Rollback to be declared
      on test classes with method-level declarations overriding class-level
      declarations would prove more intuitive than having to declare both
      @TransactionConfiguration and @Rollback. Furthermore, the
      transactionManager flag in @TransactionConfiguration was made
      superfluous many years ago with the introduction of support for a
      qualifier in @Transactional.
      
      This commit enables @Rollback to be declared at the class level for
      default rollback semantics within test class hierarchies and deprecates
      @TransactionConfiguration in favor of @Rollback and @Transactional
      qualifiers.
      
      Issue: SPR-13276, SPR-13277
      3f8b5128
  6. 17 5月, 2015 1 次提交
    • S
      Introduce JUnit Rule alternative to SpringJUnit4ClassRunner · d1b1c4f8
      Sam Brannen 提交于
      Since Spring Framework 2.5, support for integrating the Spring
      TestContext Framework (TCF) into JUnit 4 based tests has been provided
      via the SpringJUnit4ClassRunner, but this approach precludes the
      ability for tests to be run with alternative runners like JUnit's
      Parameterized or third-party runners such as the MockitoJUnitRunner.
      
      This commit remedies this situation by introducing @ClassRule and @Rule
      based alternatives to the SpringJUnit4ClassRunner. These rules are
      independent of any Runner and can therefore be combined with
      alternative runners.
      
      Due to the limitations of JUnit's implementation of rules, as of JUnit
      4.12 it is currently impossible to create a single rule that can be
      applied both at the class level and at the method level (with access to
      the test instance). Consequently, this commit introduces the following
      two rules that must be used together.
      
       - SpringClassRule: a JUnit TestRule that provides the class-level
         functionality of the TCF to JUnit-based tests
      
       - SpringMethodRule: a JUnit MethodRule that provides the
         instance-level and method-level functionality of the TCF to
         JUnit-based tests
      
      In addition, this commit also introduces the following new JUnit
      Statements for use with rules:
      
       - RunPrepareTestInstanceCallbacks
      
       - ProfileValueChecker
      
      Issue: SPR-7731
      d1b1c4f8
  7. 21 3月, 2015 2 次提交
    • S
      Add tests that use the new generate-name attribute · 3d2bde71
      Sam Brannen 提交于
      This commit updates the Spr8849Tests test suite to include XML
      configuration that guarantees that a unique database name is always
      automatically generated (via the new 'generate-name' attribute that was
      introduced in SPR-8849) while reusing the same bean name (i.e.,
      'dataSource').
      
      Issue: SPR-8849
      3d2bde71
    • S
      Refactor tests to use the new database-name attribute · ab771dfd
      Sam Brannen 提交于
      This commit refactors the XML configuration used by the tests in the
      Spr8849Tests test suite so that a unique database name is always
      generated (via the new 'database-name' attribute that was introduced in
      SPR-12835) while reusing the same bean name (i.e., 'dataSource').
      
      This is a much more robust alternative to the previous work-around
      since the name of the DataSource does not randomly change across
      application contexts, thus allowing proper autowiring by name and bean
      referencing within XML configuration.
      
      Issue: SPR-8849
      ab771dfd
  8. 01 3月, 2015 1 次提交
    • S
      Support XML config fully in web integration tests · 2ba1151b
      Sam Brannen 提交于
      Prior to this commit, it was impossible to use all features of XML
      configuration (e.g., the <qualifier> tag) in web-based integration
      tests (loaded using @WebAppConfiguration, @ContextConfiguration, etc.)
      if the Groovy library was on the classpath. The reason is that the
      GroovyBeanDefinitionReader used internally by
      GenericGroovyXmlWebContextLoader disables XML validation for its
      internal XmlBeanDefinitionReader, and this prevents some XML
      configuration features from working properly. For example, the default
      value for the 'type' attribute (defined in the spring-beans XSD) of the
      <qualifier> tag gets ignored, resulting in an exception when the
      application context is loaded.
      
      This commit addresses this issue by refactoring the implementation of
      loadBeanDefinitions() in GenericGroovyXmlWebContextLoader to use an
      XmlBeanDefinitionReader or GroovyBeanDefinitionReader depending on the
      file extension of the resource location from which bean definitions
      should be loaded. This aligns the functionality of
      GenericGroovyXmlWebContextLoader with the existing functionality of
      GenericGroovyXmlContextLoader.
      
      Issue: SPR-12768
      2ba1151b
  9. 28 2月, 2015 1 次提交
  10. 21 10月, 2014 1 次提交
  11. 13 3月, 2014 2 次提交
    • S
      Refactor SQL script support · 2bfd6ddc
      Sam Brannen 提交于
      This commit continues the work in the previous commit as follows:
      
       - Introduced an exception hierarchy for exceptions related to SQL
         scripts, with ScriptException as the base.
      
       - CannotReadScriptException and ScriptStatementFailedException now
         extend ScriptException.
      
       - Introduced ScriptParseException, used by ScriptUtils.splitSqlScript().
      
       - DatabasePopulatorUtils.execute() now explicitly throws a
         DataAccessException.
      
       - Polished Javadoc in ResourceDatabasePopulator.
      
       - Overhauled Javadoc in ScriptUtils and documented all constants.
      
       - Added missing @author tags for original authors in ScriptUtils and
         ScriptUtilsTests.
      
       - ScriptUtils.splitSqlScript() now asserts preconditions.
      
       - Deleted superfluous methods in ScriptUtils and changed method
         visibility to private or package private as appropriate.
      
       - Deleted the ScriptStatementExecutor introduced in the previous
         commit; ScriptUtils.executeSqlScript() now accepts a JDBC Connection;
         JdbcTestUtils, AbstractTransactionalJUnit4SpringContextTests, and
         AbstractTransactionalTestNGSpringContextTests now use
         DatabasePopulatorUtils to execute a ResourceDatabasePopulator instead
         of executing a script directly via ScriptUtils.
      
       - Introduced JdbcTestUtilsIntegrationTests.
      
      Issue: SPR-9531
      2bfd6ddc
    • C
      Support multi-line comments in SQL scripts · e5c17560
      cbaldwin74 提交于
      Prior to this commit neither ResourceDatabasePopulator nor
      JdbcTestUtils properly supported multi-line comments (e.g., /* ... */).
      Secondarily there has developed a significant amount of code
      duplication in these two classes that has led to maintenance issues
      over the years.
      
      This commit addresses these issues as follows:
      
       - Common code has been extracted from ResourceDatabasePopulator and
         JdbcTestUtils and moved to a new ScriptUtils class in the
         spring-jdbc module.
      
       - Relevant test cases have been migrated from JdbcTestUtilsTests to
         ScriptUtilsTests.
      
       - ScriptUtils.splitSqlScript() has been modified to ignore multi-line
         comments in scripts during processing.
      
       - ResourceDatabasePopulator supports configuration of the start and end
         delimiters for multi-line (block) comments.
      
       - A new test case was added to ScriptUtilsTests for the new multi-line
         comment support.
      
      Issue: SPR-9531
      e5c17560
  12. 22 1月, 2014 1 次提交
    • S
      Introduce EJB-based transactional tests in the TCF · c0eafa9e
      Sam Brannen 提交于
      This commit introduces transactional integration tests executing
      against both JUnit and TestNG in the TestContext framework (TCF) using
      @TransactionAttribute in EJBs instead of Spring’s @Transactional
      annotation.
      
      These tests disprove the claims raised in SPR-6132 by demonstrating that
      transaction support in the TCF works as expected when a transactional
      EJB method that is configured with TransactionAttribute.REQUIRES_NEW is
      invoked. Specifically:
      
       - The transaction managed by the TCF is suspended while such an EJB
         method is invoked.
       - Any work performed within the new transaction for the EJB method is
         committed after the method invocation completes.
       - The transaction managed by the TCF is resumed and subsequently
         either rolled back or committed as necessary based on the
         configuration of @Rollback and @TransactionConfiguration.
      
      The configuration for the JUnit-based tests is straightforward and self
      explanatory; however, the configuration for the TestNG tests is less
      intuitive.
      
      In order for the TCF to function properly, the developer must ensure
      that test methods within a given TestNG test (whether defined locally,
      in a superclass, or somewhere else in the suite) are executed in the
      proper order. In a stand-alone test class this is straightforward;
      however, in a test class hierarchy (or test suite) with dependent
      methods, it is necessary to configure TestNG so that all methods within
      an individual test are executed in isolation from test methods in other
      tests. This can be achieved by configuring a test class to run in its
      own uniquely identified suite (e.g., by annotating each concrete
      TestNG-based test class with @test(suiteName = "< Some Unique Suite
      Name >")).
      
      For example, without specifying a unique suite name for the TestNG
      tests introduced in this commit, test methods will be executed in the
      following (incorrect) order:
      
       - CommitForRequiredEjbTxDaoTestNGTests.test1InitialState()
       - CommitForRequiresNewEjbTxDaoTestNGTests.test1InitialState()
       - RollbackForRequiresNewEjbTxDaoTestNGTests.test1InitialState()
       - RollbackForRequiredEjbTxDaoTestNGTests.test1InitialState()
       - CommitForRequiredEjbTxDaoTestNGTests.test2IncrementCount1()
      
      The reason for this ordering is that test2IncrementCount1() depends on
      test1InitialState(); however, the intention of the developer is that
      the tests for an individual test class are independent of those in
      other test classes. So by specifying unique suite names for each test
      class, the following (correct) ordering is achieved:
      
       - RollbackForRequiresNewEjbTxDaoTestNGTests.test1InitialState()
       - RollbackForRequiresNewEjbTxDaoTestNGTests.test2IncrementCount1()
       - RollbackForRequiresNewEjbTxDaoTestNGTests.test3IncrementCount2()
       - CommitForRequiredEjbTxDaoTestNGTests.test1InitialState()
       - CommitForRequiredEjbTxDaoTestNGTests.test2IncrementCount1()
       - CommitForRequiredEjbTxDaoTestNGTests.test3IncrementCount2()
       - RollbackForRequiredEjbTxDaoTestNGTests.test1InitialState()
       - RollbackForRequiredEjbTxDaoTestNGTests.test2IncrementCount1()
       - RollbackForRequiredEjbTxDaoTestNGTests.test3IncrementCount2()
       - CommitForRequiresNewEjbTxDaoTestNGTests.test1InitialState()
       - CommitForRequiresNewEjbTxDaoTestNGTests.test2IncrementCount1()
       - CommitForRequiresNewEjbTxDaoTestNGTests.test3IncrementCount2()
      
      See the JIRA issue for more detailed log output.
      
      Furthermore, @DirtiesContext(classMode = ClassMode.AFTER_CLASS) has
      been used in both the JUnit and TestNG tests introduced in this commit
      in order to ensure that the in-memory database is reinitialized between
      each test class.
      
      Issue: SPR-6132
      c0eafa9e
  13. 06 11月, 2013 1 次提交
  14. 09 6月, 2013 1 次提交
  15. 07 3月, 2013 1 次提交
    • S
      Provide support for context hierarchies in the TCF · 98074e77
      Sam Brannen 提交于
      Prior to this commit the Spring TestContext Framework supported creating
      only flat, non-hierarchical contexts. There was no easy way to create
      contexts with parent-child relationships.
      
      This commit addresses this issue by introducing a new @ContextHierarchy
      annotation that can be used in conjunction with @ContextConfiguration
      for declaring hierarchies of application contexts, either within a
      single test class or within a test class hierarchy. In addition,
      @DirtiesContext now supports a new 'hierarchyMode' attribute for
      controlling context cache clearing for context hierarchies.
      
      - Introduced a new @ContextHierarchy annotation.
      - Introduced 'name' attribute in @ContextConfiguration.
      - Introduced 'name' property in ContextConfigurationAttributes.
      - TestContext is now aware of @ContextHierarchy in addition to
        @ContextConfiguration.
      - Introduced findAnnotationDeclaringClassForTypes() in AnnotationUtils.
      - Introduced resolveContextHierarchyAttributes() in ContextLoaderUtils.
      - Introduced buildContextHierarchyMap() in ContextLoaderUtils.
      - @ContextConfiguration and @ContextHierarchy may not be used as
        top-level, class-level annotations simultaneously.
      - Introduced reference to the parent configuration in
        MergedContextConfiguration and WebMergedContextConfiguration.
      - Introduced overloaded buildMergedContextConfiguration() methods in
        ContextLoaderUtils in order to handle context hierarchies separately
        from conventional, non-hierarchical contexts.
      - Introduced hashCode() and equals() in ContextConfigurationAttributes.
      - ContextLoaderUtils ensures uniqueness of @ContextConfiguration
        elements within a single @ContextHierarchy declaration.
      - Introduced CacheAwareContextLoaderDelegate that can be used for
        loading contexts with transparent support for interacting with the
        context cache -- for example, for retrieving the parent application
        context in a context hierarchy.
      - TestContext now delegates to CacheAwareContextLoaderDelegate for
        loading contexts.
      - Introduced getParentApplicationContext() in MergedContextConfiguration
      - The loadContext(MergedContextConfiguration) methods in
        AbstractGenericContextLoader and AbstractGenericWebContextLoader now
        set the parent context as appropriate.
      - Introduced 'hierarchyMode' attribute in @DirtiesContext with a
        corresponding HierarchyMode enum that defines EXHAUSTIVE and
        CURRENT_LEVEL cache removal modes.
      - ContextCache now internally tracks the relationships between contexts
        that make up a context hierarchy. Furthermore, when a context is
        removed, if it is part of a context hierarchy all corresponding
        contexts will be removed from the cache according to the supplied
        HierarchyMode.
      - AbstractGenericWebContextLoader will set a loaded context as the
        ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE in the MockServletContext when
        context hierarchies are used if the context has no parent or if the
        context has a parent that is not a WAC.
      - Where appropriate, updated Javadoc to refer to the
        ServletTestExecutionListener, which was introduced in 3.2.0.
      - Updated Javadoc to avoid and/or suppress warnings in spring-test.
      - Suppressed remaining warnings in code in spring-test.
      
      Issue: SPR-5613, SPR-9863
      98074e77
  16. 04 1月, 2013 1 次提交
    • P
      Remove duplicate test classes · 42b5d6dd
      Phillip Webb 提交于
      Prior to this commit many test utility classes and sample beans were
      duplicated across projects. This was previously necessary due to the
      fact that dependent test sources were not shared during a gradle
      build. Since the introduction of the 'test-source-set-dependencies'
      gradle plugin this is no longer the case.
      
      This commit attempts to remove as much duplicate code as possible,
      co-locating test utilities and beans in the most suitable project.
      For example, test beans are now located in the 'spring-beans'
      project.
      
      Some of the duplicated code had started to drift apart when
      modifications made in one project where not ported to others. All
      changes have now been consolidated and when necessary existing tests
      have been refactored to account for the differences.
      
      Conflicts:
      	spring-beans/src/test/java/org/springframework/beans/factory/ConcurrentBeanFactoryTests.java
      	spring-beans/src/test/java/org/springframework/beans/factory/support/BeanFactoryGenericsTests.java
      	spring-beans/src/test/java/org/springframework/beans/support/PagedListHolderTests.java
      42b5d6dd
  17. 08 12月, 2012 1 次提交
    • S
      Move tests to spring-test module · a436a575
      Sam Brannen 提交于
      When Spr9799XmlConfigTests and Spr9799AnnotationConfigTests were
      created, there were issues with the classpath related to slf4j
      dependencies that made it impossible for these classes to reside in the
      spring-test module. Consequently, these tests were added to the
      spring-test-mvc module. However, the issues with slf4j have since been
      resolved in the Gradle build, and this commit therefore moves these test
      classes to the spring-test module where they belong.
      
      Issue: SPR-9799
      a436a575
  18. 05 12月, 2012 1 次提交
    • S
      Support comments in statements in JdbcTestUtils · d0f687f0
      Sam Brannen 提交于
      Prior to this commit, executing an SQL script with JdbcTestUtils would
      fail if a statement in the script contained a line comment within the
      statement.
      
      This commit ensures that standard SQL comments (i.e., any text beginning
      with two hyphens and extending to the end of the line) are properly
      omitted from the statement before executing it.
      
      In addition, multiple adjacent whitespace characters within a statement
      but outside a literal are now collapsed into a single space.
      
      Issue: SPR-9982
      d0f687f0
  19. 22 10月, 2012 1 次提交
    • S
      Support comments in SQL scripts in JdbcTestUtils · 4aaf014c
      Sam Brannen 提交于
      Prior to this commit, utility methods in JdbcTestUtils interpreted SQL
      comments as separate statements, resulting in an exception when such a
      script is executed.
      
      This commit addresses this issue by introducing a
      readScript(lineNumberReader, String) method that accepts a comment
      prefix. Comment lines are therefore no longer returned in the parsed
      script. Furthermore, the existing readScript(lineNumberReader) method
      now delegates to this new readScript() method, supplying "--" as the
      default comment prefix.
      
      Issue: SPR-9593
      4aaf014c
  20. 14 10月, 2012 1 次提交
    • S
      Support session & request scoped beans in the TCF · 21ebbb9c
      Sam Brannen 提交于
      This commit introduces RequestAndSessionScopedBeansWacTests which
      verifies support for request and session scoped beans in the Spring
      TestContext Framework (TCF).
      
      This support was actually introduced as an intentional side effect of
      the work performed for SPR-5243 through the addition of the new 
      WebTestExecutionListener.
      
      Issue: SPR-4588
      21ebbb9c
  21. 08 10月, 2012 1 次提交
    • S
      Support loading WebApplicationContexts in the TCF · a73280cc
      Sam Brannen 提交于
      Prior to this commit, the Spring TestContext Framework only supported
      loading an ApplicationContext in integration tests from either XML or
      Java Properties files (since Spring 2.5), and Spring 3.1 introduced
      support for loading an ApplicationContext in integration tests from
      annotated classes (e.g., @Configuration classes). All of the
      ContextLoader implementations used to provide this support load a
      GenericApplicationContext. However, a GenericApplicationContext is not
      suitable for testing a web application since a web application relies on
      an implementation of WebApplicationContext (WAC).
      
      This commit makes it possible to integration test Spring-powered web
      applications by adding the following functionality to the Spring
      TestContext Framework.
      
       - Introduced AbstractGenericWebContextLoader and two concrete
         subclasses:
         - XmlWebContextLoader
         - AnnotationConfigWebContextLoader
      
       - Pulled up prepareContext(context, mergedConfig) from
         AbstractGenericContextLoader into AbstractContextLoader to allow it
         to be shared across web and non-web context loaders.
      
       - Introduced AnnotationConfigContextLoaderUtils and refactored
         AnnotationConfigContextLoader accordingly. These utils are also used
         by AnnotationConfigWebContextLoader.
      
       - Introduced a new @WebAppConfiguration annotation to denote that the
         ApplicationContext loaded for a test should be a WAC and to configure
         the base resource path for the root directory of a web application.
      
       - Introduced WebMergedContextConfiguration which extends
         MergedContextConfiguration with support for a baseResourcePath for
         the root directory of a web application.
      
       - ContextLoaderUtils.buildMergedContextConfiguration() now builds a
         WebMergedContextConfiguration instead of a standard
         MergedContextConfiguration if @WebAppConfiguration is present on the
         test class.
      
       - Introduced a configureWebResources() method in
         AbstractGenericWebContextLoader that is responsible for creating a
         MockServletContext with a proper ResourceLoader for the
         resourceBasePath configured in the WebMergedContextConfiguration. The
         resulting mock ServletContext is set in the WAC, and the WAC is
         stored as the Root WAC in the ServletContext.
      
       - Introduced a WebTestExecutionListener that sets up default thread
         local state via RequestContextHolder before each test method by using
         the MockServletContext already present in the WAC and by creating a
         MockHttpServletRequest, MockHttpServletResponse, and
         ServletWebRequest that is set in the RequestContextHolder. WTEL also
         ensures that the MockHttpServletResponse and ServletWebRequest can be
         injected into the test instance (e.g., via @Autowired) and cleans up
         thread locals after each test method.
      
       - WebTestExecutionListener is configured as a default
         TestExecutionListener before DependencyInjectionTestExecutionListener
      
       - Extracted AbstractDelegatingSmartContextLoader from
         DelegatingSmartContextLoader and introduced a new
         WebDelegatingSmartContextLoader.
      
       - ContextLoaderUtils now selects the default delegating ContextLoader
         class name based on the presence of @WebAppConfiguration on the test
         class.
      
       - Tests in the spring-test-mvc module no longer use a custom
         ContextLoader to load a WebApplicationContext. Instead, they now
         rely on new core functionality provided in this commit.
      
      Issue: SPR-5243
      a73280cc
  22. 31 1月, 2012 1 次提交
    • C
      Rename modules {org.springframework.*=>spring-*} · 02a4473c
      Chris Beams 提交于
      This renaming more intuitively expresses the relationship between
      subprojects and the JAR artifacts they produce.
      
      Tracking history across these renames is possible, but it requires
      use of the --follow flag to `git log`, for example
      
          $ git log spring-aop/src/main/java/org/springframework/aop/Advisor.java
      
      will show history up until the renaming event, where
      
          $ git log --follow spring-aop/src/main/java/org/springframework/aop/Advisor.java
      
      will show history for all changes to the file, before and after the
      renaming.
      
      See http://chrisbeams.com/git-diff-across-renamed-directories
      02a4473c