Comments (9)
Shouldn’t you use satisfies
for this?
from spring-framework.
I need to return the result from a method.
from spring-framework.
Ok. An assert object is not meant to expose anything. You can assign the result of perform and get the response from there. Would that work?
from spring-framework.
Yes, that works and is what I do as a workaround. I assume that other trying to migrate their existing assertion pipelines will run into this as well.
Furthermore, getResponse()
is already present, but protected. So I wonder why it should be fine to call that method on the object returned from ….andExpect(…)
but not the assertion object.
from spring-framework.
It doesn’t matter that the method already exists. As I’ve tried to explain, we’re following what AssertJ does and they don’t expose their internal state with a getter like that (and they have them protected just because the hierarchy needs access to it).
Mixing AssetJ with returning an element of the result and not willing to assign the result doesn’t look like a common case to me. But perhaps I am missing something.
from spring-framework.
We’re following what AssertJ does and they don’t expose their internal state with a getter like that (and they have them protected just because the hierarchy needs access to it).
Well, we're extending AssertJ. Which naturally means adding stuff to the thing that's extended, isn't it? So, AssertJ not doing something we do is by definition, isn't it? Furthermore, that internal state already is exposed on AssertableMvcResult
. There's nothing to be hidden, really. What do we gain from asking developers to write boilerplate code in this particular case? That we differentiate what an AbstractAssert
is allowed to expose VS. an AssertProvider
?
Mixing AssertJ with returning an element of the result and not willing to assign the result doesn’t look like a common case to me.
Not willing sounds stubborn. I just think it would be nice to return the result of such an operation immediately, without having to capture some state initially solely to obtain the thing I want to return from it later. It's already possible on MockMvc
: define the request, chain expectations, return an aspect of the result. I don't see how anything in AssertJ is deeming that problematic non-idiomatic.
Using the response of a request is pretty common, as soon as you move beyond one-line examples and have test methods that execute slightly more complex testing flows that span multiple requests. Find an example of that in Spring RESTBucks.
from spring-framework.
Well, we're extending AssertJ. Which naturally means adding stuff to the thing that's extended, isn't it?
Yes, just like any custom Assert
, including the ones provided by AssertJ itself. The point I was trying to make is that we want the user experience to be natural and consistent with other Assert
classes. And an Assert either returns SELF
or a more dedicated assert instance based on an extracting function of some kind. It usually doesn't have a termination method that returns actual
or some state of actual
.
Furthermore, that internal state already is exposed on AssertableMvcResult
Again, that doesn't matter. And to be clear, I am not denying the use case here, just that it has to be fixed by making a method public, because it "is already present". I've already noticed a use case with async request where you want to first make a request and then get the response to trigger another perform
. Your sample takes that to the next level with chain of processing that each take the previous response and contribute the one used by the next. I wonder if we shouldn't make that use case first class by providing a dedicated method. We'd need to hack a bit more to see how we'd name that though.
WDYT?
from spring-framework.
In the end, I, personally, am more concerned about our users' ability to write boilerplate-free code. IMO, what is or is not deemed idiomatic should be of lower priority. Especially, as in this case, the absence of a certain style of method is equated with being non-idiomatic, which, I think, is not the same thing. But I've already argued that in a multitude of ways.
Find the translation of the Hamcrest-based definition of matchers to the AssertJ ones in Spring RESTBucks here. Note how, on multiple occasions (more here and here), this causes what could have been expressed in a single, fluent statement now has to be broken up into multiple expressions.
from spring-framework.
Thanks for sharing the migration.
this causes what could have been expressed in a single, fluent statement now has to be broken up into multiple expressions.
I am sorry but I don't see how this has to be a must have. Doing so would mean you'd have to write something like return assertThat(mvc.perform(...)
and that would read very strangely indeed.
I think you've done that by accident actually, calling result
what is actually an assert object.
I am going to close this now, but I am keeping the use case of producing another request based on a previous response in mind as I've shared in my previous comment.
from spring-framework.
Related Issues (20)
- Observation in ServerHttpObservationFilter is never stopped for asynchronous requests HOT 1
- ContentCachingRequestWrapper may allocate too much memory
- Bean override with REPLACE_OR_CREATE_DEFINITION and byType lookup fails if no match is found
- Quartz does not understand Cron expression when dayOfweek is 2-6 and dayOfMonth is * HOT 3
- RestClient does not work when sending an object HOT 1
- Inconsistent character handling between MockMvc created from a context or standalone HOT 7
- Exception that prevents component scan with REGISTER_BEAN conditions should provide the affected configuration class
- Upgrade to Micrometer 1.13.1
- Upgrade to Micrometer 1.12.7
- Ambiguity in doc HOT 2
- ActiveMQ messages for a group are not getting consumed and keeps piling HOT 2
- DataClassRowMapper cannot find record construcor during native run HOT 1
- OverrideMetadata equals/hashCode should rely on getClass() HOT 1
- Upgrade to Reactor 2024.0.0-M3
- Upgrade to Reactor 2023.0.7
- Upgrade to Reactor 2022.0.20 HOT 1
- Behaviour change in ScheduledAnnotationBeanPostProcessor: canceling scheduled tasks on ContextClosedEvent v6.0 -> v6.1 HOT 4
- Upgrade to Reactor 2020.0.45 HOT 1
- Support Protobuf 4.x
- TransactionalEventListener called with open transaction HOT 2
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.