You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not sure if other Pythonistas do this, but I work like this these days:
write a test (possibly using VCRpy!) with tactical sprinkle of logger.debug() bits of info
run it
it fails; I see the useful debug trace leading up to failure (which may be an exception, etc.)
tweak the test / the source code
re-run the test... etc.
rinse and repeat
I expect libraries and tools I use to provide me useful logging debug information. When I turn the log level to DEBUG I should see important decisions that VCRpy has made, such as
when a request is detected
how exactly vcrpy decided to supply the response:
What fields of the request did it try to match?
Could it find any matches in the known cassettes?
If so, which one? Which exact request?
If not, the request hits the network. How long did the request take to complete?
This is really important especially now that vcrpy has become much more powerful with customisable request matching. There are many more ways in which it could behave not quite as the user anticipated. e.g. I know that two distinct requests were sent and both were supposed to hit the network. I found that the request matching was too broad. I want debugging to tell me this so that I can make informed decisions about how to improve my test.
I imagine a few lines like this at strategic places in vcrpy code:
logger=logging.getLogger('vcrpy')
# in vcrpy codelogger.debug("Found matching request {1} in cassette {0}. Playing back...".format(cassette, request))
The text was updated successfully, but these errors were encountered:
Interesting idea, I'll think about the best way to do this. I think using a null output logger by default and then providing a way to get logging output if you want it.
Not sure if other Pythonistas do this, but I work like this these days:
logger.debug()
bits of infoI expect libraries and tools I use to provide me useful
logging
debug information. When I turn the log level to DEBUG I should see important decisions that VCRpy has made, such asWhat fields of the request did it try to match?
Could it find any matches in the known cassettes?
If so, which one? Which exact request?
If not, the request hits the network. How long did the request take to complete?
This is really important especially now that vcrpy has become much more powerful with customisable request matching. There are many more ways in which it could behave not quite as the user anticipated. e.g. I know that two distinct requests were sent and both were supposed to hit the network. I found that the request matching was too broad. I want debugging to tell me this so that I can make informed decisions about how to improve my test.
I imagine a few lines like this at strategic places in vcrpy code:
The text was updated successfully, but these errors were encountered: