[TIP] Unittest Changes

[holger krekel]

On Fri, Jul 25, 2008 at 19:57 +1000, Andrew Bennetts wrote:
> 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.

no doubt. But still the model might more easily produce situations 
where you can't easily follow the chain of function calls. At
least that was how it felt to me. 

> 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.

ah, nice.  

> [...]
> > 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?  

Hum, for one i have hardly seen asserts outside test
functions or methods.  Even if so i don't mind much 
as long as i can see a nice trace from the test 
function down to the failing assert expression. 

I do think that a test tool/approach is well advised to help 
with setting up and organising app state and providing helpful 
output for failed test setups etc.  

Surely, with py.test grouping tests in a class and implementing
setup_class/teardown_class or setup_method/teardown_method
methods, storing context on "cls" or "self" respectively is
used a lot.  But this setup of context i regard as a quite
separate concern from expressing assertions. 

cheers, 
holger

-- 
collaborative expert contracting: http://merlinux.eu 
PyPy  Python/Compiler tool chain: http://codespeak.net/pypy 
pylib py.test/greenlets/svn APIs: http://pylib.org