Comments (5)
The way to do this with AssertJ is via satisfies
that doesn’t require any assignment. We explicitly avoid that use of and
as it’s not idiomatic with AssertJ and we’re following their lead. What is the problem with that approach?
from spring-framework.
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
from spring-framework.
What is the problem with that approach?
Boilerplate code that's not needed when using the established MockMvc
approach.
I don't want to repeat the discussion we already had on #32643. I'd just, for the record, would like to leave that being able to define expectations on any aspect of the response in any order has been idiomatic with MockMvc
. With the new API, users expecting that flexibility might be caught by surprise, as they're left in a dead end once they've moved down one path of the assertion chain (e.g., body assertions).
I've found the discoverability of domain-specific assertions (the methods specific to responses and response aspects) to be quite hidden between all the generic assertion methods (satisfies
). That's something we cannot fix, as it's the way that AssertJ works. But it's one more reason to avoid additionally making these methods harder to discover. “Oh, I can get access to other assertions, if I just assign this original thing to a variable and then call different methods on it.” is a realization you actually have to come to in the first place, especially if you're trained to think in the fluent MockMvc style that has been around for ages.
Just to make sure I don't appear obnoxious about this: I think we're dealing with two separate idiomacies here. One being the established MockMvc programming model that allowed users to flexibly and fluently trigger assertions on different aspects. The other being the way that AssertJ assertions being designed usually. There are two reasons that I think we should favor the former over the latter:
- Users' expectations are more driven by things they have (had) available (the methods on MockMvc) than they're by things they did not have available (additional methods on the assertion).
- The consequences of “violating” the former idiomacy will cause users trouble to formulating the assertions they're used to defining. At least initially. If they've overcome that discoverability hurdle, they still need to write more cumbersome code. I do not yet understand the negative consequences of “violating” the latter idiomacy, especially not for our users.
from spring-framework.
I think we're coming from two different camps and it's a question of whether we could please both camps by offering both approaches but there's more code to maintain and that'd force users to figure out which they should use.
For me, if I'm choosing to use MvcResultAssert
that's because I like AssertJ and the style of assertions that its opinions promote. So I would much prefer MvcResultAssert
to follow AssertJ conventions rather then MockMvc
conventions.
“Oh, I can get access to other assertions, if I just assign this original thing to a variable and then call different methods on it.”
IMO, that's the established approach with AssertJ and it feels natural to me as an experienced user of AssertJ.
especially if you're trained to think in the fluent MockMvc style that has been around for ages
I don't think this is the target audience. I expect MvcResultAssert
to appeal to those who know and love AssertJ and have been looking forward to getting rid of MockMvc
.
Repeating myself, assigning the result with multiple assertThat
or use satisfies
if you don't want to assign the result is what AssertJ users are doing. I like the natural grouping that you get with this sort of approach rather than chaining absolutely everything. I find the tests easier to read when there's some separation of the assertions into different areas. So you'd have one statement for the status, one for the content type, one for the body, and so on. You then get natural line breaks whereas if it's all one mass of chained methods it's easy to lose track of exactly what's being asserted.
On a final note, Spring Security is moving away from and()
in its DSL and I think that's a good thing. Consistency across the portfolio would also be nice here.
With all that said, MvcResultAssert
is a bit special as it encompasses a lot of different concepts so I would like to explore other options to "group" things at the root level. I'll requalify this issue accordingly.
from spring-framework.
So we've spent quite a bit of time in #32712 and that led to a bit of more first-level type on the root assert but nothing that would change significantly what we have. We'll continue iterating but I want to emphasis on what what said previously and our wish to follow AssertJ conventions.
from spring-framework.
Related Issues (20)
- Unexpected exception in UriComponentsBuilder with a valid URI. HOT 2
- The RestClient is configured without content-length attribute in the request header by default HOT 1
- Accept ajc-compiled `@Aspect` classes for Spring AOP proxy usage HOT 1
- Accept ajc-compiled `@Aspect` classes for Spring AOP proxy usage HOT 1
- "GET must not have a request body" exception with RestTemplate.exchange(...) and OkHttp3ClientHttpRequest.executeInternal() HOT 7
- MockHttpServletRequest should not use a shared reader when no content is available HOT 1
- `@PathVariable` is used in the `@Controller` occurred java.lang.OutOfMemoryError: Java heap space HOT 4
- Add support for qualifiers in test bean overriding and consider improving by-type matching
- Socket.io support HOT 1
- Make it easier to register reflection hints on interface hierarchies
- Unexpected bean override / inject behavior
- Support Map in FormHttpMessageConverter HOT 4
- Add support for flagging an interface to declaratively expose it as an rsocket remote service
- Create WebFlux equivalent filter to handle URLs with trailing slashes
- Do not send Cookie header in reactive JdkClientHttpRequest if no cookies added HOT 1
- Introduce static `MultiValueMap` factory methods HOT 2
- https://stackoverflow.com/feeds/tag?tagnames=springspring-mvcspring-webfluxspring-aopspring-jdbcspring-r2dbcspring-transactionsspring-annotationsspring-jmsspring-elspring-testspring-java-configspring-remotingspring-ormspring-jmxspring-cachespring-rsocket&sort=newest
- Limit reflective operations in `BeanInstanceSupplier` with Spring AOT
- Unify Spring Framework documentation
- Introduce API to initialize `BeanFactory` before singleton instantiation
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from spring-framework.