Re: [OT] TDD only works for simple things...

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.

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

ugh, sorry, WAY too early in the morning. If the installer needs a module in order to run, it has nothing to fall back on to supply that module for it. Any surrounding client doing a recursive installation can't fix it, unless what it can do when the installer runs and says that the distributi

Re: Testing with Apache/mod_perl

Oops, didn't reply to all... A-T is nothing if not flexible. That the _option_ to trade off speed for flexibility isn't as easy as I personally would like it to be, rather than that it doesn't address any given known scenario. really, I don't know what you're saying, but it sounds vaguely li

Re: Testing with Apache/mod_perl

we should keep this on list :) Adam Kennedy wrote: > > > Geoffrey Young wrote: > >> >> Adam Kennedy wrote: >> >>> I'd also add a small warning in that Apache::Test does seem to want to >>> dominate the entire test suite (run everything from TEST) and so may not >>> be as suitable in cases where

Re: Module requirements (was: Module::Build and installing in non-standardlocations)

Randy W. Sims wrote: Adam Kennedy wrote: >> There are a number of ways to do this. The most simple is: >> >> use strict; >> use warnings; >> >> use File::HomeDir; >> my $conf_dir = File::Spec->catdir( File::HomeDir->my_home, '.Foo' ); > > > Not that I wish to be a pedant about this, but

RE: [OT] TDD only works for simple things...

I would classify what Adam does as "robustness" testing. Often the first release can be classified as "working, in a perfect world". Adam lives in a World of Evil. Let me expand. For most of us (this means "Not Adam"), we work during the Day and rest at Night. We don't call it "Day" and "Not D

Re: [OT] TDD only works for simple things...

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

Re: [OT] TDD only works for simple things...

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

Re: Module::Build and installing in non-standard locations

On Thu, 30 Mar 2006, Randy W. Sims wrote: > Note that the entries in install_path must have the same name as > supplied to add_build_element() (not with the '_files' appendage). OK - thanks again, that is my problem... the naming of the entries... I was too dense to appreciate your note about th

Re: Module::Build and installing in non-standard locations

Matisse Enzer wrote: On Tue, 28 Mar 2006, Randy W. Sims wrote: There are a number of ways to do this. The most simple is: use strict; use warnings; use File::HomeDir; my $conf_dir = File::Spec->catdir( File::HomeDir->my_home, '.Foo' ); use Module::Build; my $builder = Module::Build->new(

Re: Module::Build and installing in non-standard locations

On Tue, 28 Mar 2006, Randy W. Sims wrote: > There are a number of ways to do this. The most simple is: > > use strict; > use warnings; > > use File::HomeDir; > my $conf_dir = File::Spec->catdir( File::HomeDir->my_home, '.Foo' ); > > use Module::Build; > my $builder = Module::Build->new( >

Re: [OT] TDD only works for simple things...

> "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

Module requirements (was: Module::Build and installing in non-standard locations)

Adam Kennedy wrote: >> There are a number of ways to do this. The most simple is: >> >> use strict; >> use warnings; >> >> use File::HomeDir; >> my $conf_dir = File::Spec->catdir( File::HomeDir->my_home, '.Foo' ); > > > Not that I wish to be a pedant about this, but only so people keep it in > min

Re: [OT] TDD only works for simple things...

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'

Re: [perl #38810] [PATCH] skip #7 t/dynoplibs/myops.t for mingw

> Thanks, I've applied the patch in SVN revision 12077. Thanks too. > I only replaced the package variables with lexical ones. I copy and paste from os.t > Could you check whether this works now under MinGW? Seems ok. See smoke results, i386-MSWin32-gcc Parrot 0.4.2 r12077 30 Mar 2006 00:16 Thu.

Re: [OT] TDD only works for simple things...

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

Re: [OT] TDD only works for simple things...

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.

Re: [OT] TDD only works for simple things...

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

Re: Testing with Apache/mod_perl

Adam Kennedy wrote: > I'd also add a small warning in that Apache::Test does seem to want to > dominate the entire test suite (run everything from TEST) and so may not > be as suitable in cases where you have 50-500 test scripts already, and > you just want a few to work with Apache::Test and a n

Re: Testing with Apache/mod_perl

I'd also add a small warning in that Apache::Test does seem to want to dominate the entire test suite (run everything from TEST) and so may not be as suitable in cases where you have 50-500 test scripts already, and you just want a few to work with Apache::Test and a normal Makefile.PL built wi

Re: [PATCH] Forking tests with Test::More

Well, the author of Test::More seems to differ on that: Although personally I'd think I'd read into that, that forking shouldn't cause problems, with "and you should be able to emit test output on both sides" as a bonus extended DWIM fea

Re: [OT] TDD only works for simple things...

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

Re: Module::Build and installing in non-standard locations

There are a number of ways to do this. The most simple is: use strict; use warnings; use File::HomeDir; my $conf_dir = File::Spec->catdir( File::HomeDir->my_home, '.Foo' ); Not that I wish to be a pedant about this, but only so people keep it in mind... This installer will crash with a non-

Feature freeze

The next release will be rolled out this weekend. The usual terms apply: * no feature changes to Parrot core incl. build * bug and docu fixes welcome leo

Re: Perl 6 on Solaris 10 anyone ?

Great, thanks a lot for answers. I will have to setup myself a test environment for Perl 6. I will report later my findings about this project. The goal would be to stay and test as much as I can Perl 6 under Solaris 10 and Express. I have AMD64 systems running Solaris so this would be the main pl