And: I'm sure Twisted developer's will have reasons for frowning upon
tests returning deferreds, but could you recap shortly why?
It has the classic problem with bad tests: reliance on global state
which is not controlled by the test. Unit tests should be isolated, they
should not affect or rely on external state. When they do, you’re much
more likely to run into Spooky Action At A Distance[1]. It’s also hard
to debug when things go wrong — often you’re left with a frozen test
suite and no useful diagnostic output when there’s a bug.
I do understand that unit tests should not perform _actual_ networking
(like a real TCP connection - whether that's going remote or loopback).
Networking introduces some non-determinism.
But why is it bad to test protocol/factories using _fake_ transports like
proto_helpers.StringTransport
?
Sorry for asking again .. but I feel it's important (for me;) to
understand the actual problem here:
Is it a) doing networking in unit test or b) doing any async code in
unit tests (even when not doing any networking)?
As my friends David Reid and Alex Gaynor like to say: “Call a function,
pass it some arguments, look at the return value”.
1: https://en.wikipedia.org/wiki/Action_at_a_distance_%28computer_programming%29
Alright. I see. However, doesn't that leave big gaps in testing?
E.g., for integration tests, we (Autobahn|Python) have
Autobahn|Testsuite, which actually tests interaction of components over
the network.
For low-level (per function) testing, we have (synchronous) unit tests.
But there is a gap between those latter two.
It is this level of testing that I am missing.
Thanks again!
/Tobias
