* chromatic [EMAIL PROTECTED] [2008-05-18 07:20]:
People already have to modify the TODO test to add whatever
kind of positive assertion you postulate; why is writing a
separate test a barrier?
Because it’s hidden behind an internal interface that would have
to be exposed? Or any other reason
Aristotle Pagaltzis wrote:
As a technique, paying attention to how broken code changes,
why does it matter that broken code breaks differently? What
does this information tell you that might fix code?
It means there is a known internal dependency on some other part
of the code that is not
* Michael G Schwern [EMAIL PROTECTED] [2008-05-18 05:30]:
Aristotle Pagaltzis wrote:
As a technique, paying attention to how broken code changes,
why does it matter that broken code breaks differently? What
does this information tell you that might fix code?
It means there is a known
On Saturday 17 May 2008 20:48:24 Aristotle Pagaltzis wrote:
You’re not following.
1. There is non-broken code which isn’t being tested directly.
2. There is a test that ensures its correctness, but only
indirectly, as part of testing something else.
3. That something else is currently
Smylers wrote:
Bram writes:
At the moment foo() returns 3.
Time passes and code changes.
Now there are 3 options:
foo() returns 1, this will result in 'unexpected todo test passed'
being outputted;
foo() returns 3, no special output is produced;
foo() returns 4, no special output is
* Michael G Schwern [EMAIL PROTECTED] [2008-05-14 08:50]:
As I understand it, you want to know when broken code breaks
differently.
Indeed.
I can sort of see the point as a regression test... sort of.
But if you're at the point of fussiness that broken code has to
break in a specific way...
--- Bram [EMAIL PROTECTED] wrote:
{
local $TODO = test that foo() returns 1;
local $WAS = 3;
my $s1 = foo();
is($s1, 1);
}
I really haven't thought through all of the ramifications of this, but
I like it. I was recently complaining to Schwern about the issue with
TODO tests
* Ovid [EMAIL PROTECTED] [2008-05-12 11:35]:
Alternatively, persistent TAP could potentially track TODO
results and handle the $WAS for you, but this is quite a ways
off and has the problem that we cannot always identify which
tests are which.
Plus, you still need a way to specify which
Bram writes:
At the moment foo() returns 3.
Time passes and code changes.
Now there are 3 options:
foo() returns 1, this will result in 'unexpected todo test passed'
being outputted;
foo() returns 3, no special output is produced;
foo() returns 4, no special output is produced;
--- Smylers [EMAIL PROTECTED] wrote:
If you believe that (until the TODO is done) foo will consistently
return 3, and you wish to be alerted if it suddenly starts returning
4,
then surely you can do that with a non-TODO test which checks for its
being 3?
Sure you can do that:
my $result;
Quoting Smylers [EMAIL PROTECTED]:
Bram writes:
At the moment foo() returns 3.
Time passes and code changes.
Now there are 3 options:
foo() returns 1, this will result in 'unexpected todo test passed'
being outputted;
foo() returns 3, no special output is produced;
foo() returns 4, no
2008/5/12 Ovid [EMAIL PROTECTED]:
--- Smylers [EMAIL PROTECTED] wrote:
If you believe that (until the TODO is done) foo will consistently
return 3, and you wish to be alerted if it suddenly starts returning
4,
then surely you can do that with a non-TODO test which checks for its
being 3?
--- Fergal Daly [EMAIL PROTECTED] wrote:
I almost posted this a few hours ago but then decided not to since
I'm
not sure I like the thread at all. I'm posting it now because while
I'm not a huge fan of the idea itself, the problems you list are due
to a lazy interpretation of the idea (just
On Monday 12 May 2008 16.23.46 Bram wrote:
Then what happens if it starts returning 4?
Then the test script will report a FAIL, and users will/might start
ignoring failures.
Which is a bad thing (IMHO).
The todo test indicates that something doesn't behave as it should.
If it suddenly
Quoting nadim khemir [EMAIL PROTECTED]:
On Monday 12 May 2008 16.23.46 Bram wrote:
Then what happens if it starts returning 4?
Then the test script will report a FAIL, and users will/might start
ignoring failures.
Which is a bad thing (IMHO).
The todo test indicates that something doesn't
On Monday 12 May 2008 11:41:58 Bram wrote:
What I'm suggesting is that it outputs something similar for TODO test
that return an unexpected result.
TODO means if it's anything but this, tell me. You're trying to extract two
bits of information from one bit of data. Zombie Claude Shannon
On Mon, May 12, 2008 at 08:41:58PM +0200, Bram wrote:
I'm not saying that it shouldn't change.
What I'm saying is that the value may change but that if it changes I
would like to be informed about it.
Leave your todo test as it was to start with.
Create a new test file
On Monday 12 May 2008 20.41.58 Bram wrote:
Leave your todo test as it was to start with.
Create a new test file development_values_that_shoulnot_change.t in
your developer test directory (that's not just for pod right).
Which is not practical at all.
That means maintaining an extra test
- Original Message
From: Michael G Schwern [EMAIL PROTECTED]
Ah, crud. I need to support it then. Bummer. I'll try to get a release
out there when I can, then.
Don't bother, its a poorly designed feature and likely unused. I don't want
to see it pushed forward into TAP.
OK,
On 8 Sep 2006, at 01:52, Michael G Schwern wrote:
Adrian Howard wrote:
Maybe this is the right time to think about mechanisms supporting
different versions of the TAP protocol?
http://perl-qa.yi.org/index.php/TAP_version
I meant in the context of Ovid's TAPx::Parser code.
Rather than
On 6 Sep 2006, at 14:33, Ovid wrote:
- Original Message
From: Sébastien Aperghis-Tramoni [EMAIL PROTECTED]
Hmm, that's curious. However, if it's undocumented I would argue
against
supporting it right now. What benefit does it gain us?
This comes from the Good Old Test.pm
Adrian Howard wrote:
Maybe this is the right time to think about mechanisms supporting
different versions of the TAP protocol?
http://perl-qa.yi.org/index.php/TAP_version
- Original Message
From: Shlomi Fish [EMAIL PROTECTED]
t/sample-tests/todo in the Test-Harness distribution reads:
print DUMMY_TEST;
1..5 todo 3 2;
ok 1
ok 2
not ok 3
ok 4
ok 5
DUMMY_TEST
As one can see, the 1..5 plan is followed by the todo 3 2; directive.
This is
Selon Ovid [EMAIL PROTECTED]:
As one can see, the 1..5 plan is followed by the todo 3 2; directive.
This is supposed to indicate something about plan ahead todo tests.
[...]
I'd like to know what I should do about this feature, because right now I'm
trying to convert Test-Run to use
- Original Message
From: Sébastien Aperghis-Tramoni [EMAIL PROTECTED]
Hmm, that's curious. However, if it's undocumented I would argue against
supporting it right now. What benefit does it gain us?
This comes from the Good Old Test.pm module:
$ perl -MTest -e 'plan tests = 10,
Shlomi Fish wrote:
t/sample-tests/todo in the Test-Harness distribution reads:
print DUMMY_TEST;
1..5 todo 3 2;
ok 1
ok 2
not ok 3
ok 4
ok 5
DUMMY_TEST
As one can see, the 1..5 plan is followed by the todo 3 2; directive.
This is supposed to indicate something about plan ahead todo tests.
Ovid wrote:
$ perl -MTest -e 'plan tests = 10, todo = [2,4];'
1..10 todo 2 4;
As there are quite some test scripts out there that use it, staying
compatible with it sounds like a prerequisite.
By it do you mean Test.pm or Test.pm's todo feature? The former I can
believe. The latter... I'd
On Wednesday 06 September 2006 22:50, Michael G Schwern wrote:
Shlomi Fish wrote:
t/sample-tests/todo in the Test-Harness distribution reads:
print DUMMY_TEST;
1..5 todo 3 2;
ok 1
ok 2
not ok 3
ok 4
ok 5
DUMMY_TEST
As one can see, the 1..5 plan is followed by the todo
On Wed, Apr 19, 2006 at 07:22:33AM +0200, demerphq wrote:
On 4/19/06, Andy Lester [EMAIL PROTECTED] wrote:
BTW, the patch only shows TODO pass status when no failures occur.
Oh and obviously all of Test::Harness'es tests pass. :-)
This patch doesn't apply against my latest dev
On 4/20/06, Steve Peters [EMAIL PROTECTED] wrote:
On Wed, Apr 19, 2006 at 07:22:33AM +0200, demerphq wrote:
On 4/19/06, Andy Lester [EMAIL PROTECTED] wrote:
BTW, the patch only shows TODO pass status when no failures occur.
Oh and obviously all of Test::Harness'es tests pass. :-)
On Tue, Apr 18, 2006 at 06:30:20PM +0100, Nicholas Clark wrote:
Last time I checked the core has 6 TESTS UNEXPECTEDLY SUCCEEDED
What's the expected number of unexpected successes?
Can it be made to be zero, even though we're testing the test modules?
If so, I think that that would be useful,
Nicholas Clark wrote:
Last time I checked the core has 6 TESTS UNEXPECTEDLY SUCCEEDED
What's the expected number of unexpected successes?
Can it be made to be zero, even though we're testing the test modules?
If so, I think that that would be useful, as it would mean that any (real)
TODO test
One of my unwritten TODOs is to go through the current Perlbug
queue and
write test cases for all the currently testable problems.
Hey! That's one of my unwritten TODOs, too!
In the long term, however, it would be great if Test::Harness
recognized
individual TODO test cases that passed
On 4/18/06, Nicholas Clark [EMAIL PROTECTED] wrote:
Last time I checked the core has 6 TESTS UNEXPECTEDLY SUCCEEDED
What's the expected number of unexpected successes?
Can it be made to be zero, even though we're testing the test modules?
If so, I think that that would be useful, as it would
BTW, the patch only shows TODO pass status when no failures occur.
Oh and obviously all of Test::Harness'es tests pass. :-)
This patch doesn't apply against my latest dev version of
Test::Harness. I'm going to have to massage it manually.
But I like the idea. Thanks.
xoa
--
Andy
On 4/19/06, Andy Lester [EMAIL PROTECTED] wrote:
BTW, the patch only shows TODO pass status when no failures occur.
Oh and obviously all of Test::Harness'es tests pass. :-)
This patch doesn't apply against my latest dev version of
Test::Harness. I'm going to have to massage it manually.
On Fri, Jul 18, 2003 at 01:54:24PM -0700, chromatic wrote:
In general, the person who fixes the bug writes a regression test for
the bug. The pumpkings and other porters are really good about making
sure patches have tests.
Yes, but I'm talking about outstanding bugs that don't have tests
37 matches
Mail list logo
