Eric Wilhelm wrote:
# from Michael G Schwern
# on Thursday 29 November 2007 19:00:
Otherwise, what's important to people?
Could it be made fork-safe?
http://search.cpan.org/src/TJENNESS/File-Temp-0.19/t/fork.t
Possibly that involves blocking, or IPC with delayed output, or a
plan
Andy Armstrong wrote:
On 30 Nov 2007, at 03:00, Michael G Schwern wrote:
Otherwise, what's important to people? I know there's a lot of
suggestions
about increasing the flexibility of planning. Also the oft requested
I'm
done running tests sentinel for a safer no_plan. Most of the time
As threatened, here's Test::Fork for easier writing of forked tests.
http://pobox.com/~schwern/src/Test-Fork-0.01_01.tar.gz
use Test::More tests = 4;
use Test::Fork;
fork_ok(2, sub{
pass(Child);
pass(Child again);
});
Michael G Schwern wrote:
Otherwise, what's important to people?
Here's something that's important to me. I'd like to make it easier for
people to patch my modules. A bunch of people already have write access to my
repository, and I've taken care to ensure that most all the outstanding items
Fergal Daly wrote:
One of the supposed benefits of using TODO is that you will notice
when the external module has been fixed. That's reasonable but I don't
see a need to inflict the confusion of unexpectedly passing tests on
all your users to achieve this.
Maybe we should just change the
Fergal Daly wrote:
As long as you're releasing a new version, why would you not upgrade your
module's dependency to use the version that works?
Your module either is or isn't usable with version X of Foo.
If it is usable then you would not change your dependency before or
after the bug in
So I read two primary statements here.
1) Anything unexpected is suspicious. This includes unexpected success.
2) Anything unexpected should be reported back to the author.
The first is controversial, and leads to the conclusion that TODO passes
should fail.
The second is not controversial,
use Test::More;
pass();
plan tests = 2;
pass();
Why shouldn't this work? Currently you get a You tried to run a test without
a plan error, but what is it really protecting the test author from?
Historically, there was a clear technical reason. It used to be that
David Golden wrote:
Michael G Schwern [EMAIL PROTECTED] wrote:
It also makes it technically possible to allow the test to change it's plan
mid-stream, though the consequences and interface for that do require some
thought.
With some sugar, that could actually be quite handy for something
Eric Wilhelm wrote:
# from David Golden
# on Monday 03 December 2007 19:55:
With some sugar, that could actually be quite handy for something like
test blocks. E.g.:
{
plan add = 2;
ok( 1, wibble );
ok(1, wobble );
}
or maybe make the block a sub
block {
subplan 2;
A. Pagaltzis wrote:
Yes, so this should be allowed:
pass();
plan 'no_plan';
pass();
Whereas this should not:
pass();
plan tests = 2;
pass();
Umm, why not? That's exactly what I was proposing and it would result in...
ok 1
ok 2
1..2
Smylers wrote:
It also makes it technically possible to allow the test to change
it's plan mid-stream
Without some hypothetical future version of TAP this is only possible
if you have run tests before declaring a plan at all, because
otherwise the plan will already have been output as the
A. Pagaltzis wrote:
That would work. Of course once you have that, you don’t need to
allow assertions to run without a plan, since one can always say
use Test::More tests = variable = 0;
pass();
plan add_tests = 2;
pass();
instead of
use Test::More;
pass();
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 of TAP rules within the
TAP-emitter is what lead to my trouble in the first place.
A
Andreas J. Koenig wrote:
Bug in CPAN::Reporter and/or Test::Harness and/or CPAN.pm?
http://www.nntp.perl.org/group/perl.cpan.testers/796974
http://www.nntp.perl.org/group/perl.cpan.testers/825449
All tests fail but Test::Harness reports NOTESTS and CPAN::Reporter
concludes UNKNOWN and
This this whole discussion has unhinged a bit from reality, maybe you can give
some concrete examples of the problems you're talking about? You obviously
have some specific breakdowns in mind.
Fergal Daly wrote:
Modules do not have a binary state of working or not working. They're
composed
Geoffrey Young wrote:
I guess what I thought you were getting at was a natural decoupling of
comparison functions with the planning without all the hackery involved
to get that sepraration working now. so I was suggesting that the
decoupling go further than just no_plan, and that yeah, rock
Eric Wilhelm wrote:
A. Pagaltzis wrote:
...
which would still be an error. That way a mistake in a test
script won’t lead to Test::More silently converting an up-front
plan declarations into trailing ones.
Which brings us back to the original question: why should that be an
error?
It's
::Harness (aka Test::Harness 3) has fairly easy ways to control how
TODO tests are interpreted.
** It could be made easier, especially WRT controlling make test
** CPAN::Reporter could be made aware of TODO passes.
Fergal Daly wrote:
On 05/12/2007, Michael G Schwern [EMAIL PROTECTED] wrote
Eric Wilhelm wrote:
Since we're on the subject of CPAN::Reporter, TAP::Harness, Test::More,
and TODO wrt failure vs. no-noise vs. report-back vs. await-dependency
and the binaryism of failure and etc...
Perhaps a general sort of MAYBE namespace in TAP would be a nice
addition.
Is this a
A. Pagaltzis wrote:
* Michael G Schwern [EMAIL PROTECTED] [2007-12-05 04:30]:
Why do they care if the plan is output at the beginning or end?
How does this stricture improve the quality of the test?
It improves the resulting TAP stream, if not the test itself.
What's improved about the plan
Eric Wilhelm wrote:
# from Michael G Schwern
# on Wednesday 05 December 2007 05:47:
Perhaps a general sort of MAYBE namespace in TAP would be a nice
addition.
Is this a joke? I hope it's a joke.
Do I look like I'm joking? :-|
As it is, we're talking about detecting/reporting a 3rd
Eric Wilhelm wrote:
Give me something concrete, not just it's better. I'm going to
keep drilling through the BS until I either hit bottom or punch
through.
It allows you to apply the policy all tests have a plan at the test
level. Yes, policy often sounds like BS.
By historical
A. Pagaltzis wrote:
* Michael G Schwern [EMAIL PROTECTED] [2007-12-05 15:00]:
I'm going to keep drilling through the BS until I either hit
bottom or punch through.
Yeah, we’re all spouting bullshit. Gee, some tone you’re setting.
Sorry, I forgot the :)
That I'm pushing so hard to get
Fergal Daly wrote:
The importance of the test has not changed. Only the worth of the
failure report has changed.
This could be solved by having another classification of test, the
not my fault test used as follows
BLAME: {
$foo_broken = test_Foo(); # might just be a version check or
Ovid wrote:
Side note: those features I really want control over in
Test::Harness
are the plan() and ok() methods. There's no clean way for me to do
that. Just look at the constructor:
my $Test = Test::Builder-new;
sub new {
my($class) = shift;
$Test ||= $class-create;
Ovid wrote:
Test results currently look something like this:
t/foo.t. ok
t/bar.t. ok
t/baz.t. 23/?
# Failed test at t/baz.t line 9
# Looks like you failed 2 tests out of 23
t/baz.t. Dubious, test ...
Why do
Adrian Howard wrote:
On 11 Dec 2007, at 05:12, Michael G Schwern wrote:
Adam Kennedy posed me a stumper on #toolchain tonight. In short,
having a
test which checks your signature doesn't appear to be an actual
deterrent to
tampering. The man-in-the-middle can just delete the test
Andreas J. Koenig wrote:
On Mon, 10 Dec 2007 21:12:51 -0800, Michael G Schwern [EMAIL
PROTECTED] said:
Adam Kennedy posed me a stumper on #toolchain tonight. In short, having a
test which checks your signature doesn't appear to be an actual deterrent
to
tampering. The man
Edwardson, Tony wrote:
Anyone written any CPAN modules for which the testing coverage needs to be
improved ?
Want someone else to sort this out for you ?
...
Any takers ?
http://search.cpan.org/dist/ExtUtils-MakeMaker
Repository here:
http://svn.schwern.org/svn/CPAN/ExtUtils-MakeMaker
Andreas J. Koenig wrote:
On Fri, 14 Dec 2007 15:49:32 -0800, Michael G Schwern [EMAIL
PROTECTED] said:
We would seem to be agreeing. If the goal of the test suite is not to
protect
against spoofing, and if it doesn't accomplish that anyway, why put a
signature check
Andreas J. Koenig wrote:
On Sat, 15 Dec 2007 01:34:37 -0800, Michael G Schwern [EMAIL
PROTECTED] said:
See above. Once the bug is reported there is no justification to keep
the test around. In this case I prefer a skip over a removal because
the test apparently once was useful
nadim khemir wrote:
On Saturday 15 December 2007 20.53.30 Michael Peters wrote:
The uploaded file
TAP-Harness-Archive-0.03.tar.gz
...
Nice. Now, what do we do with it?
You RTFM.
http://search.cpan.org/perldoc/TAP::Harness::Archive
--
If at first you don't succeed--you fail.
chromatic wrote:
On Tuesday 18 December 2007 17:27:24 Andy Armstrong wrote:
Someone (MLEHMANN) doesn't like smoking... That was a test report
generated by CPAN::Reporter.
It hadn't previously occurred to me that test reports might cause
offence...
Didn't you get a whole slew of them a
Andy Armstrong wrote:
On 19 Dec 2007, at 03:13, Michael G Schwern wrote:
Anyhow, what's clear is there is a problem with IO::AIO. It hasn't been
addressed properly by the author. While it's frustrating to get a
constant
stream of your shit is broke, his shit is indeed broke
Michael Peters wrote:
David Golden wrote:
On Dec 20, 2007 1:19 PM, Dave Rolsky [EMAIL PROTECTED] wrote:
It's generally
pretty rare that the failure report includes enough information for me to
do anything about it, so without an engaged party on the other end, it
really is just noise.
With
Andy Armstrong wrote:
On 21 Dec 2007, at 00:11, Michael G Schwern wrote:
This could be accomplished silently with some environment variables.
TAP_PARSER_ARCHIVE_DIR=/path/to/somewhere
It's called PERL_TEST_HARNESS_DUMP_TAP and it already exists.
Well there you go.
Though might I suggest
chromatic wrote:
On Saturday 22 December 2007 16:48:29 Michael G Schwern wrote:
The I installed to a directory with a space in the path is an example of
CPAN Testers working as expected. It found and highlighted an annoying bug
that the rest of us either ignore or work around.
CPAN Testers
chromatic wrote:
I just went through a sampling of fail reports for my stuff. There was one
legitimate packaging bug, and a couple of legitimate errors due to updates to
Perl. About 35% of the other reports are these.
I love the Illegal seek error message:
David Golden wrote:
On Dec 23, 2007 2:37 AM, Michael G Schwern [EMAIL PROTECTED] wrote:
[1] It can be argued that bleadperl testers should probably not email
authors,
and maybe they aren't I can't tell from these archives, but at least the work
is useful. CPAN::Reporter could change
Michael G Schwern wrote:
David Golden wrote:
On Dec 23, 2007 2:37 AM, Michael G Schwern [EMAIL PROTECTED] wrote:
[1] It can be argued that bleadperl testers should probably not email
authors,
and maybe they aren't I can't tell from these archives, but at least the
work
is useful. CPAN
Gabor Szabo wrote:
might be slightly unrelated to QAsorry
In the future, MakeMaker issues go to [EMAIL PROTECTED]
After installing JOSHUA/Net-Telnet-Cisco-1.10.tar.gz
if I run perl Makefile.PL on an unrelated Makefile.PL that
requires 'Net::Telnet::Cisco' = '1.10'
I get a
Gabor Szabo wrote:
Is there a place with definition of what a VERSION value can be ?
Anything which compares sanely as a number plus the X.YY_ZZ alpha convention
(which MM converts to a number). I guess that's never stated explicitly. I'd
welcome a section on $VERSION in
Eric Wilhelm wrote:
# from Aristotle Pagaltzis
# on Wednesday 02 January 2008 16:47:
looking for (and diffusing) mines
That sounds like a novel approach! Or do you mean “defusing”? :-)
Yeah :-D Diffuse is probably what they do when you find them the less
careful way!
I guess the
nadim khemir wrote:
print 'hi' or carp q{can't print!} ;
I'm not even going to wade into the layers of neurosis demonstrated in this
post, but if you want to throw an error use croak().
--
...they shared one last kiss that left a bitter yet sweet taste in her
mouth--kind of like throwing up
demerphq wrote:
So we are told the way to mark a module as development is to use an
underbar in the version number:
$VERSION= 1.23_01;
but this will produce warnings if you assert a required version
number, as the version isn't numeric.
We talked about this recently on [EMAIL PROTECTED]
demerphq wrote:
Just a heads up that I patched the core version of Test::Builder to
use more reliable and robust methods for detecting regexps in test
cases. This makes them robust to changes in the internals and also
prevents Test::Builder from getting confused if someone uses blessed
Salve J Nilsen wrote:
Oslo.pm is planning a Perl QA Workshop/Hackathon in Oslo, Saturday
April 4th to Monday April 7th, 2008.
FWIW, if I can get sponsored, I'm going with bells on.
Just to make things more interesting, IEEE will have a conference on
software testing nearby (in Lillehammer,
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
Ovid wrote:
I'll go fix that diagnostic thing now. Unfortunately, I think I'll
have to violate encapsulation :(
If you know how to fix it let me know, because other than enumerating each
testing module you might use and lex-wrapping all the functions they export,
I'm not sure how to do it.
The whole idea of halting on first failure was introduced to me by some XUnit
folks. Their rationale was not to avoid spewing output, they had no such
problem since it's all done via a GUI, but that once one failure has happened
the failing code might hose the environment and all following
Ovid wrote:
--- Michael G Schwern [EMAIL PROTECTED] wrote:
The whole idea of halting on first failure was introduced to me by
some XUnit
folks ... As any field scientist knows, there's no such thing as
uncontaminated data.
As any tester knows, a one size fits all suit often doesn't fit
Aristotle Pagaltzis wrote:
* Michael G Schwern [EMAIL PROTECTED] [2008-01-12 12:00]:
Ovid wrote:
I'll go fix that diagnostic thing now. Unfortunately, I
think I'll have to violate encapsulation :(
If you know how to fix it let me know, because other than
enumerating each testing module you
Ovid wrote:
So we can preserve diagnostics, but we need help in cleaning up those
damned line numbers. Hook::LexWrap didn't have the magic I thought it
would.
ok() is now inside a wrapper so you're one level further down then it thinks.
Just add one to $Level and then take it back off again
Paul Johnson wrote:
This is something that I too have asked for in the past. I've even
hacked up my own stuff to do it, though obviously not as elegantly as
you or Geoff. Here's my use case.
I have a bunch of tests that generally pass. I hack something
fundamental and run my tests.
Ovid wrote:
My first attempt at determining the most popular testing modules left
out Test.pm. Whoops! I've fixed that.
Out of almost 60,000 test programs, it turns out Test.pm is used 8,937
times. Now that I have a file which lists how many times each test
module is used, I can start
Matisse Enzer wrote:
I just want to be able to run a test suite with a switch that makes the
entire test run stop after the first failure is reported.
Ok, it's nice to want things, but why do you want it?
--
100. Claymore mines are not filled with yummy candy, and it is wrong
to tell
Matisse Enzer wrote:
On Jan 12, 2008, at 10:24 PM, Michael G Schwern wrote:
Matisse Enzer wrote:
I just want to be able to run a test suite with a switch that makes the
entire test run stop after the first failure is reported.
Ok, it's nice to want things, but why do you want
Michael Peters wrote:
Michael G Schwern wrote:
Ok, why do you want to stop it as fast as possible when a failure occurs?
I have a 45 minute test suite and I want to work on the first failure as soon
as
possible. I also have multiple desktops and am doing other things in another
desktop
Adam Kennedy wrote:
This shouldn't be any more complicated than -g (where g in my case
stands for goat as in feinting goat)
Ok, I'll bite. Why a goat and why is it feinting?
--
...they shared one last kiss that left a bitter yet sweet taste in her
mouth--kind of like throwing up after
Gabor Szabo wrote:
I know I am a bit late to the party but what about Test::Anything ?
Rapidly drifting towards Test::Anything::Protocol.
--
But there's no sense crying over every mistake.
You just keep on trying till you run out of cake.
-- Jonathan Coulton, Still Alive
Ovid wrote:
Test::Harness used to be very limited. We couldn't do a lot with it,
but when we started testing, most of us didn't do a lot with it. As we
understood more about testing, we understood better many things we
wanted. As a result, Schwern posted a great plan for rewriting
Ovid wrote:
What should parallel tests do if a BAIL_OUT is encountered? I think
all parallel tests currently running should be allowed to finish so
they can attempt to cleanup, but no more tests should be started. Does
this sound reasonable?
It's not entirely clear if bail out means kill the
Ian Malpass wrote:
I got a failure message from CPAN testers for Pod::Extract::URI for
5.11.0 patch 33001 on Linux 2.6.22-3-amd64
(x86_64-linux-thread-multi-ld)[0]
The failures were where I was testing to see if an arrayref of qr//
patterns was the array I was expecting. is_deeply() has
Ovid wrote:
Crap. Can we just forget I sent that to Perl QA instead of the Grant
Committee?
/me puts on his sunglasses.
/me pulls out a black device.
Now if everyone on perl-qa will please look this way...
*FLASH!*
--
You are wicked and wrong to have broken inside and peeked at the
Andrew Hampe wrote:
The Basic CPAN concern: --bail_on_fail flag (2008.02.10 )
Problem description:
when a cpan session is looking for more than one distribution/module
there needs to be a way to 'flag' that the session must fail and stop
if there is an error loading any
chromatic wrote:
On Tuesday 12 February 2008 10:55:21 chromatic wrote:
On Tuesday 12 February 2008 10:06:14 Eric Wilhelm wrote:
How will you print the assertion code without a source filter?
Show Source on Exception is fairly easy:
David Landgren wrote:
I wish you'd s/Got/Actual/ or Received. Got must die.
Why's that?
--
Hating the web since 1994.
Adrian Howard wrote:
which isn't _too_ shabby, but doesn't help much with things like:
ok_if { Foo-new-answer == 42 };
or
ok_if { $Some_dynamic_var == 42 };
So I don't really think it's worth pursuing.
Well, if we follow the logic of the assert2 author, you're just being SLOPPY
I just merged together a number of tickets having to do with Test::More not
liking wide characters.
use 5.008;
use strict;
use warnings;
use Test::More tests = 1;
my $uni = \x{11e};
ok( $uni eq $uni, Testing $uni );
__END__
1..1
Wide character in print at lib/Test/Builder.pm line 1252.
ok 1
Aristotle Pagaltzis wrote:
use 5.008;
use strict;
use warnings;
use open ':std', ':locale';
use Test::More tests = 1;
my $uni = \x{11e};
ok( $uni eq $uni, Testing $uni );
__END__
1..1
Wide character in print at lib/Test/Builder.pm line 1252.
^^ after the above patch, gone
There's
Andy Armstrong wrote:
Is there a generally approved way for an XS module to test for the
existence of a C compiler before attempting to build?
MakeMaker uses ExtUtils::CBuilder-have_compiler() in it's tests. It's worked
well with no complaints. It's an additional testing dependency, but
Yitzchak Scott-Thoennes wrote:
On Mon, Feb 25, 2008 at 03:59:37PM -0800, Michael G Schwern wrote:
MakeMaker uses ExtUtils::CBuilder-have_compiler() in it's tests. It's
worked well with no complaints. It's an additional testing dependency,
but it's a useful one and Module::Build
demerphq wrote:
On 03/03/2008, David Golden [EMAIL PROTECTED] wrote:
On Mon, Mar 3, 2008 at 6:57 AM, demerphq [EMAIL PROTECTED] wrote:
IMO if an NA result comes in without email contact details and without
an explanation for the NA then the result should not be aggregated
against the
Nicholas Clark wrote:
On Mon, Mar 03, 2008 at 02:19:23PM +, Smylers wrote:
demerphq writes:
It turned out the problem is that when the tests are root it seems to
be not possible to create a directory that is not writeable by root.
I think that can be reduced to: It isn't possible to
David Golden wrote:
On Mon, Mar 3, 2008 at 11:45 AM, Michael G Schwern [EMAIL PROTECTED] wrote:
It would be nice if NA's included the reason for it being an NA, that being
the full Makefile/Build.PL output just like if it failed. I don't see any
harm in that and it would help identify
I'm coining a new term, fixage, like breakage.
Fixage is when software fixes a bug and reveals bugs in dependent software.
Test-Simple 0.77 (which includes Test::More) fixed a long standing bug by
removing the annoying global $SIG{__DIE__} handler to trap test death. It
would swallow the
David Golden wrote:
On Mon, Mar 3, 2008 at 2:04 PM, Michael G Schwern [EMAIL PROTECTED] wrote:
* parsing for error messages from code like use 5.008 or from our
being used in $VERSION strings prior to 5.005
It's that last one that concerns me, it's a bit heuristicy and I've been
things
chromatic wrote:
On Monday 03 March 2008 11:20:54 Michael G Schwern wrote:
Fixage is when software fixes a bug and reveals bugs in dependent
software.
Test-Simple 0.77 (which includes Test::More) fixed a long standing bug by
removing the annoying global $SIG{__DIE__} handler to trap test
The First International Conference on Software Testing, Verification and
Validation is happening in Lillehammer, Norway April 9 - 11. The conference
proper is April 10th and 11th, just after Go Open and the Oslo QA Hackathon.
I think this is a good chance for Perl QA to crash the IEEE and get
Chris Dolan wrote:
On Mar 8, 2008, at 11:59 AM, Andy Armstrong wrote:
On 8 Mar 2008, at 17:54, Chris Dolan wrote:
Perl 5.8.6 (Apple's dist for OSX 10.4)
Test::Harness 3.10
TAP::Harness 0.54
TAP::Parser 0.54
CPAN 1.9205
CPANPLUS 0.82
Yeah, you have a mixture of Test::Harness and
Andy Armstrong wrote:
On 20 Nov 2007, at 23:39, Michael G Schwern wrote:
Do we like that?
Test::Harness 2 put it on it's own line mostly to avoid wrapping off
the right
side of the screen. I still lean in that direction.
Hmm. I'm kind of hooked on the new behaviour now. It puts a summary
Ricardo SIGNES wrote:
That's all! I hope someone else finds it useful.
FWIW we were just talking about the issue of generating modules from static
files (rather than the other way around like we do now) at PDX.pm.
--
Look at me talking when there's science to do.
When I look out there it
Matisse Enzer wrote:
I'm discussing some potential refactorings at $work at wanted to give an
articulate explanation of the benefits of having package declarations
match file names, so that:
# file is Foo/bar.pm
package Foo::Bar;
That was probably a typo, but I hope you mean
Dave Rolsky wrote:
There's a lot of value in following the existing best practices of the
Perl community as a whole. For one thing, it means you can hire people
with Perl experience and they can bring that experience to bear on
your application.
If you insist on reinventing every wheel,
About two years ago several people came upon this patent granted to Sun,
EP1170667 - Software Package Verification
http://gauss.ffii.org/PatentView/EP1170667
Its US equivalent is 7080357
http://www.google.com/patents?vid=USPAT7080357
There was some concern this might conflict with TAP and
A few logistical items that I'd like to make sure are being taken care of for
the hackathon. The idea is to work this out now to maximize our in-site
hacking time.
I don't know what the status of this is, but here's what I can think of off
the top of my head.
*) Access for wirelessless
Gergely Brautigam wrote:
One last question then I swear I will shut up :)
Why use perl for testing? Of course all others languages are used for testing
this
and that.. What excels perl to be used for testing. Obviusly it has
powerfull regex,
and datahandling capabilities... But besides
[EMAIL PROTECTED] wrote:
Hi *,
are there any Perl modules for model-based testing [1]? Are there any
talks about model-based testing with Perl?
Cheers,
Renee
[1] http://en.wikipedia.org/wiki/Model-based_testing
Never heard of it. It smells a little bit like a further extension of FIT
I have some work to write tests for a server that talks to a database. This
means creating a database and firing up a server for testing purposes, and
then dropping the database and shutting down the server at the end. This also
means making sure that multiple instances of the test can run on
Ovid wrote:
Has anyone here ever succesfully used FIT testing? I was at one of the
first presentations of FITness a long time ago, but the example Ward
Cunningham gave was of a calculator. I thought the idea was neat, but
how would I implement it?
When you say implement it do you mean the
Eric Wilhelm wrote:
On Thursday 27 March 2008 12:42:13 Eric Wilhelm wrote:
What do you need to test that your users need to drive?
Business rules.
So, what is a good example of such a business rule? I posit that
payroll does not count because the user could more concisely write the
rule
I put Test::Builder 2 up as a topic for the Oslo hackathon.
http://perl-qa.hexten.net/wiki/index.php/Oslo_QA_Hackathon_2008_:_Topics#Test::Builder_2
--
E: Would you want to maintain a 5000 line Perl program?
d: Why would you write a 5000 line program?
Ok, let's clear this all up.
FIT is not about expressing business rules.
FIT is a tool which allows the customer to add test cases in a way they're
comfortable with. A programmer still has to write the logic behind those
tests (called a Fixture), but it allows a customer to easily add more
Stumbled across this while finding an alternative to libtap for testing C (it
has some sort of issue linking with this hairy project I'm working on).
Apparently MySQL wrote their own TAP library for C.
From http://dev.mysql.com/doc/mysqltest/en/unit-test.html
The unit-testing facility is
Buddy Burden wrote:
Not criticizing, not claiming my method is better, just looking for
any reasons why this wouldn't work. And, JIC there's some agreement
that it _would_ work, I've already put together a patch for Test::Most
that does it. That is, at the top of your script, you put this:
Aristotle Pagaltzis wrote:
Note that it doesn’t quite protect you from running too few tests
either. You may botch some conditional in your test program and
end up skipping tests silently, in which case you will still
reach the `all_done()` line, and it’ll look as if all was fine.
The typical
Eric Wilhelm wrote:
# from Aristotle Pagaltzis
# on Sunday 30 March 2008 23:14:
Except that the test program might be running at the other end of
an HTTP connection. Or at the other end of a serial port. Or the
harness might be parsing an archived TAP stream. Or a TAP archive
generated offline
Eric Wilhelm wrote:
What it protects you from is dying half-way through the tests
without the harness noticing...
Death is noted by both Test::More and Test::Harness and has been for a
long time
The only way you can abort the test halfway through using no_plan and
get a success is with an
Eric Wilhelm wrote:
# from Michael G Schwern
# on Sunday 30 March 2008 23:35:
There is a TAP proposal to add meta information such as the exit
codes. http://testanything.org/wiki/index.php/TAP_meta_information
Yay.
Can we put 'hostname' in there too?
You can put whatever you want
1101 - 1200 of 1466 matches
Mail list logo
