On 06/11/2018 05:43, Moshe Zadka wrote:
Some of the best advice depends on details of the application. One
trick that is sometimes useful is passing in a "fake" reactor object.
This, of course, is only useful if the application is structured in a
way that functions/classes expect to get a reactor, instead of
reaching for the global one. However, usually *that's* not a
complicated refactoring to do.
Cool, do you have any example tests that do this?
Interesting, looks like pytest-twisted does away for the need for this
by showing how to install a fake reactor globally:
https://github.com/pytest-dev/pytest-twisted/blob/master/pytest_twisted.py#L129-L142
You can look at
https://twistedmatrix.com/documents/current/api/twisted.test.proto_helpers.MemoryReactor.html for
inspiration although, as all code under `twisted.test`, it is not
intended as end-user functionality, so using it directly is problematic.
Not sure I fully understand this, why is the MemoryReactor bad to use?
Where is it used?
It would be nice to have externally-useful reactors along the lines of
Clock
(https://twistedmatrix.com/documents/current/api/twisted.internet.task.Clock.html )
but, unfortunately, we do not have that yet.
So, clock is just a clock, right? How would that get worked into a
"real" reactor for testing?
You can, of course, use a real reactor and a real client to pump data.
However, in that case, you probably do want to switch to trial so that
you can return a deferred from a test function and have the reactor
run until the deferred fires. This is not great, but can work in a pinch.
pytest-twisted looks like it supports this pattern too, allowing test
functions to return deferreds...
I guess I'm still really looking to see examples of all of this...
Chris
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
