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
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
29 matches
Mail list logo
