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 Thalhamm
--- 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
[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 wond
ke another chunk, repeat till you have a 500 line subroutine with some
semi-meaningful calls to nicely tested functions. And so on.
Enough preaching - the oven says my pies are ready!!
Leif
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, 12 January 200
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
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
Hi,
On Friday 12 January 2007 01:49, [EMAIL PROTECTED] wrote:
> You don’t have to use objects to get the same end effects as mocking
> objects.
Right!
Now, as my "devil's advocate" signature tried to show, this thread is for the
fun of the discussion. I'm sure all of use, and Ovid more than th
--- [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 compl
, not "what it does when
under test". Changing the code for testing 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:
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 w
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?
>
> Ar
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
--- 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 i
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
> > > e
--- 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
>
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 wh
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 someone
accidentally does this:
perl t/email_supp
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
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
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 n
>> 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
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
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)
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 o
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;
Test::More->bui
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
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 p
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. for
>> 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_Hea
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 optio
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 s
31 matches
Mail list logo
