Re: Dealing with balls o' mud (was: Re: Test::Builder feature request)

2007-01-15 Thread Matisse Enzer
Another vote here for Working Effectively with Legacy Code On Jan 14, 2007, at 10:35 AM, Michael G Schwern wrote: ... (where's my refactoring browser!?) http://e-p-i-c.sourceforge.net/ Eclipse plugin for Perl. Provides extract subroutine using Devel::Refactor. I believe Jeff Thalhammer

Dealing with balls o' mud (was: Re: Test::Builder feature request)

2007-01-14 Thread Michael G Schwern
[EMAIL PROTECTED] wrote: 1. To test the code, you need to change it. 2. Before changing the code, you should test it. How do we resolve these two opposites ? We change as little as possible. *snip* A lot of my more recent thoughts about testing and development have come from a wonderful

Re: Dealing with balls o' mud (was: Re: Test::Builder feature request)

2007-01-14 Thread Ovid
--- Michael G Schwern [EMAIL PROTECTED] wrote: I've thought things like that in the past, innocent refactorings, and broke shit. Especially since they have to be done by hand (where's my refactoring browser!?) At absolute minimum, with a big ball of mud, you can do dumb high level exact

Re: Test::Builder feature request

2007-01-13 Thread James E Keenan
chromatic wrote: the Star Trek: Generations fallacy. You steal a spaceship, which flies through space, to fly through space to a planet, flying through space, where a temporal anomaly, which also flies through space, deflected by a supernova, which you flew through space in your spaceship

RE: Test::Builder feature request

2007-01-13 Thread leif . eriksen
::Builder feature request --- [EMAIL PROTECTED] wrote: I think code under test that has if I'm under test statements is intrinsically weak. You want to test what it does, not what it does when under test. Changing the code for testing means your not really testing it , your testing a variation

Re: Test::Builder feature request

2007-01-12 Thread Michael G Schwern
chromatic wrote: (I know; it's not exactly what you were asking. I just wanted to get that in a public mailing list so I could call that the Star Trek: Generations fallacy. You steal a spaceship, which flies through space, to fly through space to a planet, flying through space, where a

Re: Test::Builder feature request

2007-01-11 Thread Nadim Khemir
On Thursday 11 January 2007 15:30, Ovid wrote: Quite often people will write code which tests to see if $ENV{HARNESS_ACTIVE} is true. For example, this allows them to not email support from their code while testing. This variable is set in Test::Harness. However, this causes a problem when

Re: Test::Builder feature request

2007-01-11 Thread Ovid
--- Nadim Khemir [EMAIL PROTECTED] wrote: On Thursday 11 January 2007 15:30, Ovid wrote: Quite often people will write code which tests to see if $ENV{HARNESS_ACTIVE} is true. For example, this allows them to not email support from their code while testing. This variable is set in

Re: Test::Builder feature request

2007-01-11 Thread Paul Johnson
On Thu, Jan 11, 2007 at 09:04:54AM -0800, Ovid wrote: --- Nadim Khemir [EMAIL PROTECTED] wrote: On Thursday 11 January 2007 15:30, Ovid wrote: Quite often people will write code which tests to see if $ENV{HARNESS_ACTIVE} is true. For example, this allows them to not email support

Re: Test::Builder feature request

2007-01-11 Thread Ovid
--- Paul Johnson [EMAIL PROTECTED] wrote: Now I can see uses for knowing whether or not you are being run as part of an installation, or in some automated environment, and I can imagine someone would have a use for HARNESS_ACTIVE, though I can't see it myself, but I'm not sure this is it.

Re: Test::Builder feature request

2007-01-11 Thread Nadim Khemir
On Thursday 11 January 2007 18:04, Ovid wrote: Just one, Shouldn't the mailer object be mocked and the mail sending checked? absolutely, but how do you know to mock it or really send the email unless you know that you're being run by tests? Aren't you mixin contexts here? The code to be

Re: Test::Builder feature request

2007-01-11 Thread Smylers
Nadim Khemir writes: On Thursday 11 January 2007 18:04, Ovid wrote: Just one, Shouldn't the mailer object be mocked and the mail sending checked? absolutely, but how do you know to mock it or really send the email unless you know that you're being run by tests? Aren't you mixin

Re: Test::Builder feature request

2007-01-11 Thread chromatic
On Thursday 11 January 2007 06:30, Ovid wrote: Quite often people will write code which tests to see if $ENV{HARNESS_ACTIVE} is true.  For example, this allows them to not email support from their code while testing.  This variable is set in Test::Harness.  However, this causes a problem when

RE: Test::Builder feature request

2007-01-11 Thread leif . eriksen
means your not really testing it , your testing a variation of it. Leif -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, 12 January 2007 11:04 AM To: perl-qa@perl.org Subject: Re: Test::Builder feature request Nadim Khemir writes: On Thursday 11 January

RE: Test::Builder feature request

2007-01-11 Thread Ovid
--- [EMAIL PROTECTED] wrote: I think code under test that has if I'm under test statements is intrinsically weak. You want to test what it does, not what it does when under test. Changing the code for testing means your not really testing it , your testing a variation of it. I completely

Re: Test::Builder feature request...

2006-07-06 Thread Michael G Schwern
On 2/9/06, Geoffrey Young [EMAIL PROTECTED] wrote: This works: yes, excellent randy. thanks for that. it still seems a little hackish but that's ok - hackish works for me if it means I can do what I want and nobody else needs to do extra work :) I made some tweaks to your format and added a

Re: Test::Builder feature request...

2006-07-06 Thread Geoffrey Young
Michael G Schwern wrote: On 2/9/06, Geoffrey Young [EMAIL PROTECTED] wrote: This works: yes, excellent randy. thanks for that. it still seems a little hackish but that's ok - hackish works for me if it means I can do what I want and nobody else needs to do extra work :) I made some

Re: Test::Builder feature request...

2006-02-09 Thread Geoffrey Young
One of the problems is going to be numbering, surely? but it shouldn't need to be, right? I mean, TAP is merely a protocol and there shouldn't be a requirement that the bookkeeping happen in the same process as the TAP emitting process I wouldn't think. in fact, if someone were implementing

Re: Test::Builder feature request...

2006-02-09 Thread Adam Kennedy
Randy W. Sims wrote: Adam Kennedy wrote: Randy W. Sims wrote: Adam Kennedy wrote: This works: ---test.pl--- use Test::More tests = 1; my $Test = Test::More-builder; my $counter = $Test-current_test; print qx!perl t/response.pl!; $Test-current_test($counter + 1); But why 1? Why not

Test::Builder feature request...

2006-02-08 Thread Geoffrey Young
hi all :) there's a feature split I'm itching for in Test::Builder, etc - the ability to call is() and have it emit TAP free from the confines of plan(). not that I don't want to call plan() (or no_plan) but I want to do that in a completely separate perl interpreter. for example, I want to do

