PHPT --SKIPIF--

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Can you tell a test to skip if a previous test failed? Hrm.
I guess  
if (file_exists('previoustest.out')) returns true? Thoughts?
Seems  
hacky ...

- --Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGFWV8h0MUGpYY9OQRAutMAJ9rDignUKaotAXTavzJKyN6kzHopgCg
tEBS
a5U6z8tjbL6ExRRELe9yYJs=
=Mbto
-----END PGP SIGNATURE-----

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Joe Stump wrote:
> Can you tell a test to skip if a previous test failed?
Hrm. I guess if
> (file_exists('previoustest.out')) returns true?
Thoughts? Seems hacky ...

Hi Joe,

Short answer: no

Long answer: Perhaps a bit more information on the problem
you're trying
to solve would help?

You could, theoretically, include the relevant portion of
the test in
your --SKIPIF-- and use that to determine whether to echo
"skip" but if
your failure is fatal error-related, that gets tricky, to
say the least 

Greg

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Basically if you have something like this:

001-test-a.phpt
002-test-b.phpt

I'd like to know in 002-test-b.phpt if 001-test-a.phpt
failed. I was  
able to do this by adding this into my 002-test-b.phpt
file:

- --SKIPIF--
<?php

if (file_exists('002-test-a.out')) {
     echo 'skip 002-test-a.phpt failed';
}

?>

It appears to work fine.

- --Joe


On Apr 5, 2007, at 3:45 PM, Gregory Beaver wrote:

> Joe Stump wrote:
>> Can you tell a test to skip if a previous test
failed? Hrm. I  
>> guess if
>> (file_exists('previoustest.out')) returns true?
Thoughts? Seems  
>> hacky ...
>
> Hi Joe,
>
> Short answer: no
>
> Long answer: Perhaps a bit more information on the
problem you're  
> trying
> to solve would help?
>
> You could, theoretically, include the relevant portion
of the test in
> your --SKIPIF-- and use that to determine whether to
echo "skip"  
> but if
> your failure is fatal error-related, that gets tricky,
to say the  
> least 
>
> Greg

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGFXxWh0MUGpYY9OQRAosEAJ9z29bfBO06t9CUzNH4A6z+b8XXKgCg
qMW4
9akg4lpgYEQyXMgF7SfZASk=
=Ojof
-----END PGP SIGNATURE-----

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Joe Stump wrote:
> Basically if you have something like this:
>
> 001-test-a.phpt
> 002-test-b.phpt
>
> I'd like to know in 002-test-b.phpt if 001-test-a.phpt
failed. I was
> able to do this by adding this into my 002-test-b.phpt
file:
>
> --SKIPIF--
> <?php
>
> if (file_exists('002-test-a.out')) {
>     echo 'skip 002-test-a.phpt failed';
> }
>
> ?>
>
> It appears to work fine.

If you run the tests out of order, it will fail, so you need
to be sure
that the OS will sort them properly.  For instance, try

pear run-tests 001-test-a.phpt 002-test-b.phpt

and see if it still works.

What I meant though is *why* do you need to skip a test if
the previous
test failed?  Why not just let them both fail?

Greg

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> If you run the tests out of order, it will fail, so you
need to be  
> sure
> that the OS will sort them properly.  For instance,
try
>
> pear run-tests 001-test-a.phpt 002-test-b.phpt
>
> and see if it still works.

This works. Running them backwards would cause the check to
not work  
as expected, but it wouldn't fail catastrophically either.

> What I meant though is *why* do you need to skip a test
if the  
> previous
> test failed?  Why not just let them both fail?

Because, if 001-test-a fails and 002-test-b relies on
001-test-a for  
something (ie. data written to the DB, memcache, etc.)
002-tests-b  
isn't actually failed. It's like saying that your test of gd
failed  
when gd isn't installed at all. The test didn't actually
fail because  
it never had a chance of running. It should skip the test
and say why  
and move on.

- --Joe


>
> Greg
>
> -- 
> PEAR Development Mailing List (http://pear.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub
.php
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGFX75h0MUGpYY9OQRAhHKAJ9WMASPb07rhsiPhMrMVuY6w/angwCg
logP
SaiyN6YgT0co3o2ospGIVQY=
=98bc
-----END PGP SIGNATURE-----

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

On Thu, 05 Apr 2007 15:57:59 -0700, Joe Stump wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
>> If you run the tests out of order, it will fail, so
you need to be sure
>> that the OS will sort them properly.  For instance,
try
>>
>> pear run-tests 001-test-a.phpt 002-test-b.phpt
>>
>> and see if it still works.
> 
> This works. Running them backwards would cause the
check to not work as
> expected, but it wouldn't fail catastrophically
either.
> 
>> What I meant though is *why* do you need to skip a
test if the previous
>> test failed?  Why not just let them both fail?
> 
> Because, if 001-test-a fails and 002-test-b relies on
001-test-a for
> something (ie. data written to the DB, memcache, etc.)
002-tests-b isn't
> actually failed. It's like saying that your test of gd
failed when gd
> isn't installed at all. The test didn't actually fail
because it never
> had a chance of running. It should skip the test and
say why and move
> on.

Isn't the point of testing to keep each part as a self
contained beast ?
Anyway I've always believed that tests should be able to run
by them self 
and thus not having the exact problem you are describing


You could take the approach to have a setup/teardown
function in the 
tests to setup the data you need for each individual test.

Regards
Helgi

-- 
There are no stupid questions, only stupid people

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Isn't the point of testing to keep each part as a self
contained  
> beast ?
> Anyway I've always believed that tests should be able
to run by  
> them self
> and thus not having the exact problem you are
describing 

Okay, I'll put it another way. Let's say 001-test-a.phpt
tests class  
Foo. It runs through and finds that Foo isn't behaving as
expected.  
Now, 002-test-b.phpt tests class Bar, which extends from
Foo. Can you  
tell me how to make a test that is "a self contained
beast" on that  
use case (I'd assume using classes, etc. is a somewhat
common use  
case these days).

My argument is that 002-test-b.phpt isn't in a failed state
because  
it's not in a position to be tested in the first place.

- --Joe



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGFY62h0MUGpYY9OQRAsrJAJ9kdo2cpGQaNwajRWrorFMGicycywCg
u9dy
weJcYa9JquXXUaK/9nRnZDo=
=lKpb
-----END PGP SIGNATURE-----

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Joe Stump wrote:
>>> Isn't the point of testing to keep each part as
a self contained beast ?
>>> Anyway I've always believed that tests should
be able to run by them self
>>> and thus not having the exact problem you are
describing 
> 
> Okay, I'll put it another way. Let's say
001-test-a.phpt tests class
> Foo. It runs through and finds that Foo isn't behaving
as expected. Now,
> 002-test-b.phpt tests class Bar, which extends from
Foo. Can you tell me
> how to make a test that is "a self contained
beast" on that use case
> (I'd assume using classes, etc. is a somewhat common
use case these days).
> 
> My argument is that 002-test-b.phpt isn't in a failed
state because it's
> not in a position to be tested in the first place.

Just let both tests fail 

Every time I change one small thing in PEAR, it breaks 200
tests, I
either update all the tests, or change the thing that broke
the test
(usually change the thing that broke the test).  It's a
powerful
incentive to maintain BC

Greg

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php