On 12/03/2009 04:08 PM, Benji York wrote:
On Thu, Dec 3, 2009 at 9:43 AM, Marius Gedminasmar...@gedmin.as wrote:
I've had some success with this:
[snip code]
Nice. I'd love to see this wired into the testrunner so people could
specify breakpoints on the command line while running tests.
On Thu, Dec 03, 2009 at 08:55:32AM +0100, Wichert Akkerman wrote:
On 2009-12-2 23:06, Marius Gedminas wrote:
On Wed, Dec 02, 2009 at 01:36:37PM -0500, Benji York wrote:
Here's another idea: a testrunner option that takes a file name and line
number and inserts a breakpoint at that position.
On Thu, Dec 03, 2009 at 03:51:06PM +0200, Marius Gedminas wrote:
On Thu, Dec 03, 2009 at 08:55:32AM +0100, Wichert Akkerman wrote:
On 2009-12-2 23:06, Marius Gedminas wrote:
On Wed, Dec 02, 2009 at 01:36:37PM -0500, Benji York wrote:
Here's another idea: a testrunner option that takes a
On Thu, Dec 3, 2009 at 9:43 AM, Marius Gedminas mar...@gedmin.as wrote:
I've had some success with this:
[snip code]
Nice. I'd love to see this wired into the testrunner so people could
specify breakpoints on the command line while running tests.
If no one else gets around to that, I might.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ross Patterson wrote:
When a try/finally clause is (appropriately) used to do cleanup after an
exception during a test run, it often tears down parts of the fixture
that are needed in order to do useful post_mortem debugging of the
exception, such
Tres Seaver tsea...@palladion.com writes:
Ross Patterson wrote:
When a try/finally clause is (appropriately) used to do cleanup after an
exception during a test run, it often tears down parts of the fixture
that are needed in order to do useful post_mortem debugging of the
exception, such as
On Wed, Dec 02, 2009 at 09:08:51AM -0800, Ross Patterson wrote:
When a try/finally clause is (appropriately) used to do cleanup after an
exception during a test run, it often tears down parts of the fixture
that are needed in order to do useful post_mortem debugging of the
exception, such as
On Wed, Dec 2, 2009 at 1:22 PM, Ross Patterson m...@rpatterson.net wrote:
I'm sorry, I was unclear, the try/finally clauses are not necessarily in
*test tearDown* methods (though I used that language), they are often a
part of the application being tested, such as closing the request,
closing
Benji York be...@zope.com writes:
On Wed, Dec 2, 2009 at 1:22 PM, Ross Patterson m...@rpatterson.net wrote:
I'm sorry, I was unclear, the try/finally clauses are not necessarily in
*test tearDown* methods (though I used that language), they are often a
part of the application being tested,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ross Patterson wrote:
Tres Seaver tsea...@palladion.com writes:
Are you using try:...finally:... inside your testcase methods? If so,
why not just move the cleanup invocation into your 'tearDown' for the
testcase class: at that point, the '-D'
On Wed, Dec 02, 2009 at 01:36:37PM -0500, Benji York wrote:
Here's another idea: a testrunner option that takes a file name and line
number and inserts a breakpoint at that position. That way you can get
the same effect as editing the code without actually having to do so.
Is that possible?
On Wed, Dec 2, 2009 at 5:06 PM, Marius Gedminas mar...@gedmin.as wrote:
On Wed, Dec 02, 2009 at 01:36:37PM -0500, Benji York wrote:
Here's another idea: a testrunner option that takes a file name and line
number and inserts a breakpoint at that position. That way you can get
the same effect
On 2009-12-2 23:06, Marius Gedminas wrote:
On Wed, Dec 02, 2009 at 01:36:37PM -0500, Benji York wrote:
Here's another idea: a testrunner option that takes a file name and line
number and inserts a breakpoint at that position. That way you can get
the same effect as editing the code without
13 matches
Mail list logo