Re: Test::Builder feature request...

2006-02-08 Thread David Wheeler
On Feb 8, 2006, at 11:41, Geoffrey Young wrote: so, I guess my question is whether the plan-is linkage can be broken in Test::Builder/Test::Harness/wherever and still keep the bookkeeping in tact so that the library behaves the same way for the bulk case. or maybe at least provide some

Re: Test::Builder feature request...

2006-02-08 Thread Geoffrey Young
so, thoughts or ideas? am I making any sense? Yes, you are. *whew* :) I think that the subprocess can load Test::More and friends like this: use Test::More no_plan = 1; Test::More-builder-no_header(1); cool, thanks. That will set No_Plan, Have_Plan, and No_Header to true,

Re: Test::Builder feature request...

2006-02-08 Thread Adam Kennedy
Geoffrey Young wrote: hi all :) there's a feature split I'm itching for in Test::Builder, etc - the ability to call is() and have it emit TAP free from the confines of plan(). not that I don't want to call plan() (or no_plan) but I want to do that in a completely separate perl interpreter.

Re: Test::Builder feature request...

2006-02-08 Thread Randy W. Sims
Adam Kennedy wrote: Geoffrey Young wrote: hi all :) there's a feature split I'm itching for in Test::Builder, etc - the ability to call is() and have it emit TAP free from the confines of plan(). not that I don't want to call plan() (or no_plan) but I want to do that in a completely separate

Re: Test::Builder feature request...

2006-02-08 Thread David Wheeler
On Feb 8, 2006, at 12:41, Geoffrey Young wrote: with your suggestion I'm almost there: 1..1 ok 1 - this was a passing test # No tests run! What parts do you want left out? Best, David

Re: Test::Builder feature request...

2006-02-08 Thread Adam Kennedy
This works: ---test.pl--- use Test::More tests = 1; my $Test = Test::More-builder; my $counter = $Test-current_test; print qx!perl t/response.pl!; $Test-current_test($counter + 1); But why 1? Why not 5? or 10? __END__ ---response.pl--- use Test::More no_plan = 1;

Re: Test::Builder feature request...

2006-02-08 Thread Randy W. Sims
Adam Kennedy wrote: This works: ---test.pl--- use Test::More tests = 1; my $Test = Test::More-builder; my $counter = $Test-current_test; print qx!perl t/response.pl!; $Test-current_test($counter + 1); But why 1? Why not 5? or 10? It has to be set to the number of tests run in the

Re: Test::Builder feature request...

2006-02-08 Thread Fergal Daly
On 2/8/06, Adam Kennedy [EMAIL PROTECTED] wrote: Geoffrey Young wrote: hi all :) there's a feature split I'm itching for in Test::Builder, etc - the ability to call is() and have it emit TAP free from the confines of plan(). not that I don't want to call plan() (or no_plan) but I want

Re: Test::Builder feature request...

2006-02-08 Thread Randy W. Sims
Adam Kennedy wrote: Randy W. Sims wrote: Adam Kennedy wrote: This works: ---test.pl--- use Test::More tests = 1; my $Test = Test::More-builder; my $counter = $Test-current_test; print qx!perl t/response.pl!; $Test-current_test($counter + 1); But why 1? Why not 5? or 10? It has to