Dear Lovers of all things TAP,
Just wanted to let you know about a new module I just released for
the OCaml language that produces TAP output.
http://www.iinteractive.com/ocaml/
It supports most (but not all) of the TAP protocol and seems to work
just fine with prove and co. (haven't teste
Michael,
On Nov 22, 2005, at 3:13 PM, Michael Peters wrote:
Stevan Little wrote:
Michael,
You might want to look at some of the work on the Pugs test suite.
http://m19s28.vlinux.de/cgi-bin/pugs-smokeserv.pl
It uses (among other things) Test::TAP::Model and
Test::TAP::HTMLMatrix, and uses
Michael,
You might want to look at some of the work on the Pugs test suite.
http://m19s28.vlinux.de/cgi-bin/pugs-smokeserv.pl
It uses (among other things) Test::TAP::Model and
Test::TAP::HTMLMatrix, and uses YAML as an intermediate test-run format.
Stevan
On Nov 22, 2005, at 2:11 PM, Mi
On Feb 6, 2005, at 3:16 PM, Michael G Schwern wrote:
On Sat, Feb 05, 2005 at 06:59:26PM -0500, Ian Langworth wrote:
'comment', however, seems just right -- it implies a short, optional
description.
I like comment, too. It already has a meaning in Perl (and every other
language) and its just the sa
7; third.
- Steve
On Feb 5, 2005, at 3:23 PM, Ian Langworth wrote:
Stevan Little wrote:
I sent Schwern a patch to change 'names' to 'description', but then
Andy brought up the idea of 'labels'. At the time, Schwern said it
was 'in the pipeline', but I exp
I sent Schwern a patch to change 'names' to 'description', but then
Andy brought up the idea of 'labels'. At the time, Schwern said it was
'in the pipeline', but I expect its actually been moved out since.
Personally, I view them as 'descriptions' since thats what I usually
write. But 'labels'
Ovid,
If you want/need to test for circular data structures,
Test::Memory::Cycle does a nice job. It's bascially just a wrapper
around Devel::Cycle. And if you need to test weakened ones, I am wrote
a patch for both Devel::Cycle and Test::Memory::Cycle to be able to
check them as well. We are w
On Dec 13, 2004, at 11:10 AM, Jason Gessner wrote:
David Cantrell wrote:
Jason Gessner wrote:
Andy Lester wrote:
So it's sort of adding make functionality with prove. The way the
check
is running in the patch, the only criteria for updating it is
changes
in the .t file, but what if what you're u
I don't really agree that "comment" implies "not really worth doing". I
think
those inclined to not put a name/comment/label on their test will not
do it
whatever we end up calling it. IMO the only way to get people to do it
would
be to make it required, and I don't think that is a good idea.
I
On Dec 2, 2004, at 7:24 PM, Michael G Schwern wrote:
Let's start calling it the comment, in all of our testing modules,
starting now.
I give this a hearty shrug of indifference. Patches to Test::More
welcome.
This patches Test::More, Test::Simple, Test::Tutorial and Test::Builder
to refer to
'na
Andy,
You have my vote for "comments".
Calling it a test "name" have never made sense to me.
Steve
On Dec 2, 2004, at 11:40 AM, Andy Lester wrote:
I have a modest proposal.
Stop calling the 2nd parm to ok() the "name". It's really a comment.
ok( $is_happy, "Make sure the doodad is wingoed" );
Th
Ovid,
I second that complaint against JUnit. I recently have been doing some
Java work and found it somewhat frustrating that when my test failed I
had to read line numbers and hunt around, etc etc etc. I have gotten so
used to my test comment not only pointing me right to the failed test,
but
Jeff,
On Nov 5, 2004, at 4:33 PM, Jeff Bisbee wrote:
I was just wondering if there was an easier way where make test whould
like in lib and not blib.
Well if you don't do the 'make test' step, you can just call the test
file individually and add 'lib/' to the @INC from the command line.
Like this
Jeff,
On Nov 5, 2004, at 10:46 AM, Jeff Bisbee wrote:
I'm also curious how other folks run coverage, update modules
and rerun coverage.
I tend to not re-make my modules before I test them (then again, they
are always pure perl so I don't need to do it as much in a C based
module). I have a small
Mark,
This can be an issue, however I think it is easily solved.
1) Use a mean between the most efficient and least efficient
programmers times, since it could be either one (and probably both) who
work on it.
In many situations, your more efficient programmer is managing your
less efficient pr
Mark,
There is one theme I haven't heard anyone mention:
The purely scientific approach that I assume involves collecting a lot
o
data and using complex formulas.
I think that may be because project estimation is more akin to alchemy
and witchcraft than it is "hard science".
:)
Steve
Mark,
I think Jared and Andy both have made excellent suggestions, especially
Andy's comment about breaking it down into manageable chunks.
So, what resources are recommended to consult to make great estimates?
What habits to develop?
When I first started estimating projects I very often would ma
, [ (caller($i))[0 .. 3] ] while caller($i++);
did not help, only the addition of the DB package AND the
post-increment made the Devel::Cover run work (but made the normal test
fail).
Anyway, I am still looking.
Steve
On Sep 10, 2004, at 12:50 PM, stevan little wrote:
I am seeing some weird behavior
I am seeing some weird behavior where Devel::Cover seems to be
removing/consuming information I am trying to extract with caller(). I
have managed to isolate the behavior in a small script, which is
included below.
Anyone else seen this problem before? Am I doing something wrong? Or is
this a
their proper scope, all was well. However, this doesn't
answer my question about why prove let this happen, and make test
caught it.
Steve
On Sep 3, 2004, at 1:45 PM, stevan little wrote:
I am getting ready to release a new version of DBD::Mock and all
seemed fine until I tried running
I am getting ready to release a new version of DBD::Mock and all seemed
fine until I tried running 'make test' and I got a bunch of warnings,
which when I ran it with 'prove -b t/*.t' I did not get.
I have tried to debug the issue based on the DBI line number. But (as
far as I can tell) what
Personally I prefer to use cmp_ok for things like this, so that you can
be sure to use the right operator for the job ('is' will use the 'eq'
operator).
cmp_ok(0, '==', 1, "Zero shouldn't equal one");
Steve
On Aug 31, 2004, at 7:58 AM, Ricardo SIGNES wrote:
* Andrew Savige <[EMAIL PROTECTED]> [2
Geoff,
This sounds like mock objects basically
(http://www.mockobjects.com/FrontPage.html), although maybe on a
smaller/more-directed scale. I do like the idea of building a mock
object repository of sorts, I am sure that would come in handy.
Steve
On Aug 9, 2004, at 3:42 PM, Geoffrey Young wr
On Jul 11, 2004, at 4:09 PM, James Mastros wrote:
package Foo;
sub new {
my $class=shift;
$class=ref($class)||$class;
bless [], $class;
}
eval { Foo::new(); }
is($!, "new dies when called as a function");
Actually this doesn't die, it does even worse, given this code:
package Foo;
sub new {
Micheal,
On Jul 11, 2004, at 2:09 PM, Michael G Schwern wrote:
On Sun, Jul 11, 2004 at 12:26:44PM -0400, stevan little wrote:
As for POD, in most cases, I agree with you, but to say you should
have
100% POD coverage brings up several other questions, such as; Should I
document private methods
On Jul 9, 2004, at 6:06 PM, Andy Lester wrote:
Don't be mesmerized by 100% coverage.
Agreed 100% here. However, I stand by my original statement that you
CAN have 100% coverage on subroutines and pod. Any disagreement on
that
one?
I agree with having 100% on subroutines, and I would add that 100
Gabor,
Maybe you could try using the [EMAIL PROTECTED] trick to do what
you want?
You could unshift a sub ref onto @INC right before the test which would
mock the loading failure for Foo and only Foo. Then as soon as your
test is finished, you can shift it back off again.
unshift @INC => sub {
Andy,
I agree, it an intimidating idea to think that you have to take on
responsibility for a whole module. I enjoyed working on the DBI tests,
and when I next have some spare time between projects, I plan on
helping again, either with DBI or some other module. You should really
encourage that
Francisco,
Personally I like to have tests that depend upon one another in a
single file. However, that is not always possible or easy to do. In
your case though, I would suggest you use mock objects for your
database instead of a real database. This would allow your tests to be
run independent
On May 22, 2004, at 7:43 AM, Gabor Szabo wrote:
This extra color still leaves place for questions on the side of
the management so there could be a flag such as --mcl
(manager compatible report) that would turn all the purple parts
to be green.
Manager Compatible Reports :) I like that.
Although, I
On May 21, 2004, at 12:02 PM, Geoffrey Young wrote:
Full coverage isn't always possible, and the lack of it isn't
necessarily a problem.
I fully agree. however, once you start using a tool like this,
management
will inevitably ask "what's that 93% about?" and the answer is
sometimes
complex an
Tim,
On May 15, 2004, at 5:00 PM, Tim Bunce wrote:
I think our mileage does vary as I can't think of any overloaded
stringification in the DBI or these tests.
I'm sorry, i read stringification, not "overloaded" stringification.
You are right,.. we just do regular ole' perl stringification on the
Andy,
This stringification problem may be a culprit, as we stringify 2
objects to test against in the subroutine which is run in each thread.
But that stringification was there before in the old test (1.42), so I
think maybe this is a different problem.
Steve
On May 15, 2004, at 2:17 PM, Andy L
ce wrote:
On Sat, May 15, 2004 at 11:47:39AM +0100, Tim Bunce wrote:
On Fri, May 14, 2004 at 09:16:00PM -0400, stevan little wrote:
Tim, Andy,
Could you take a look at this problem with threaded perl:
t/10examp.ok 165/252Invalid value for shared scalar at
/usr/local/perl583-i/lib/5.8.3/
I have commited several revisions and additions to the 03handle.t test
file to the SVN repository. They are detailed as follows:
- increased number of tests from 68 to 101
- added tests to check conditions/assumptions prior to running
groups of tests,
which compliment the testing of th
I have committed a small set of changes to the svn repository, here are
the details:
For sake of consistency throughout all the tests, I have set the
she-bang line on all to be:
#!perl -w
NOTE: I have not removed any instances of $^W=1 in the tests although
it really is no longer needed.
I
";
Tim.
So I will make sure all the tests have the -w in the she-bang line.
Steve
On Tue, 2004-05-11 at 15:19, stevan little wrote:
If 5.6.1 is the official minimum, then maybe this brings back up the -w
vs. warnings issue? Since Ovid pointed out that 5.6 was the minimum for
the warnings
ay?
Steve
On May 11, 2004, at 6:14 PM, Tim Bunce wrote:
On Tue, May 11, 2004 at 05:13:19PM -0400, stevan little wrote:
On May 11, 2004, at 2:47 PM, Andy Lester wrote:
One concern just popped into my head... I'd like to not have to
depend on very recent versions of Test::More. Can you loo
ppp* files should not have -T in their
she-bang, since the regular test files they load already do. Would you
agree?
Steve
On May 11, 2004, at 6:06 PM, Tim Bunce wrote:
On Tue, May 11, 2004 at 01:48:47PM -0500, Andy Lester wrote:
On Tue, May 11, 2004 at 01:58:51PM -0400, stevan little
([EMAIL
A question for the class:
Is specifying the -w flag in the she-bang line sufficient? Or should we
also include $^W = 1 at the top of every file as well?
Steve
On May 11, 2004, at 5:39 PM, Ovid wrote:
--- stevan little <[EMAIL PROTECTED]> wrote:
If this will break things prior to 5.6
PM, Ovid wrote:
--- stevan little <[EMAIL PROTECTED]> wrote:
I would also like to propose that we remove all -w flags, and convert
them to use the warnings pragma.
Does that mean you don't want to support versions of Perl prior to
5.6? I would think that should
be up to Tim.
C
.
Do you guys concur?
Steve
On May 11, 2004, at 2:48 PM, Andy Lester wrote:
On Tue, May 11, 2004 at 01:58:51PM -0400, stevan little
([EMAIL PROTECTED]) wrote:
Should we put the -T flag in all the test files? I can do that if so.
I'd like to. I'd like every module to think about taint-sa
On May 11, 2004, at 2:47 PM, Andy Lester wrote:
I've committed my t/41 and t/42 changes to subversion. They are not
the
same as what I submitted to the list.
Yes, that slightly confused me, which is why I asked. I assumed there
was a reason why you had chosen to not use skip_all, so I thought I
Tim, Andy,
Should we put the -T flag in all the test files? I can do that if so.
Also, i noticed in the most recently checked in versions, that the
'skip_all' code was not included from the patches Andy sent for
41prof_dump.t and 42prof_data.t. Are we not using 'skip_all'? If so, I
will remov
Tim,
I made another update today, here are the details of the changes:
07kids.t
- changed it to a skip_all for DBI::PurePerl
- Increased the number of tests from 11 to 20
- Added tests to exercise the $dbh's Kids/ActiveKids attributes more
by cre
On May 10, 2004, at 5:29 PM, Tim Bunce wrote:
On Mon, May 10, 2004 at 01:40:55PM -0400, stevan little wrote:
I have committed my first set of changes to the DBI svn repository.
Thanks!
I got an assortment of warnings from various tests. I suspect you
didn't run a plain "make test&q
On May 10, 2004, at 1:46 PM, H.Merijn Brand wrote:
On Mon 10 May 2004 19:40, stevan little <[EMAIL PROTECTED]>
wrote:
I have committed my first set of changes to the DBI svn repository. I
am mostly still working on converting the scripts to use Test::More,
but I have managed to slip i
:More.
Still to do:
- clean up the existing test orgainization
- make sure all tests have a test name
- add 'isa_ok' tests where appropriate
There of course, is still more to come. But I thought I would commit my
changes thus far.
Thanks,
Stevan Little
[EMAIL PROTECTED]
--
On May 9, 2004, at 6:48 PM, Tim Bunce wrote:
On Sat, May 08, 2004 at 03:16:45PM -0400, stevan little wrote:
On May 8, 2004, at 2:25 PM, Tim Bunce wrote:
Just some (and thanks for that). But there are still a few with
custom ok() subs and some others using the plain Test module.
Tim.
Make that 2
On May 8, 2004, at 2:25 PM, Tim Bunce wrote:
Just some (and thanks for that). But there are still a few with
custom ok() subs and some others using the plain Test module.
Tim.
Make that 2 less tests doing the funky stuff, this is actually going a
lot faster than I thought it was going to.
I hope
Andy,
Devel::Cover and I are already very well aquainted, its one of my
favorite tools actually.
steve
On May 7, 2004, at 6:14 PM, Andy Lester wrote:
On Fri, May 07, 2004 at 10:31:49PM +0100, Tim Bunce
([EMAIL PROTECTED]) wrote:
Here's what I'd like to see done soonish:
1. Convert all exisi
the driver test harness as I do this.
I will let you know when I have something interesting to show.
Thanks
Steve
On May 7, 2004, at 5:31 PM, Tim Bunce wrote:
On Fri, May 07, 2004 at 03:03:10PM -0400, stevan little wrote:
On May 7, 2004, at 1:37 PM, Tim Bunce wrote:
But still no hoplite has
On May 7, 2004, at 1:37 PM, Tim Bunce wrote:
But still no hoplite has actually adopted the DBI...
Since I would like to get involved here, and (with the exception of
HTML::Template, which is already taken) the module I know best in the
100 is DBI. Besides, it seems like Tim really want's someone
I looked on the site (http://qa.perl.org/phalanx/), but there was
nothing said about how to get involved in this project. Are you looking
for help? And if so, how can I help?
Thanks,
Steve
54 matches
Mail list logo
