hi all :)
quite honestly, I'm completely perplexed by this entire discussion. the
people involved are very smart, so I find myself scratching my head as
to the disconnect...
is bail out not a part of the TAP specification? according to
http://podwiki.hexten.net/podwiki.pl?page=TAP
TAP c
chromatic wrote:
On Monday 14 January 2008 15:42:49 Adam Kennedy wrote:
Test::Builder should just do what it's told.
If the code that IS responsible for testing suites tells it to bail on
fail, that's exactly what it should do.
Let me rephrase this in an amusing way which demonstrates how
Still curious - perhaps you can explain more about why you think this is
useful thing.
it's useful to me because I say it is. personally I don't feel the need
to defend something many people would like to see this like we're being
forced to here. schwern has a valid point in not wanting to
There are two usual rebuttals.
the third being "just add it and let me decide"
:)
--Geoff
Ovid wrote:
I've posted a trimmed down version of the custom 'Test::More' we use
here:
http://use.perl.org/~Ovid/journal/35363
I can't recall who was asking about this, but you can now do this:
use Our::Test::More 'no_plan', 'fail';
If 'fail' is included in the import list, the test pro
A. Pagaltzis wrote:
> * Michael G Schwern <[EMAIL PROTECTED]> [2007-12-06 06:35]:
>> Right now you have to write this:
>>
>> use Test::More;
>>
>> if( $^O eq 'SomeOS' ) {
>> plan skip_all => "Tests don't apply to SomeOS":
>> }
>> else {
>> plan tests => 3;
>> }
>>
>> It's ug
Michael G Schwern wrote:
> Geoffrey Young wrote:
>> Andy Armstrong wrote:
>>> On 4 Dec 2007, at 15:22, Geoffrey Young wrote:
>>>> it would be nice if this were enforced on the TAP-digestion side and not
>>>> from the TAP-emitter side - the coupling o
Andy Armstrong wrote:
> On 4 Dec 2007, at 15:22, Geoffrey Young wrote:
>> it would be nice if this were enforced on the TAP-digestion side and not
>> from the TAP-emitter side - the coupling of TAP rules within the
>> TAP-emitter is what lead to my trouble in the first p
> Since the technical restriction is gone, and I see no particular benefit to it
> being there, and it eliminates some tricky plan counting situations, I don't
> see why it shouldn't be removed.
this would be great, and help with situations like this:
http://www.nntp.perl.org/group/perl.qa/200
Matisse Enzer wrote:
>
> On Nov 18, 2007, at 3:50 AM, Michael G Schwern wrote:
>
>>
>> I start at the top, read the first few failures, fix them and rerun.
>> I ignore
>> the bulk of a really large failure as they're probably just cascades
>> of the
>> one mistake.
>
> This reminds me - I was
> The metric will be called prereq_matches_use and shall check if all the
> modules used in a dist are also listed as a prereq.
I find this odd.
if I check a prereq for mod_perl (.pm) I know I have the 50 some modules
that come with a mod_perl distribution. check for LWP and I know I have
HTTP
> Honestly, just convert to TAP::Parser. Straps has no future.
Apache-Test subclasses Straps to override _command_line() and provide
php as the test caller (so you can run t/foo.php with php instead of perl).
unfortunately for us, the magic required for this to work with Straps
isn't straightfo
> I will be covering some of these coverage reporting options at PPW. If
> you have actual use cases, please post. Thank you very much.
coverage for xs was really hard for me to figure out... until paul
pointed me toward the gcov2perl manpage, where I learned that
$ cover -test
tool care of
James E Keenan wrote:
> I have had a proposal accepted to do a presentation at the Pittsburgh
> Perl Workshop (Oct 13-14) on "Better Code via Coverage Analysis during
> Testing" (http://pghpw.org/ppw2007/talk/725).
>
> During this presentation I hope to:
>
> 1. Channel pjcj to the best of my a
Scott McWhirter wrote:
> This would be easy to do in Test::Builder within &Test::Builder::ok by
> making it call $Test->BAIL_OUT();
>
> Then at least you would get it across all Test::* modules.
yeah, that's what I was implying in my followup message.
the attached patch against 0.70 seems to d
Ovid wrote:
> --- Geoffrey Young <[EMAIL PROTECTED]> wrote:
>
>> I'd like Test::* to completely bailout on the first is/ok/whatever to
>> fail. I just can't seem to find a canonical way to do this. but
>> someone here knows, I'm sure :)
>
>
hi all :)
this sounds so simple it must be covered someplace, but I just can't
find it at the moment, so...
I have a truckload of tests in a single file. of the iterative sort,
lest you think I'm a bit insane :) anyway, some have started randomly
failing and I'd like to examine why via verbose
Dhaval Shah wrote:
> I am trying to create a code coverage report on my web server running
> mod_perl.
>
> As suggested in Devel::Cover and installing it, I have inserted "use
> Devel::Cover" in startup.pl and restart my apache. This is what I get:
> Even though I run my tests [which are browse
Adrian Howard wrote:
>
> On 19 Mar 2007, at 12:51, Geoffrey Young wrote:
>
>> hi all...
>>
>> it's really hard to wade through the flurry of activity of late, but is
>> the consideration really to alter current TAP to make it look like YAML?
>
&g
hi all...
it's really hard to wade through the flurry of activity of late, but is
the consideration really to alter current TAP to make it look like YAML?
I know this came up here before, and I thought there was a general
consensus that YAML is really only conventient for perl, that moving
away f
> There ought to be a way to capture diagnostic information in the TAP stream
> because it's useful for diagnosing problems.
I feel like I'm talking to myself when I say this (since I've said this
before) but I'll say it again just, well, because :)
the implicit idea that STDERR generally goes
Ovid wrote:
> If you want things to be *really* easy to run test suites in multiple
> languages, do this.
another option is this:
http://people.apache.org/~geoff/test-more-separately.tar.gz
which illustrates how to separate planning, etc in perl but use a
foreign tap producing faile - somethin
sorry to chime in late...
> FWIW, I like the tabular output. How about something like:
>
> TestTotal Failed List of Failed TODO Passed
> ---+---+--+--+
> t/bar.t 13 9 2, 6-8, 13, 17, 33-35 3-4
> t/foo.t 10 10 5, 19,
> Its been doing that for the last 10 years or so. Try an espresso.
yeah, ok.
> Apache::Test, by default, sends diagnostics to STDERR. This is because
> by default it uses Test.pm which sends its errors to STDERR.
right. I haven't actually used the Test.pm interface in ages. but most
other
> $ perl -MTest::Harness -wle 'runtests @ARGV' ~/tmp/stdout.t
> /Users/schwern/tmp/stdoutdubious
>Test returned status 1 (wstat 256, 0x100)
> DIED. FAILED test 1
>Failed 1/1 tests, 0.00% okay
> Failed Test Stat Wstat Total
Adrian Howard wrote:
>
> On 16 Aug 2006, at 14:45, Geoffrey Young wrote:
> [snip]
>
>> I dunno, but I think the ability to
>> integrate like this is something that would make a killer feature if
>> folks figured out how to leverage (and market) it.
>
>
&g
> Trouble is at the moment all this is still in the prototype stage.
> And none of them are killer.
supporting TAP means you can integrate with Test::Harness. now, I know
that might not seem like much, but we've got quite the number of mature
testing tools over in perl-land that are pretty cool.
Jonathan Rockway wrote:
> While I agree with David, this argument is almost completely pointless.
> Nobody reads the raw TAP output!
are you serious? listen to what they people here are saying - we _all_
read the raw TAP output, all the time, and not because we're TAP
developers interested in th
> However, most perl tests don't care about TAP, they use Test::More and
> Test::Harness and happen to exchange data via TAP. If Test::More and
> Test::Harness decied to use "YAP" (YAML Anything Protocol? :), then most
> applications would probably never notice.
most _perl_ applications would ne
Ovid wrote:
> - Original Message From: Jonathan Rockway <[EMAIL PROTECTED]>
>
>> What else is TAP targeted to? C / C++ / Java?
>
>
> PHP tests often use TAP (don't know the name)
almost all of the php test frameworks now offer TAP support - see
http://search.cpan.org/dist/Test-Harn
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 w
Geoffrey Young wrote:
> I've mentioned the idea of making it simple to use
> plan() and Test::More functions before
blarg... insert "separately" ^ here. all the rest is pretty simple
already :)
--Geoff
sorry for dropping in on this late, but it was a holiday weekend :)
> * How can I help?
>
> Provide use cases, what would you want to do with Test::Harness if you
> could? What are you doing with Straps? What features do other
> testing systems (JUnit, for example) have that you'd like to see i
hi all :)
so, as a standard practice, I start with
use_ok($class);
as the first test in each file, the idea being that if the class doesn't
compile I shouldn't care about the results of the rest of the test - I
know immediately that subsequent failures are because I introduced a
typo or someth
Nik Clayton wrote:
> Geoffrey Young wrote:
>
>>> Since you're using C++, you can probably use libtap
>>> (http://www.onlamp.com/pub/a/onlamp/2006/01/19/libtap.html and
>>> http://jc.ngo.org.uk/trac-bin/trac.cgi/wiki/LibTap) for writing the
>>> te
> Since you're using C++, you can probably use libtap
> (http://www.onlamp.com/pub/a/onlamp/2006/01/19/libtap.html and
> http://jc.ngo.org.uk/trac-bin/trac.cgi/wiki/LibTap) for writing the tests and
> then you could use a Perl harnes to collect those results.
just out of curiosity, has anyone got
Pete Krawczyk wrote:
> Subject: skip_all with Test::More?
> From: Tels <[EMAIL PROTECTED]>
> Date: Wed, 31 May 2006 17:53:46 +0200
>
> }
> }use Test::More;
> }
> }plan tests => 123;
> }
> }skip_all( 'reason' ) if ...;
> }
> }# tes
Adam Kennedy wrote:
>
>>> Schwern made one small change in the STDERR format, and the recursive
>>> cascade of failing test-testing modules hit something like 3000 CPAN
>>> distributions.
>>
>>
>> While I agree that this caused problems, those modules were relying on a
>> format that was not spe
chromatic wrote:
> On Monday 17 April 2006 18:50, Ovid wrote:
>
>
>>The only problem I see with that is the occasional buffering errors I
>>see on my Mac where the STDERR and STDOUT don't line up.
>
>
> Agreed. Is it too late to send everything to STDOUT where it belongs?
just for everyone'
Andy Lester wrote:
>
> I'm adding a section to Test::Harness::TAP on non-Perl TAP.
>
> http://svn.perl.org/modules/Test-Harness/trunk/lib/Test/Harness/TAP.pod
>
> If you know of one, please send me some text to add.
all the big PHP players now produce TAP
o phpt (outputs TAP by default as
>
> A-T requires me to do things differently, and it's that difference that
> introduces the lack of flexibility.
I had a bunch of foo written that I removed, mainly because this is the real
issue, for you I guess - the idea that different is somehow bad or
inflexible, that anyone who creates so
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
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
> Apache::Test looks like it might be the way to go. But it doesn't seem
> to play very nicely with Test::More,
that's not really true. yes, Apache-Test was based on Test.pm (for various
reasons I won't get into here) but I added Test::More support and use it all
the time. grep for stuff lik
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.
>
>
>
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
>>> I've long intended to take t/test.pl from the Perl core distribution
>>> and wrap
>>> up at least its runperl() in a Test:: module. Perhaps that would
>>> work for
>>> you?
>>
>>
>> compile_ok() ?
>>
>> --Geoff
>>
>
> It is unclear from Geoff's message above whether he is asserting that
>
chromatic wrote:
> On Wednesday 15 March 2006 12:25, Jeffrey Thalhammer wrote:
>
>
>>I'm sure I could clean this up by opening a pipe
>>instead of using backticks and output redirection.
>>But even that doesn't smell very good. I've looked
>>around on CPAN, but I have not yet found a Test::
>>
>> 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
>> 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
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
> Nice work, Geoff
:)
>
> A few issues:
>
> 1)
>
> % make testcover
> Cannot run testcover action unless Devel::Cover is installed
>
> and after installing Devel::Cover it still gives the same error, since
> it's hardcoded in Makefile.PL. May be adding a check and suggesting to
> rebuild Mak
hi all :)
I just commited a patch to Apache-Test in svn that removes all the
additional work involved with getting Devel::Cover to work for server side
tests. now a simple 'make testcover' should be all you need to do to get
coverage results from code within handler() subroutines - no more adding
> No, not when I run the example out of the box - I had to move the
> PerlPassEnv directives to extra.conf.in and rebuild (this makes sense,
> though, as extra.conf is processed before modperl_extra.pl, while
> extra.last.conf is processed after - perhaps you fixed your local copy and
> haven't up
Hilary Holz wrote:
Okay - here's what I've figured out - D::C is not recording any coverage
info when I run a test in t/apache. D::C is recording coverage for all the
tests that are in the t/ directory - and the reports are in the realm of the
reasonable.
Have you had D::C collect coverage sta
> [snip - ah, helpful, now I understand how to use the testcover target]
:)
> Devel::Cover is reporting
> 100% statement coverage for a number of modules for which there are no tests
> as of yet (legacy modules I have yet to revisit)
I don't think that's unusual - D::C will aggregate all the r
> I'd really love to use Devel::Cover - I love the effect mastering the
> request/response Apache::Test framework has had on my code, and I really
> want to start using code coverage as part of my toolkit.
yah, this is a bit more complex than it probably ought to be, but I guess
that's by design.
Andy Lester wrote:
>> yeah, well, you could say that. last time I installed my washer I said
>> "looks pretty level to me, but I know where my level is if it makes a
>> racket"
>
>
> That's fine, but I'm still not shipping my washing machines without
> explicit instructions to level the dam
Andy Lester wrote:
>> Usually, Test::* modules are only used for the test phase.
>
>
> I really don't understand the idea of "only used for the test phase",
there is clearly a distinction between the code required for a given module
to compile and run in a production environment and the code r
They add some value to me (show that at least something works).
>>>
>>>Either they're valuable enough that you install their prerequisites or
>>>they're not.
>
>
> But how am I supposed to find this out? I dont even know whether the
> required modules are used for the tests only, without di
Michael G Schwern wrote:
> What I'm looking for is ideas about more things it could do that would
> be useful for most testing libraries. What scaffolding do module authors
> find themselves implementing?
if there were a better way to do this:
push @ISA, qw(Test::Harness::Straps);
$Test:
> (I deliberately
> did *not* list IO::Capture as a prerequisite in Makefile.PL because I
> didn't want to force users to install that module. I simply wanted them
> to use it during testing and then throw it away.
this is the start of the right attitude I think - when your testing
environment r
> http://www.justatheory.com/code/Test.Simple-0.10/tests/index.html?
> verbose=1
that's just awesome :)
nice work.
--Geoff
>>> This seems unfortunate for at least two reasons:
>>> 1) it ends up taking a really long time to run the tests. At some
>>> point, maybe long enough that nightly tests become prohibitive (even
>>> more so for continuous integration).
> We have a substantial Perl code base (as I've said sever
Ricardo SIGNES wrote:
> Yesterday, hide gave me some sweet example code to use
> HTTP::Server::Simple and Test::WWW::Mechanize to test Rubric's CGI bits.
> I've started working with them, and they make me happy.
>
> I've realized that the server, which is forked from the test script,
> doesn't h
Vsevolod (Simon) Ilyushchenko wrote:
> Hi,
>
> I'd like to suggest a module that I came up with to test CGI file
> uploading logic. I have not found anything else like it.
have you seen Apache-Test yet?
http://search.cpan.org/dist/Apache-Test/
I find it hard to understand modules like this a
David Wheeler wrote:
> On May 5, 2005, at 04:26 , Adrian Howard wrote:
>
Here's a weird idea: how about the option of AJAXing the test
harness results back to a receiving server somewhere that
understands TAP? Bingo: TAP testing of JS embedded in web pages in
its native ha
David Wheeler wrote:
> On Apr 7, 2005, at 5:55 PM, Michael G Schwern wrote:
>
>> If you have isDeeply() there's little point to the eq* salad.
>
>
> Hrm, fair enough. I'll comment them out, then...
well, a few thoughts here...
as someone familiar with T::M and not javascript, were I to try t
> test => { TESTS => join ' ', map { glob } qw( t/*/*.t t/*/*/*.t ) },
but slashes aren't portable, right? I don't think you can get rid of
File::Spec.
> Also, I agree that the use-Test-Plan-after-Test-More caveat is icky.
well, it's a caveat, not a requirement :)
the way it works now is t
hi all :)
following up on the discussion from a few months ago but renewed over the
weekend, here is Test::Plan. basically all it does is carry over the exact
syntax and helper functions we are already using in Apache-Test land to the
greater community.
I'm still working up additional tests, but
Michael G Schwern wrote:
> On Sat, Mar 12, 2005 at 11:41:08PM -0500, Geoffrey Young wrote:
>
>>well, this syntax doesn't exist in Test::More at the moment (though I
>>probably should get around to a patch like I promised) - it's only in
>>Apache-Test.
>
&
Mark Stosberg wrote:
> On 2005-03-13, Geoffrey Young <[EMAIL PROTECTED]> wrote:
>
>>nevertheless, what you are replying to was just a discussion about a feature
>>that doesn't exist in the standard Test::More toolkit but was brought up
>>because Apache-Test&#
Ian Langworth wrote:
> On 12.Mar.2005 11:41PM -0500, Geoffrey Young wrote:
>
>
>>nevertheless, what you are replying to was just a discussion
>>about a feature that doesn't exist in the standard Test::More
>>toolkit but was brought up because Apache-Test's
Ian Langworth wrote:
> On 30.Nov.2004 09:57AM -0600, Andy Lester wrote:
>
>
>> plan tests => 14, have( "Foo::Wango" ), moon_phase eq "waning", etc;
>
>
> Where does the reason fit into this syntax?
well, this syntax doesn't exist in Test::More at the moment (though I
probably should get ar
Joe Schaefer wrote:
> we should be able to communicate TAP via HTTP, SMTP, etc.).
TAP::Lite anyone?
/me ducks
;)
--Geoff
> Hm, that does seem valuable. Should all test modules report their
> versions by default, though?
well, my thought was that it was more important to list the source of the
comparison operators the user uses (like is() or eq_array()) than it was the
internal stuff that, say, interfaces with Test
> This is helpful for processing bug reports, so I don't have to make
> second trip back to the user to ask: "What version of CGI.pm where you
> using?".
yeah, I'll second this, at least so far as adding a version component to
Test::More goes (which is different than adding a TAP version, which
Ovid wrote:
> Is anyone even using THS?
/me raises his hand
> If anything, I
> suspect there are a tiny handful of people who have played with it, but
> haven't really used it since it's not as useful as it could be.
I got Apache-Test to run .php scripts in under 10 lines by subclassing
strap
> But for all Test::Builder based modules you can get the same intent with
> Test::Builder->reset.
yup, I used that for the port away from Test.pm - works like a charm :)
--Geoff
Michael G Schwern wrote:
> On Tue, Dec 21, 2004 at 04:53:18PM +0100, Tels wrote:
>
>>On Tuesday 21 December 2004 08:53, Michael G Schwern wrote:
>>
>>>I've gotten absolutely no response about Test::Legacy. Is anybody
>>>using it? Anybody tried migrating old Test.pm based tests with it?
>>
>>I
> Changing the subject slightly, is there any guidance on what people
> should write in the name/comment/label?
>
> I ask because several times I've been puzzled by a test failure
> where the message printed is ambiguous. Compare these two:
>
> not ok 42 - is red
>
> not ok 42 - sho
Michael G Schwern wrote:
> On Wed, Dec 01, 2004 at 12:44:50AM +0100, Paul Johnson wrote:
>
>>>plan tests => 14, if => have( "Foo" ) && moon_phase eq "waning";
>>
>>The downside here, as Geoff alluded to, is that we don't really want the
>>short circuiting behaviour of &&, since evaluating the op
Andy Lester wrote:
> On Tue, Nov 30, 2004 at 10:36:00AM -0500, Geoffrey Young ([EMAIL PROTECTED])
> wrote:
>
>>anyway, the point of this exercise is to present a few different options for
>>augmenting Test::More's plan(). personally, I really, really like the way
&g
hi all.
yesterday on irc we got to discussing adding a feature to Test::More that
Apache-Test has been using for a while. the overall opinion was that the
idea had merit, but we should vet out options here, so comments welcome.
here's the scoop...
over in Apache-Test we allow users to join the p
[Torsten Fortsch ]
added Apache::TestRunPHP and Apache::TestConfigPHP classes,
which provide a framework for server-side testing via PHP scripts
[Geoffrey Young]
fix problem with multiple all.t files where only the final
file was being run through the test harness. [Geoffrey Young]
Documented
> 0.49 Thu Oct 14 21:58:50 EDT 2004
excellent! thank you very much.
for the interested, Test::More support has now officially been added to
Apache-Test server-side tests, provided you have 0.49.
kudos all around.
--Geoff
ss runtime argument, which will start the server
in single-server mode (httpd -X in Apache 1.X or
httpd -D ONE_PROCESS in 2.X) [Geoffrey Young]
In open_cmd, sanitize PATH instead of clearing it [Gozer]
Allow / \ and \\ path delimiters in SKIP file [Markus Wichitill
<[EMAIL PROTECTED]>]
Add
erver mode (httpd -X in Apache 1.X or
httpd -D ONE_PROCESS in 2.X) [Geoffrey Young]
In open_cmd, sanitize PATH instead of clearing it [Gozer]
Allow / \ and \\ path delimiters in SKIP file [Markus Wichitill
<[EMAIL PROTECTED]>]
Added an apxs query cache for improved test performance [Gozer]
David Wheeler wrote:
> On Oct 5, 2004, at 12:43 PM, Geoffrey Young wrote:
>
>> no, it is required. but only cvs currently supports -one-process as an
>> option - earlier versions will explode.
>
>
> Okay. So I just added this to the testcover
David Wheeler wrote:
> On Oct 5, 2004, at 12:36 PM, Geoffrey Young wrote:
>
>> somewhere in here it looks like -one-process is missing, though I
>> wouldn't
>> know where it would go.
>
>
> I'll put it in, though it isn't needed if you use A-
> +my $atdir = $self->localize_file_path("$ENV{HOME}/.apache-test");
> +local $Test::Harness::switches=
> +local $Test::Harness::Switches=
> +local $ENV{HARNESS_PERL_SWITCHES} = "-MDevel::Cover=+inc,'$atdir'";
somewhere in here it looks like -one-process is missing, though
David Wheeler wrote:
> On Oct 5, 2004, at 11:32 AM, Geoffrey Young wrote:
>
>>> Ah, cool. But $(HOME) doesn't correspond to ~/ here, does it?
>>
>>
>> yeah - it's equivalent to $ENV{HOME} in make-land. I guess there is
>> always
>> the dan
>>test-cover ::
>> @cover -delete
>> @HARNESS_PERL_SWITCHES=-MDevel::Cover=+inc,$(HOME)/.apache-test
>>APACHE_TEST_EXTRA_ARGS=-one-process $(MAKE) test
>> @cover
>
>
> I wonder whether we shouldn't try to standardise the target name before
> it's too late to do so. Module::Build
>> - HARNESS_PERL_SWITCHES gets Devel::Cover started
>
>
> Module::Build's testcover target already does this.
:)
>
>> - +inc,$(HOME)/.apache-test keeps coverage away from generated A-T
>> files,
>> which isn't required
>
>
> Ah, cool. But $(HOME) doesn't correspond to ~/ here, does it?
David Wheeler wrote:
> On Oct 2, 2004, at 2:30 PM, Geoffrey Young wrote:
>
>> I started to maintain Apache-Test skeletons, but I never quite got
>> them up
>> to speed. give me a few days and I'll roll a tarball with a test-cover
>> target so that folks ca
Geoffrey Young wrote:
>>[ Just before sending this I notice Geoff has recommended something
>>better, but I'll send this too as another WTDI. ]
>
>
> cool :)
>
> I started to maintain Apache-Test skeletons, but I never quite got them up
> to speed. give me
> [ Just before sending this I notice Geoff has recommended something
> better, but I'll send this too as another WTDI. ]
cool :)
I started to maintain Apache-Test skeletons, but I never quite got them up
to speed. give me a few days and I'll roll a tarball with a test-cover
target so that folk
Kevin Scaldeferri wrote:
>
> On Oct 2, 2004, at 12:36 PM, Geoffrey Young wrote:
>
>>>
>>
>> we use Apache-Test, which starts the server, runs the tests, and shuts
>> down
>> the server again.
>
>
>
> When I last talked with you about Apa
> if you haven't investigated Apache-Test yet, I would. our custom make
> target look like this:
I forgot to add some A-T specific stuff :)
t/conf/modperl_extra.pl:
if ($ENV{HARNESS_PERL_SWITCHES}) {
eval {
require Devel::Cover;
Devel::Cover->import('+ignore' => 't/response/'
Kevin Scaldeferri wrote:
>
> On Sep 21, 2004, at 1:30 PM, Kevin Scaldeferri wrote:
>
>>
>> So, I don't expect anyone to try to figure out this stack trace stuff,
>> but I'm curious if other people have seen stability problems like
>> this? Alternatively, if someone can tell me the exact logist
1 - 100 of 125 matches
Mail list logo
