There are a few interesting points on which I'd like to comment
Richard Hainsworth wrote:
> In other words, test functionality sufficient for the compiler may not
> be adequate for module testing. But other functions can be developed in
> Test modules that can be hooked into a general testing approach.
That's clear to me, and our current approach doesn't require all tests
to be written as adverbs - only the most common ones. For example I
think the eval_lives_ok and eval_dies_ok functions will remain, as well
as a few others.
> a) a global variable $*TESTING which defaults to FALSE (or should it be
> $?TESTING ?)
>
> It could be set lexically so that specific software / modules can be
> tested without triggering tests in other used modules.
I don't think that lexical is good choice, since it means that you can
only ever turn it on from the inside, which means that every code that
contains TEST blocks also has to have some logic for switching on
$*TESTING - which smells like a lot of code duplication.
> b) When $*TESTING is TRUE, any TEST block is executed.
>
> c) Within a TEST block, the tenary <?? !!> is defined slightly
> differently, thus for
> <perl6 boolean expression> ?? <diagnostic if expression is TRUE> !!
> <diagnostic if expression is FALSE>;
>
> <perl6 boolean expression> is guaranteed to return Boolean::FALSE if an
> exception or failure condition is encountered when evaluating it.
>
> Some advantages of this approach over :OK<>:
> - no new behaviour outside of a TEST block is defined, no change to
> adverbs or boolean operators.
That is an advantage, but the definition of the :OK adverbs could also
somehow magically be scoped to TEST blocks.
> - any expression that leads to a boolean result (note that :OK is
> suggested to be defined only on boolean operators) can be included in
> the expression, eg., an entire block.
The same can be achieved with ? ... :OK
> - The programer has control over both the "True" diagnostic, as in the
> :OK<> syntax, but also over the 'False' diagnostic, thus allowing a
> degree of introspection on the component of the expression, which the
> programmer has more knowledge about than the compiler.
Sadly he not only has the control, but is also obliged to cater for both
cases. I'm lazy, and I don't want to type all of my messages twice.
But it is interesting to think about the case where a user wants two
different diagnostic test messages (to all the testing gurus out there:
do you actually want such a feature?). It shouldn't be too hard to do;
maybe just :OK('True message', 'False message')?
> - Since the variables used in the boolean expression are available to
> the programmer for both diagnostics, there is no need for special magic
> to generate the failure diagnostic, which seems to be the situation with
> :OK<>.
No, the :OK solves that problem, it doesn't generate it.
Also it implies again that the programmer actually has to do it himself,
which goes against the principle of laziness.
> - Since it is the programmer that defines the False diagnostic, no extra
> autogenerated macros are needed.
> - The minimum that is needed for a test would be to specify a 'true'
> diagnostic and the $! error variable, eg.,
> TEST { 2 == 2 ?? say 'constants are constants' !! say $! };
And what would $! contain in this case?
(I think the real objection from is that ?? !! is just plain ugly; but
then again I might be blind here...)
> d) A TEST block is specified to react to exceptions / failures in a
> different manner than in normal blocks. Uncaught exceptions are
> discarded at the end of a block. Thus compiler / module / software
> failures do not stop the software from continuing, unless specifically
> required by the programmer to do so within the block.
That's quite a good idea.
> e) Other functions that are useful in test suites, such as plan, could
> be defined later as wrappers around "?? !!"
Or just stay as plain functions.
Cheers,
Moritz
