-
Notifications
You must be signed in to change notification settings - Fork 1
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
chore: export some things for use by consumers, docs fixes, updates to the match not found message #26
Conversation
…dditional data to the message printed when a match cannot be found
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #26 +/- ##
==========================================
+ Coverage 95.34% 95.91% +0.56%
==========================================
Files 4 4
Lines 86 98 +12
==========================================
+ Hits 82 94 +12
Misses 4 4
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious if you like my suggestion!
@@ -44,7 +44,7 @@ class CharlatanHttpClientAdapter implements HttpClientAdapter { | |||
|
|||
Unable to find matching fake http response definition for: | |||
|
|||
${method.toUpperCase()} $path | |||
${method.toUpperCase()} $path ${options.data} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel ya on the struggle of making this readable for gql or other nuanced requests.
Two thoughts:
- We could probably do something to include the query string here in addition to just the path. That won't help for gql unless we make some tweaks to clients to include the operation name in the query string. Which would be really useful
- We could add a hook on Charlatan to allow you to customize how the request prints out for this debugging use case with a solid default. Then consumers can do whatever makes sense to them to make the failed match on the request easier to interpret. Like in the case of gql maybe you can parse the operation name from the body instead of using the whole body. Not sure of a great name for this. Maybe
requestDebugFormatter
? Naming this is hard haha
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could add a hook on Charlatan to allow you to customize how the request prints out for this debugging use case with a solid default.
I like this idea as it was something I had been thinking about for the actual "matching" logic. I was struggling to suss out what Charlatan was doing under the hood and breakpoints were helpful but didn't fully solve my struggles so I pulled down Charlatan locally and added some logs like:
Matching $requestInfo against $matcherDescription; did not match
Matching $requestInfo against $otherMatcherDescription; did match
...
That along with the actual "couldn't find matches, here's what's configured:" message could be value adds, but I'd like to iterate on that in a follow-up PR because the real need from this PR is the exports of the typedef
s. So I'll back these changes out and maybe open an issue for this stuff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
domainlgtm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
platformlgtm
Dismissed because the approval was invalidated by another commit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
domainlgtm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
platformlgtm
…refactor * origin/main: chore: export some things for use by consumers, docs fixes, updates to the match not found message (#26)
📰 Summary of changes
Ran into a few hiccups when integrating with
0.3.0
that I'm addressing here, namey:CharlatanHttpRequest
andCharlatanRequestMatcher
which are helpful for defining customCharlatanRequestMatcher
s like the following:AddingUPDATE: Pulled this change out, see discussion on PRRequestOptions#data
to the message that gets printed out when a match cannot be found. This felt helpful because for GraphQL cases, themethod
andpath
are always the same, and the query itself (found indata
) is what helps identify the request for which there was no response definition. HOWEVER, at the same time, GraphQL queries can be pretty chunky, so when printing this out, there's a lot to parse. Should we truncate the data (often the first little bit is enough to see what was being requested) or do something else entirely?🧪 Testing done
I've updated the test for the one functional change, but that's the part of this PR that's most up for discussion!