- 27 7月, 2015 1 次提交
-
-
由 Rob Winch 提交于
This commit introduces integration between MockMvc and HtmlUnit, thus simplifying end-to-end testing when using HTML-based views and enabling developers to do the following. - Easily test HTML pages using tools such as HtmlUnit, WebDriver, & Geb without the need to deploy to a Servlet container - Test JavaScript within pages - Optionally test using mock services to speed up testing - Share logic between in-container, end-to-end tests and out-of-container integration tests Issue: SPR-13158
-
- 22 7月, 2015 4 次提交
-
-
由 Sam Brannen 提交于
SPR-13211 introduced support for reusing mock requests in Spring MVC Test if the request was created by the the Spring TestContext Framework. Unfortunately, that change makes it impossible for MockMvc.perform() to be invoked multiple times within the same test method without side effects. For example, session attributes and request parameters are transparently and unexpectedly retained for subsequent invocations of perform(), causing certain categories of tests to fail. This commit reverts the changes introduced in SPR-13211 and introduces a new MockMvcReuseTests class to serve as regression tests within Spring's test suite. Issue: SPR-13260, SPR-13211
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
-
由 Brian Clozel 提交于
HTTP headers such as "Expires", "Last-Modified" all use date strings like "Tue, 21 Jul 2015 10:00:00 GMT". Prior to this commit, there was no way to match those header values, besides formatting dates manually. This commit introduces a new HeaderResultMatcher to test those date headers using a long timestamp: ``` this.mockMvc.perform(get("/persons/1").header("If-Modified-Since", now)) .andExpect(status().isNotModified()) .andExpect(header().dateValue("Last-Modified", timestamp)); ``` Issue: SPR-13263
-
- 21 7月, 2015 2 次提交
-
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
Prior to this commit, the Spring MVC Test Framework always created a new MockHttpServletRequest, disregarding any mock request already present in Spring Web's RequestContextHolder -- for example, one created by the ServletTestExecutionListener in the Spring TestContext Framework (TCF). This commit modifies MockHttpServletRequestBuilder so that it reuses a mock request created by the TCF. However, MockMultipartHttpServletRequestBuilder continues to always create a new MockMultipartHttpServletRequest since a MockHttpServletRequest created by the TCF is not directly compatible with a MockMultipartHttpServletRequest. Furthermore, in order to avoid unforeseen side effects, MockHttpServletRequestBuilder will always create a new MockHttpServletRequest if a mock request is present in the RequestContextHolder but not created by the TCF. Issue: SPR-13211
-
- 16 7月, 2015 1 次提交
-
-
由 Michal Karolik 提交于
Closes gh-839
-
- 10 7月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
When using the Spring TestContext Framework (TCF) to load a WebApplicationContext and the Spring MVC Test Framework (MockMvc) to test a controller, two instances of MockHttpServletRequest will be created. Due to an ordering issue with regard to population of the RequestAttributes, it is therefore possible that a filter accesses the mocked request managed by the TCF, while the controller accesses the mocked request managed by MockMvc, and this leads to test failures if the controller expects data from the filter to be present in the request. This commit fixes this bug by ensuring that the RequestAttributes backed by the mocked request managed by MockMvc are stored in the RequestContextHolder before any filters are invoked by MockMvc. Issue: SPR-13217
-
- 28 6月, 2015 2 次提交
-
-
由 Sam Brannen 提交于
Issue: SPR-13171
-
由 Sam Brannen 提交于
Prior to this commit, the Spring MVC Test framework only provided support for printing debug information about the MvcResult to STDOUT. This commit introduces support for logging `MvcResult` details at `DEBUG` level via the Apache Commons Logging API. In addition, this commit introduces additional `print(..)` variants for printing debug information to custom output streams and writers. Specifically, `MockMvcResultHandlers` has been augmented with the following new static methods: - `log()` - `print(OutputStream)` - `print(Writer)` Issue: SPR-13171
-
- 27 6月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
Prior to this commit, when rendering cookies via `andDo(print())` in Spring MVC Test, the output for the `MockHttpServletResponse` would look something like the following: Cookies = [javax.servlet.http.Cookie@25084a1e] The reason is that the Cookie class in javax.servlet-api-3.0.1.jar does not implement toString(). Consequently, nothing about the cookie's name, value, etc., is displayed, thereby making the debug output for cookies next to useless. This commit improves on this by implementing custom toString() logic for cookies in debug output in Spring MVC Test. For example, the output now looks like this (without the newlines): Cookies = [[Cookie@47faa49c name = 'enigma', value = '42', \\ comment = [null], domain = [null], maxAge = -1, \\ path = [null], secure = false, version = 0, \\ httpOnly = false]] In addition, this commit fixes a minor bug for FlashMap debug output if the FlashMap is empty. Issue: SPR-13168
-
- 25 6月, 2015 1 次提交
-
-
由 Rossen Stoyanchev 提交于
Issue: SPR-13079
-
- 19 6月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
-
- 17 6月, 2015 1 次提交
-
-
由 Brian Clozel 提交于
Prior to this change, `XpathResultMatchers` and more generally the `MockHttpServletResponse` would default to ISO-8859-1 encoding even when it's not supposed to. The Servlet/HTTP specs mention this encoding for all `text/*` mime types when decoding bodies to Strings, but this issue is about XML Parsers. XML Parsers should use the encoding: * defined in the `Content-Type` response header (if available) * written in the XML declaration of the document * "guessed" by a built-in auto-detection mechanism This commit changes the following: * XPathMatchers now feed the XML parser with byte arrays instead of decoded Strings * the response should be written to `MockHttpServletResponse` using its OutputStream, and not a PrintWriter which defaults to ISO-8859-1 Issue: SPR-12676
-
- 12 6月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
The modifications to DefaultMockMvcBuilder performed in conjunction with SPR-12553 introduced a breaking change: the WebApplicationContext supplied to DefaultMockMvcBuilder's constructor was *always* stored in the ServletContext as the root WebApplicationContext, overwriting a root WebApplicationContext that had been set by the user or by the Spring TestContext Framework (TCF) -- for example, in AbstractGenericWebContextLoader. Consequently, the changes in SPR-12553 cause tests that use @ContextHierarchy to fail if web components rely on the correct WebApplicationContext being stored under the WebApplicationContext#ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE key. This commit reverts the breaking changes introduced in SPR-12553: if the root WebApplicationContext has already been set in the ServletContext of the WebApplicationContext supplied to DefaultMockMvcBuilder, no action is taken. Furthermore, this commit introduces new code to address the initial intent of SPR-12553. Specifically, if the root WebApplicationContext has NOT been set in the ServletContext of the WebApplicationContext supplied to DefaultMockMvcBuilder, the application context hierarchy will be traversed in search of the root WebApplicationContext, and the root WebApplicationContext will then be stored under the ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE key. Issue: SPR-13075, SPR-12553
-
- 25 4月, 2015 1 次提交
-
-
由 Rob Winch 提交于
Previously MockHttpServletRequestBuilder merge method would append the parent's (default) RequestPostProcessor implementations to the end. This means that the default RequestPostProcessor implementations would override values set by previous RequestPostProcessor implementations. This commit ensures that the default RequestPostProcessor are preformed first so that additional RequestPostProcessor implementations override the defaults. Issue: SPR-12945
-
- 07 4月, 2015 1 次提交
-
-
由 Rossen Stoyanchev 提交于
Issue: SPR-12880
-
- 25 3月, 2015 1 次提交
-
-
由 Juergen Hoeller 提交于
As of JUnit 4.9 / Hamcrest 1.3, there is no real need for a custom copy of that class anymore.
-
- 24 3月, 2015 1 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-12147
-
- 19 3月, 2015 1 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-12147
-
- 28 2月, 2015 1 次提交
-
-
由 Rossen Stoyanchev 提交于
Issue: SPR-12735
-
- 27 2月, 2015 1 次提交
-
-
由 Rossen Stoyanchev 提交于
-
- 26 2月, 2015 1 次提交
-
-
由 Rossen Stoyanchev 提交于
Issue: SPR-12751
-
- 10 2月, 2015 1 次提交
-
-
由 Stephane Nicoll 提交于
Add support for annotation-based event listeners. Enabled automatically when using Java configuration or can be enabled explicitly via the regular <context:annotation-driven/> XML element. Detect methods of managed beans annotated with @EventListener, either directly or through a meta-annotation. Annotated methods must define the event type they listen to as a single parameter argument. Events are automatically filtered out according to the method signature. When additional runtime filtering is required, one can specify the `condition` attribute of the annotation that defines a SpEL expression that should match to actually invoke the method for a particular event. The root context exposes the actual `event` (`#root.event`) and method arguments (`#root.args`). Individual method arguments are also exposed via either the `a` or `p` alias (`#a0` refers to the first method argument). Finally, methods arguments are exposed via their names if that information can be discovered. Events can be either an ApplicationEvent or any arbitrary payload. Such payload is wrapped automatically in a PayloadApplicationEvent and managed explicitly internally. As a result, users can now publish and listen for arbitrary objects. If an annotated method has a return value, an non null result is actually published as a new event, something like: @EventListener public FooEvent handle(BarEvent event) { ... } Events can be handled in an aynchronous manner by adding `@Async` to the event method declaration and enabling such infrastructure. Events can also be ordered by adding an `@order` annotation to the event method. Issue: SPR-11622
-
- 17 1月, 2015 1 次提交
-
-
由 Maciej Ziarko 提交于
-
- 22 12月, 2014 1 次提交
-
-
由 Sebastien Deleuze 提交于
Issue: SPR-12553
-
- 02 11月, 2014 1 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-12405
-
- 30 10月, 2014 1 次提交
-
-
由 Sam Brannen 提交于
Class-level Javadoc for MockHttpServletRequestBuilder now correctly refers to MockMvcRequestBuilders instead of MockMvcBuilders. Issue: SPR-12393
-
- 21 10月, 2014 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 14 8月, 2014 1 次提交
-
-
由 Sam Brannen 提交于
-
- 13 8月, 2014 1 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-11235
-
- 07 8月, 2014 1 次提交
-
-
由 Sebastien Deleuze 提交于
Replace references to the old RFC 2616 (HTTP 1.1) with references to the new RFCs 7230 to 7235. This commit also deprecates: - HttpStatus.USE_PROXY - HttpStatus.REQUEST_ENTITY_TOO_LARGE in favor of HttpStatus.PAYLOAD_TOO_LARGE - HttpStatus.REQUEST_URI_TOO_LONG in favor of HttpStatus.URI_TOO_LONG Issue: SPR-12067
-
- 02 8月, 2014 2 次提交
-
-
由 Rossen Stoyanchev 提交于
-
由 Jakub Narloch 提交于
Surprisingly until now the MockMvcRequestBuilders did not have methods for HTTP HEAD. This change adds such methods to the API making it consistent with other HTTP method types. Issue: SPR-12055
-
- 29 7月, 2014 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 24 7月, 2014 1 次提交
-
-
由 Sam Brannen 提交于
- Formatting - Suppress warnings - Remove unused imports
-
- 23 7月, 2014 1 次提交
-
-
由 Rossen Stoyanchev 提交于
This is a follow-up on the commit introducing MockMvcConfigurer: https://github.com/spring-projects/spring-framework/commit/c2b0fac852dd9f865699fb374ad78543767fec05 This commit refines the MockMvcConfigurer contract to use (the new) ConfigurableMockMvcBuilder hence not requiring downcasting to AbstractMockMvcBuilder. The same also no longer passes the "default" RequestBuilder which would also require a downcast, but rather allows a RequestPostProcessor to be returned so that a 3rd party framework or application can modify any property of every performed MockHttpServletRequest. To make this possible the new SmartRequestBuilder interface separates request building from request post processing while the new ConfigurableSmartRequestBuilder allows adding a RequestPostProcessor to a MockMvcBuilder. Issue: SPR-11497
-
- 18 7月, 2014 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 16 7月, 2014 1 次提交
-
-
由 Sam Brannen 提交于
-