[TIP] Unittest Changes

[Andrew Bennetts]

holger krekel wrote:
[...]
> 
> aren't debuggability/maintenance problems maybe also attributable 
> to the deferred/asynchronous model exposed by twisted?  

Given that debuggable and maintainable tests have been written for Twisted code,
I don't think this is the case.

The @inlineCallbacks decorator for instance is useful for writing a test method
in the synchronous style, even though it may be calling asynchronous code.  So
a test can easily be written as a simple series of actions with no visible
asynchrony if that is the appropriate way to write that test.

[...]
> the need to think much.  But surely, you still need to think
> about how to write sensible tests - recently i have been wading 
> through test code that needed serious refactoring to become
> more maintainable (and it doesn't use twisted :) 

Right.  The problem isn't Twisted.  The problem is poorly written test code,
which is you say is possible with any project.

That said, the testing tools you provide can encourage good ways to arrange
code, and they can encourage bad ways to arrange code.  Like any API, in fact.

So, to borrow your phrase: aren't debuggability/maintenance problems maybe also
attributable to the put-assertions-anywhere-with-no-context model?  Twisted's
experience suggests “yes” to me (a Twisted developer), even if your
interpretation of JP's example is different.  Maybe you lack enough context
<wink>.

-Andrew.