On 30 Mar 2006 07:02:21 -0800, Randal L. Schwartz wrote:
> > "demerphq" == demerphq <[EMAIL PROTECTED]> writes:
>
> demerphq> While apparently some on this list apparently dont favour this
> demerphq> approach, im pretty much at a loss to come with a better way to test
> demerphq> the module.
bject approach to be superb - and usually part of the TDD development cycles
where time permits.
Leif
-Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, 31 March 2006 1:54 PM
To: [EMAIL PROTECTED]
Cc: perl-qa@perl.org; [EMAIL PROTECTED]
Subject: Re:
Tels wrote:
Moin,
On Thursday 30 March 2006 17:32, Adam Kennedy wrote:
[snip]
Calling ->method( \"" ) or ->method( \undef ) or ->method ( sub { die
"foo" } ) and a dozen other things like that is intentionally provoking
that code into blowing up.
This are good things, but checking every param
Well, the weakness I speak of is not so much that that it will never get
to the point of being stable, but that it introduces a temptation to
release early without taking the time to critically look at what might
go wrong, based on your knowledge of how it is implemented.
So more of a timing t
> "demerphq" == demerphq <[EMAIL PROTECTED]> writes:
demerphq> While apparently some on this list apparently dont favour this
demerphq> approach, im pretty much at a loss to come with a better way to test
demerphq> the module.
Did you also look at Devel::Cover, to see if your tests tickle th
On Thursday 30 March 2006 07:32, Adam Kennedy wrote:
> In contrast, as I hear chromatic express it, TDD largely involves
> writing tests in advance, running the tests, then writing the code.
Not quite. It means writing just enough tests for the next testable piece of
the particular feature you'
Adam Kennedy wrote:
- It can test the things you know that work.
- It is good when testing the things you know that don't work (its
strong point)
- It is not good for testing the things you don't know that don't work.
This implies that TDD is about code quality. For me, I find that a big
par
Moin,
On Wednesday 29 March 2006 22:44, Andrew Savige wrote:
> --- Tels wrote:
> > although I still can only guess what TDD stands for :)
>
> Tolkien Driven Development?
>
> Googling around for examples of real world large systems developed
> using TDD, I found http://www.agiledata.org/essays/tdd.
Moin,
On Thursday 30 March 2006 17:32, Adam Kennedy wrote:
[snip]
> Calling ->method( \"" ) or ->method( \undef ) or ->method ( sub { die
> "foo" } ) and a dozen other things like that is intentionally provoking
> that code into blowing up.
This are good things, but checking every param on every
The one thing I don't really like very much about TDD is that in a
loosely typed language I suspect if suffers.
Specifically...
- It can test the things you know that work.
- It is good when testing the things you know that don't work (its
strong point)
- It is not good for testing the things
On Wednesday 29 March 2006 19:15, Tels wrote:
> Anyway, I hope my longer replay was usefull and helped a bit, although I
> still can only guess what TDD stands for :)
>
TDD == Test Driven Development.
Regards,
Shlomi Fish
-
--- Tels wrote:
> although I still can only guess what TDD stands for :)
Tolkien Driven Development?
Googling around for examples of real world large systems developed
using TDD, I found http://www.agiledata.org/essays/tdd.html which
states:
The first reaction that many people have to agile tec
On 3/28/06, David Cantrell <[EMAIL PROTECTED]> wrote:
> Geoffrey Young wrote:
>
> >> "Only the simplest of designs benefits from pre-coded tests, unless you
> >> have
> >> unlimited developer time."
> > needless to say I just don't believe this.
>
> Try writing a test suite ahead of time for a gra
Moin,
On Tuesday 28 March 2006 20:01, Fergal Daly wrote:
> On 3/28/06, Tels <[EMAIL PROTECTED]> wrote:
> > Moin,
> >
> > On Tuesday 28 March 2006 17:14, Fergal Daly wrote:
> > > I don't know of examples off-hand but I think in a way they're
> >
> > [snipabit]
> >
> > > Also, the problem with php (
Moin,
On Tuesday 28 March 2006 20:11, Fergal Daly wrote:
> On 3/28/06, David Cantrell <[EMAIL PROTECTED]> wrote:
> > Geoffrey Young wrote:
> > > David Cantrell wrote:
> > >>Try writing a test suite ahead of time for a graphing library.
> > >> It's possible (indeed, it's trivial - just check the m
On Tuesday 28 March 2006 06:11, Geoffrey Young wrote:
> "Only the simplest of designs benefits from pre-coded tests, unless you
> have unlimited developer time."
"If you think TDD is expensive, try debugging."
Greg's comments give me the impression that he thinks TDD means writing a
whole pile
On 3/28/06, David Cantrell <[EMAIL PROTECTED]> wrote:
> Geoffrey Young wrote:
> > David Cantrell wrote:
> >>Try writing a test suite ahead of time for a graphing library. It's
> >>possible (indeed, it's trivial - just check the md5 hashes of the images
> >>that are spat out against images that you
On 3/28/06, Tels <[EMAIL PROTECTED]> wrote:
> Moin,
>
> On Tuesday 28 March 2006 17:14, Fergal Daly wrote:
> > I don't know of examples off-hand but I think in a way they're
> [snipabit]
> > Also, the problem with php (assuming you use it as a webpage
> > generator) is that it encourages you to emb
Geoffrey Young wrote:
> "Only the simplest of designs benefits from pre-coded tests, unless
you have
unlimited developer time."
needless to say I just don't believe this. but as I try to broach the
test-driven development topic with folks I hear this lots - not just that
they don't have the t
Ben Evans wrote:
Strawman.
Ad hominem.
A graphing library is an obvious example where functional testing should be
used prior to automated regression testing.
Yes. It is one of many such examples. It just happens to be the one I
am working on as we speak.
--
David Cantrell
Moin,
On Tuesday 28 March 2006 17:14, Fergal Daly wrote:
> I don't know of examples off-hand but I think in a way they're
[snipabit]
> Also, the problem with php (assuming you use it as a webpage
> generator) is that it encourages you to embed code in your HTML and so
> yes, it is naturally diffic
Geoffrey Young wrote:
David Cantrell wrote:
Try writing a test suite ahead of time for a graphing library. It's
possible (indeed, it's trivial - just check the md5 hashes of the images
that are spat out against images that you have prepared ahead of time in
some other way) but it would be damna
Moin,
On Tuesday 28 March 2006 16:11, Geoffrey Young wrote:
> hi all :)
>
> for those interested in both php and perl, it seems that php's native
> .phpt testing feature will soon produce TAP compliant output - see greg
> beaver's comments here
>
> http://shiflett.org/archive/218#comments
>
> so
On Tue, Mar 28, 2006 at 05:47:29PM +0100, David Cantrell wrote:
> Geoffrey Young wrote:
>
> >> "Only the simplest of designs benefits from pre-coded tests, unless you
> >> have
> >> unlimited developer time."
> > needless to say I just don't believe this.
>
> Try writing a test suite ahead of ti
Geoffrey Young wrote:
"Only the simplest of designs benefits from pre-coded tests, unless you have
unlimited developer time."
needless to say I just don't believe this.
Try writing a test suite ahead of time for a graphing library. It's
possible (indeed, it's trivial - just check the md5 ha
David Cantrell wrote:
> Geoffrey Young wrote:
>
>>> "Only the simplest of designs benefits from pre-coded tests, unless
>>> you have
>>> unlimited developer time."
>>
>> needless to say I just don't believe this.
>
>
> Try writing a test suite ahead of time for a graphing library. It's
> poss
I don't know of examples off-hand but I think in a way they're
correct. If you write lots of code first and then try to test it, you
will look and say "it's not possible to test this so I could not
possibly have written my tests beforehand - those TDD guys are fools".
If you write the tests beforeh
hi all :)
for those interested in both php and perl, it seems that php's native .phpt
testing feature will soon produce TAP compliant output - see greg beaver's
comments here
http://shiflett.org/archive/218#comments
so, TAP is slowly dominating the world... but we all knew that already :)
wha
28 matches
Mail list logo
