On 12/03/2009 04:08 PM, Benji York wrote:
> On Thu, Dec 3, 2009 at 9:43 AM, Marius Gedminas 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
On Thu, Dec 3, 2009 at 9:43 AM, Marius Gedminas 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. One day.
--
Ben
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
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 p
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 with
On Wed, Dec 2, 2009 at 5:06 PM, 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
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?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ross Patterson wrote:
> Tres Seaver 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' option to the
Benji York writes:
> On Wed, Dec 2, 2009 at 1:22 PM, Ross Patterson 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,
On Wed, Dec 2, 2009 at 1:22 PM, Ross Patterson 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 DB connections,
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 a
Tres Seaver 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 closing the
-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, s
13 matches
Mail list logo