-
Notifications
You must be signed in to change notification settings - Fork 123
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
testing with betamax? #212
Comments
Here's my hack for now (in testing setup):
and it seems to work correctly, except it still calls |
this is all i got: https://gitlab.com/anarcat/feed2exec/-/blob/master/feed2exec/tests/test_feeds.py#L175 |
Note that i found out |
yep, that's what i found out as well. |
this is roughly how close I got
problem is that |
This was failing because hooking up the cache into the session completely obliterates our poor old betamax cache. Instead of doing that, we politely queue the cache layer behind it... ... except that doesn't really work at all, does it. When the betamax cassette is hit, it does not need the cache, it *is* a cache. So that change in the controller setup breaks the test_fetch_cache which *does* expect the cache to "work" (that is, that the body is "None"), which it isn't when betamax wins. So we just mark that test as an expected failure for now. The proper way of doing this would be for the cache controller to be hit first, and if it doesn't find anything, ask betamax. But I couldn't figure out how to do this. I asked upstream: psf/cachecontrol#212 It would require some changes in the cache controller code. Meanwhile, i tried various horrors to work around this problem. I tried monkey-patching the base class of CacheControlAdapter so that it would call betamax, that failed in mysterious ways: https://stackoverflow.com/a/39311813 Specifically, it told me it couldn't call `send()` on a mock object. Go figure. I also tried to monkeypatch my way around this by deriving the CacheControlAdapter class to inject the betamax class as the called class, but this ended up in some sort of infinite loop and I got lost. I *could* have let the test_fetch_cache() function skip betamax and just talk to the cache. But then it would hit the network, and that would break autobuilders and all sorts of other assumptions. So fuck it. The caching layer works well enough, and this fixes the test suite for now.
is there a way to test this module alongside betamax?
the idea would be that the cachecontrol module would hit its own cache if present, otherwise bounce back into betamax. I am already using betamax extensively in my project to "mock" HTTP requests (record and replay, really) and it's been quite useful. But when I pair it with cachecontrol, I don't get good results.
either:
Those two possible scenarios are pretty much covered in this
if
case:That's pretty much case 1 above, which falls back to case 2 if we don't detect a "betamax" adapter in place.
And of course, it doesn't work.
What I would need is something like betamax's "old_adapters" system. Instead of calling the parent class,
CacheControlAdapter.send()
should allow the caller to define a list of adapters to call instead. The way betamax does this is fairly simple: there's anold_adapters
parameter that you can pass and that it uses for sending its requests..I have looked into the cachecontrol test suite to figure out if there could be inspiration there, but it seems to "mock" an http adapter instead of delegating requests... Since I don't want to reimplement the entire thing myself (and I can't figure out how to hook betamax in there either), could we add a similar functionality here?
Thanks!
PS: it seems I can mock a parent class but that seems horribly dirty - I am not sure I want to go that far...
The text was updated successfully, but these errors were encountered: