# from nadim khemir
# on Monday 03 December 2007 15:11:
>There is not simple solution to this problem.
There is, but the data needs to be more complicated than a boolean.
Please. Calling it "failure" just gets everyone hung-up on semantics
(and rightly so, because computers are awfully picky about semantics.)
>but I would like to be
> able to check my modules more thorowly and I would like to be able to
> setup cpan so I can say "unexpectedly succeeded" == failed
I would be all-for harness enhancements where "unexpectedly succeeded"
== "unexpectedly succeeded". You could then treat it as "disallow
unexpectedly succeeding results".
Adding machine-readable information to the output (or hooks to the API)
and using it to apply policy is *much* different than optionally and
arbitrarily defining $foo as failure (and, IMO, will cause fewer
plagues of locusts.)
Now, as far as whether this means a non-zero return value from prove, or
some bit of YAML at the end of the output or some-other-thing is quite
a different question.
Also, how is this hooked into CPAN.pm? (I suspect the linkage is
limited to a boolean, which might mean you'll break CPAN::Reporter or
something if you're not careful.) Anybody more-in-the-know care to
comment on how this works now?
The internal API of TAP::Harness already has a pretty rich system for
determining what failed or passed or skipped or todo_passed -- why not
use that to drive some kind of result_policy system?
--Eric
--
Those who cannot remember the past are condemned to repeat it.
--George Santayana
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
