It's also possible to write a little bit of testing library code and get both versions of the test nearly for free. Unfortunately, I very rarely see test suites written that way. I think many people don't realize there are two cases to handle or believe testing both cases is too expensive for them (perhaps because they don't realize you can reuse the code for doing so to save on the cost). Jean-Paul On Wed, Oct 19, 2016 at 5:54 PM, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
On Oct 19, 2016, at 2:47 PM, Itamar Turner-Trauring <itamar@itamarst.org> wrote:
On Wed, Oct 19, 2016, at 05:45 PM, Itamar Turner-Trauring wrote:
Well... I had a test that went through synchronous Deferred path. And yeah, it was easier to write than async test. But it failed to catch a bug that was only in async case. So the problem I see is that supporting both in Deferred means you need twice the number of tests each time you use Deferreds.
Er, that was unclear. I had a bug that wasn't caught by tests because it passed with sync Deferred and failed with async Deferred callback, and I didn't have tests for latter.
To be clear: I do see this as a *downside* to Deferred's architecture; it's a tradeoff. I see the loose coupling with the event loop as a worthwhile upside.
However, it's totally possible to write the async Deferred callback case as well, just by having the test fire the Deferred after returning to the test body instead of firing it before :-).
-glyph
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python