dynamic typing questions

Alexander Schmolck a.schmolck at gmx.net
Sun Dec 21 14:31:31 CET 2003


"John Roth" <newsgroups at jhrothjr.com> writes:

> "Alexander Schmolck" <a.schmolck at gmx.net> wrote in message
> news:yfsu13viaf2.fsf at black132.ex.ac.uk...
> > "John Roth" <newsgroups at jhrothjr.com> writes:
> >
> > > Also, pervasive testing has so many other advantages
> > > that I'm beginning to think that debuggers were the
> > > single worst invention in history.
> >
> > Pervasive testing is much easier in an interactive enviroment with a good
> > debugger.
> 
> It's much easier if you automate your tests, you write them
> first and you write the code for each one as you write the test.
> 
> Then you don't need the debugger. 

Needs are relative. Does one need hot water?

> Usually.

Usually I *do* make use of the debugger during such test development with
`unittest`. I typically use something along the following lines::

    import unittest
    class PermeableTestCase2(unittest.TestCase, object):
        def __call__(self, result=None):
            if result is None: result = self.defaultTestResult()
            result.startTest(self)
            testMethod = getattr(self, self._TestCase__testMethodName)
            self.setUp()
            testMethod()
            result.addSuccess(self)
            self.tearDown()
            result.stopTest(self)

    TestCase = PermeableTestCase2
    #TestCase = unittest.TestCase

    class FooTest(TestCase): ...

When a test fails (assuming I'm running emacs/ipython with ``@pdb on``) this
will automatically visit the file and line where the test fails in emacs and
throw me into the debugger in ipython so that I can easily see *why* the test
fails (by examinging the local variables, typing in expressions to try out
things, going up and down the stack (which will automatically visit the right
files and locations in emacs) etc.).

I find that this makes any development of tests (whether ''test-driven'' or
not) much more pleasant and the development of tests that contain loops and/or
complex/random state bearable.

If you think that you develop your tests more effectively by not using
something like the above, I'd be really curious to hear details.

 
'as

BTW: Does anyone have an authorative opinion whether it is possible to fake
resumable exceptions in python/pdb? My biggest current python programming
annoyance is that I'm not able to manually fix things and continue if a
program dies after churning away for a couple of hours because of a bad format
string (Who said static typing didn't have *any* advantages)?




More information about the Python-list mailing list