Mock Response modification & request patterns feature

[zdllucky]

Sometimes when i PUT PATCH or POST data I need to receive different responses over time, so I guess it will be great to make response builder function instead of direct static response in reply method. This may be trigged on iteration, as instance: I send first request and receive RESP#1 and on the next requests i will Receive RESP#2 only. (Otherwise if i will try to place my own returnable method with proposed logic will it work though?...)

The second feature is to include the path patterns for the route, that will allow to put modifiable data e.g. uuids etc. in the path according to REST API patterns. The further enhancement might also include passing those modifiable path parameters to response builder I proposed above so developers could build their own custom response every time.

Hope my thoughts were useful enough, thank you.

[cyberail]

HI @zdllucky, First of all, thank you for the attention! Now about your issues: Both of them are really great features and we would love to implement them in our package.

More than that, about the second feature, we already started working on it. ncb000gt contributed the code to us for that functionality, we just made some style improvements. See PR #65 You can view it on the feature/matchers branch, I am recommending you to check code after line 151 in the matches_request_test.dart for the usage. For now it is not published still requires some reviews but you can test it by pulling aforementioned branch.

About the first feature, I just want to make sure that you want something like iterable responses for specific route containing the same data, e.g one route(with always same data) can have multiple responses which will be iterated on every requests you will make to this route(with same data) and when it reaches last one it will continue to return only the last one, does not matter how many request you will make after you reach the last response.

Please, ensure me about the first feature, so we know that we are on the same page.

Thank you again, we will love to hear more suggestions from you. And yeah, HNY! 🎆

[zdllucky]

@campfire5 There might be pretty many different parameters for the response modification: time, request data, iteration etc. That’s why I tried to propose a builder method for the mock response generation with those parameters provided (directly or via context variable). Hope this will make sense.

I will try the response marcher though and reply for usage experience, tnx.

[ncb000gt]

@zdllucky with the pr I have open you can extend the Matcher class and write whatever match fn you need/want. I supplied a few that I personally needed, but wanted to make it more extensible. Hope that helps clarify.

[ncb000gt]

I added a PR that should help resolve the "route path" issue described in this issue: https://github.com/lomsa-dev/http-mock-adapter/pull/79

[LukaGiorgadze]

Sometimes when i PUT PATCH or POST data I need to receive different responses over time, so I guess it will be great to make response builder function instead of direct static response in reply method.

@zdllucky hey, could you give us a little example what you mean there? Thank you!

[zdllucky]

@LukaGiorgadze for example delete request on the same object may be done only once. So every next request after delete 200 must return 404. But for myself i might do side action on fake json object and delete it there so on every nex request mockadapter will return 404 as it did not find object to delete

Like on this scheme:

Map<String, dynamic> fakeBd = {'1', Object()}

mock..onDelete()..callback() {
if(fakeBd.contains('1')) {
fakeBd.remove('1');
return /* 200 */;
}
else return /* 404 */;
}

I guess this will be ok

[LukaGiorgadze]

@LukaGiorgadze for example delete request on the same object may be done only once. So every next request after delete 200 must return 404. But for myself i might do side action on fake json object and delete it there so on every nex request mockadapter will return 404 as it did not find object to delete

Like on this scheme:

Map<String, dynamic> fakeBd = {'1', Object()}

mock..onDelete()..callback() {
if(fakeBd.contains('1')) {
fakeBd.remove('1');
return /* 200 */;
}
else return /* 404 */;
}

I guess this will be ok

That's the point of mock, you must know what data will be returned from the backend. Any logic like "if status xxx then return that" inside mock is incorrect.

[kuhnroyal]

@LukaGiorgadze for example delete request on the same object may be done only once. So every next request after delete 200 must return 404. But for myself i might do side action on fake json object and delete it there so on every nex request mockadapter will return 404 as it did not find object to delete

Like on this scheme:

Map<String, dynamic> fakeBd = {'1', Object()}

mock..onDelete()..callback() {
if(fakeBd.contains('1')) {
fakeBd.remove('1');
return /* 200 */;
}
else return /* 404 */;
}

I guess this will be ok

This should be split up into 2 separate tests tbh. A unit test should always run without side effects so that you can easily spot the problem. You are not only mocking a response, you are creating a fake backend with logic and your tests depend on this logic and some order of execution. Would strongly advise against doing this. Your single test has no more value than 2 separate test, it is only harder to unterstand and to trace problems.

[LukaGiorgadze]

Closed. https://github.com/lomsa-dev/http-mock-adapter/pull/79 by @ncb000gt