Comments (27)
I believe this accomplishes part of what we added to the rexsl fork. One question, what is the behavior of take() with respect to the order of requests? For example, if I have two conditional next() statements, the requests for these can arrive in any order. How do I take the request that matched a specific response in order to apply request specific validation to it?
from jcabi-http.
You should call takeAll(m)
and get a collection of all queries/requests which received the answers that match m
. Then, you can do whatever you want with this collection. Of course, queries will be positioned inside the collection in some order. And it will be the order of requests arrival to the container.
If you want to make assertions on all of that requests, you should use Matchers.everyItem(m)
. If you want to assert that at least one of them has some properties, you use Matchers.hasItem(m)
. Where m
is a matcher.
Let me know if I managed to explain it clear enough :)
from jcabi-http.
I'm aware of the task, give me some time to find a developer...
from jcabi-http.
@carlosmiranda it's yours now, please proceed keeping in mind our principles. Feel free to ask any technical questions right here in the ticket
from jcabi-http.
@carlosmiranda The cost of this task is 30 mins (this is exactly how much will be paid, not less not more), when the task is done
from jcabi-http.
@carlosmiranda please hold on with implementation... let's clarify the requirements first
from jcabi-http.
@yegor256 , no problem.
from jcabi-http.
Maybe I've missed something but we specifically want to validate each request against a unique set of requirements. If the matching of request and response is separated from the validation of requests we cannot know which validation requirements to apply to each request.
from jcabi-http.
@vjkoskela , @yegor256 , any word on what needs to be done?
from jcabi-http.
@vjkoskela do you know in advance how many requests are you expecting?
from jcabi-http.
Not exactly. Most test cases will know the exact number, type and requirements for all requests it is mocking. However, there are test cases that target specific functionality and are more permissive to certain common calls that do not directly affect the test case. For example, a test targeting a specific business case may stub a standard positive response to an authorization request and permit any number of request-responses on that endpoint.
from jcabi-http.
OK, how about this. MkContainer
will have three different methods:
next(MkAnswer)
next(MkAnswer, Matcher<MkQuery>)
next(MkAnswer, Matcher<MkQuery>, int)
.
The first one is just calling the second one with a "matching all" matcher. The second one is calling the third one with 1
as its third argument.
When requests arrive, the container will check which matchers they match. The first successful match will cause the answer to be returned. Then, the container will decrement the number, until it reaches zero.
For example, we want to response to authorization requests always, but only one time to a specific data request:
container.next(authorization_answer, Matchers.is_autorization_request(), Integer.MAX_VALUE);
container.next(data_answer, Matchers.is_data_request());
Makes sense?
from jcabi-http.
Yes, that makes sense. Is the first form next(MkAnswer) then the lowest priority? e.g. it is only used if no matcher matches the request?
from jcabi-http.
The priority is set by the order of calls to next()
. For example:
container
.next(alpha, when_request_contains_foo_header)
.next(beta)
.next(gamma, when_post_request, 5);
This means that when request arrives the container:
- check whether it it contains
foo
header. - if yes, returns
alpha
(and never returns it again) - if no, returns beta (and never returns it again)
gamma
will be returned only after beta
and only when request is POST
, and only 5 times.
In your scenario, when you want authentication request be always satisfied and data request only on certain conditions, configuration will look like:
container
.next(auth_response, if_it_is_auth_request, Integer.MAX_VALUE)
.next(data_response)
Any number of auth requests will be satisfied, but only one data request will get its answer. All other data requests will get 500.
from jcabi-http.
I still think there is a conflict between specifying order and specifying matchers. In our case we don't know the order but we would like to setup rules with matchers and execute the one that matches regardless of order.
So if I have the following:
container
.next(alpha, when_request_contains_foo_header)
.next(beta, when_request_contains_far_header)
.next(gamma, when_post_request, 5);
Will the correct response be given if I get the following in any order:
- request_contains_foo_header
- request_contains_foo_header
- post_request (up to five times)
The statement that concerns me, and granted I am not clear on how you intend to implement this, is "gamma will be returned only after beta". Are you implying there is a strict ordering to the expected requests?
from jcabi-http.
In this example everything will work as you expect. Because you're using matchers in all next()
methods. In my example, I'm using Matchers.anything()
matcher in the second call to next()
. This matcher will catch everything, and my gamma
will be returned only after beta
is satisfied.
So, your example will work exactly as you expect.
from jcabi-http.
My concern in your example is that if after the alpha matching request you receive a request that matches gamma then beta is still returned. You are correct that users can make it work; however, the semantics may be a little surprising and can make it easier to write brittle tests.
In our case the semantics were that only one matcher could match a request or else and exception is thrown. I understand that you are doing something more general so that's fine - just my two cents.
from jcabi-http.
Yeah, as a library we have to be generic..
@carlosmiranda does it all sound clear? can you implement it?
from jcabi-http.
@yegor256 , @vjkoskela , yeah it seems pretty clear now. If I understand it correctly, we implement MkQueryMatchers
, and next(MkAnswer, Matcher<MkQuery>, int)
, with convenience overloads for next
with predetermined Matcher and priority values?
I know it's been assigned to me since last week but please do give me a bit more time to implement, it's only been clarified recently.
from jcabi-http.
@carlosmiranda yeah you got it right
from jcabi-http.
@dmarkov please note that we need more time here than usual, thanks
from jcabi-http.
@dmarkov please note that we need more time here than usual, thanks
@yegor256 yes, take your time, thanks for letting me know
from jcabi-http.
I submitted a pull request for this at #23, please take a look.
from jcabi-http.
@yegor256 , #23 has been merged, are we good here?
from jcabi-http.
I think we're good with this ticket. I'll add a documentation page soon. @vjkoskela I'll keep you updated by email when the feature is fully ready and documented
from jcabi-http.
@carlosmiranda 30 mins was added to your account, many thanks for your contribution!
from jcabi-http.
the feature released in version 1.5
from jcabi-http.
Related Issues (20)
- No args contructors for Request types HOT 6
- Remove MultipartBodyBuilder HOT 7
- JdkRequest does not support compression HOT 1
- Update to Jakarta EE 9 spec HOT 3
- Bump hamcrest to 2.2 HOT 3
- new skin 1.7.1 HOT 17
- CVE-2018-10237 HOT 1
- CVE-2020-13956 HOT 1
- CVE-2020-8908 HOT 1
- Setting a filename for MultipartFormBody is broken HOT 1
- jackson-databind-2.13.1.jar: CVE-2020-36518 HOT 1
- pom.xml:114-419: Transitive dependencies for hamcrest 1.3... HOT 1
- CachingWire.java:85-89: This implementation depends on... HOT 1
- BaseRequest.java:75-83: Refactor this class to get rid of... HOT 1
- LastModifiedCachingWireTest.java:60-68: Clean tests... HOT 1
- LastModifiedCachingWireTest.java:204-213: Confirm cache... HOT 1
- fresh release HOT 6
- Dependency Dashboard
- XMLResponse fails recognizing namespaces HOT 2
- Release HOT 4
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 jcabi-http.