Feature request: Add optional before_intercept and after_intercept callbacks #28
Comments
|
That seems like a reasonable feature. Is it something you could create yourself and provide a pull request? Or at least a starting point from which we can collaborate? One area where things might get a bit messy is that the fundamental architecture of wsgi-intercept is rather old so we'd need to decide if we just want to hack something into that structure, or tune up things in general (for example there's been discussion of using context managers throughout). Anyway: Do you want the callbacks to happen directly before and after an intercepted request happens, or before the intercept it established? I assume the former? |
|
Assuming you only support 2.6 and above, I think a general overhaul of the code is due, which is good. However, I think a basic callback can be established even with the existing codebase. I will try to hack on it and see what I come up with. Regarding your question -- what I want is a hook to be called after we've decided a request is to be intercepted, but before calling the actual backing wsgi app to handle the request, and also a hook to call just before returning the data to the mocked interfaces (requests/urllib2/whatever) |
|
@cdent nope, couldn't find the time to hack on it - it requires a lot of work. I'm using our own Flask-Loopback for now, which is less flexible but gets the job done for our needs... |
See test/test_interceptor for the expect use pattern. The idea here is that instead of the overrides being visible to the caller the caller just uses a context manager that surrounds the tests and that context manager does the right thing. Those things, at the moment, are exploratory, in an effort to find the right idiom. The use of classes is intentional, despite icky, to make overrides and the creation of external subclasses easier. One thing (of probably several) that remains to be determined is the best idiom for interception when running a large suite of tests with the same intercept? What controls the context entry and exit? Nothing written in stone here, just an exploration. The goals? Two: * make the external interface simple while allowing lots of changing underneath (to bring wsgi-intercept into the future) * explore options for adding hooks and the like (see #28 for a related idea)
|
It has occured to me while working on 9d73597 that perhaps the easiest way to make this happen is to not use hooks at all. Instead just wrap the wsgi app being tested in another wsgi app callable? That covers the use case doesn't it? The ability to add code before and after the app is run? If not, could you provide a bit more clarity on what you're trying to do? Thanks. |
|
I currently use Flask-Loopback to simulate a 3rd party product, and want to be able to change its state before each request is made to it. All this should be done without changing any client code - so I keep all of my simulation code in the test setup area. I guess we can make it work with a wsgi wrapper, but it would be nice to add a dedicated hook because the library knows when it intercepts a call anyways. |
|
I'll continue thinking about this but right now I don't have a clear idea on how to best implement it. If you've got some ideas please add them here. In the meantime I'm releasing a new version today that has the context manager stuff referenced above. I'm hoping that's going to start a process of refactoring that will make things like hooks a bit easier. |
|
Perhaps for your needs is suitable a special module https://pypi.python.org/pypi/before_after |
I recently found out about wsgi-intercept and it looks extremely useful. I would like to convert one of my own projects, Flask-Loopback (https://github.com/vmalloc/flask-loopback) to use it, but am missing a small feature - the ability to register callbacks to take place before and after intercepted requests. It is useful in some testing scenarios, where you want to simulate time passage or other aspects of mocked environments. It would be also useful to provide those callbacks with as much data as is available about the request that was intercepted.
Thanks in advance!
The text was updated successfully, but these errors were encountered: