enable conditional answers in MkContainer about jcabi-http HOT 27 CLOSED

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:

1. check whether it it contains foo header.
2. if yes, returns alpha (and never returns it again)
3. 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.