-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Partial body matching, possibly with Regex #7
Comments
Hi @Vages, glad you find talkback useful, and thank you for the feature idea. I understand the problem you're facing, and I already have in mind something that would cover this case and also be more generic to support other users' use cases. My idea is to add an option that let's you hook up your own body matching function. What do you think? |
Sounds like a great idea, @ijpiantanida! More versatile than my proposition. Reminds me of another tool we're already using, https://www.npmjs.com/package/dyson. I think you may have a better plan than I about how this should be implemented, but if you want any other kind of assistance (questions, code review, testing), I would be glad to help. |
@Vages I just released v1.5.0 which adds the Hope it helps! |
I could give the following a try and make a PR if you think the it sounds like a worthwhile undertaking, @ijpiantanida.
Our problem
My team and I have often found that a request body contains some piece of ever-changing data, e.g. a date or timestamp. Consequently, Talkback is unable to serve a cached response for the request the next time we run our tests.
The new ignore body option partially solves our problem: It works fine when we want to cache just one response for a given URL. But there are some URLs for which we need to cache two or more responses and serve them based on differing characteristics of the bodies. (This is especially true for GraphQL-endpoints, where the body is the only thing that matters and we may have hundreds of different bodies.) Ignore body is not of much help to us in these situations.
Proposed solution
We discussed this in my team. Our best idea was to giving Talkback-users the option of adding a
reqBodyIsRegex
field to themeta
-object in the cached response file, signifying that the request body is to be interpreted as a regular expression (requiring the author to convert the string to a regex). If any request body matches the regex, the cached response is served, exactly as stored. (Regex capturing groups could be used to adapt responses in the future, but I think this should not be in the first version of this.)Matching priority
My thoughts are that exact matching will have priority over regex-matching. I do not have any ideas about how to tie-break between competing regexes, but my guess is there's either no solution or some really good, pre-existing solution.
The text was updated successfully, but these errors were encountered: