- Original Message
> From: jerry gay
> since the :ok adverb is modifying the operator, perl knows what kind
> of comparison is being attempted, and can automatically give smart
> diagnostics. this point was taken into consideration when the
> adverbial test syntax was originally design
Moritz Lenz wrote:
So I'd like to hear your opinions: do you think
adverb-based testing is a good idea? If you don't like
it, do you see any other good way to tackle the
problems I mentioned above?
After reading everything in this thread to date and in order to
structure my thoughts, I wrot
- Original Message
> From: Moritz Lenz
> So Larry and Patrick developed the idea of creating an
> adverb on the test operator instead:
>
> $x == 1e5 :ok('the :ok makes this is a test');
>
> This is an adverb on the infix:<==> operator, and might
> desugar to something like this:
Darren Duncan wrote:
Dave Whipp wrote:
sub sqrt(Num where { 0 <= $_ <= Real::Max } $x) {
(0..$x/2 :by(Real::Epsilon)).min: { abs $x - $^candidate ** 2 }
}
So do you really mean "as declarative a manner as possible"? Or would
you consider this example to go beyond "possible"?
I would decl
Moritz Lenz wrote:
A few months ago Larry proposed to add some testing
facilites to the language itself, because we want to
culturally encourage testing, and because the test
suite defines the language, so we need to specify the
behaviour of our testing facilities anyway.
If we're going to reva
Moritz Lenz wrote:
$x == 1e5 :ok('the :ok makes this is a test');
I can't help feeling that there's an end-weight problem here: The fact
that it is a test is the essence of statement.
If we're thinking of it as a library, then the MMD way of thinking might
be appropriate: we know it'
- Original Message
> From: Moritz Lenz
> > test Unit::Customer plan 3 {
> > use Customer;
> > my Customer $cust .= new( :fname, :lname);
> > $cust.fname eq 'Billy' :ok;
> >
> > # plan assumes 2 referrals
> > # won't work because we can't interpolate?
> >
Ovid wrote:
> Regarding the disadvantages:
>
>> However nothing in life is free, we pay for it with a
>> few disadvantages:
>> * We nearly double the number of built-in operators
>>by adding an :ok multi
>
> Yes, but conceptually this will be transparent to the end user, right?
> They'll ju
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 ap
Ovid wrote:
> One concern is where Larry asks:
>
> I wonder how often we'd have people making the error
> of trying to interpoalte into :ok
>
>
>
> I'd be one of them. The following is a very common idiom:
>
> for my $method (@methods) {
> can_ok $object, $method;
>
Dave Whipp wrote:
Darren Duncan wrote:
Dave Whipp wrote:
sub sqrt(Num where { 0 <= $_ <= Real::Max } $x) {
(0..$x/2 :by(Real::Epsilon)).min: { abs $x - $^candidate ** 2 }
}
So do you really mean "as declarative a manner as possible"? Or would
you consider this example to go beyond "possib
On Thu, Jan 22, 2009 at 09:22, Moritz Lenz wrote:
> Richard Hainsworth wrote:
> 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;
>
- Original Message
> From: jerry gay
> On Thu, Jan 22, 2009 at 09:22, Moritz Lenz wrote:
> > Richard Hainsworth wrote:
> > 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
On Thu, Jan 22, 2009 at 4:51 PM, jerry gay wrote:
> $x == $y
>:ok({ .true ?? 'message' !! 'failure message' })
>:diag( 'tap comment', :some_tap_property)
I just want to stress again that I would like to see no focus on just tap
emitters. While I realize this is just an example, adverbs
On Thu, 22 Jan 2009, Richard Hainsworth wrote:
4) Testing software is different from debugging or running software. Running
is about providing functionality to the user. Debugging is about getting
expected behaviour and discovering why behaviour exhibited is not what is
expected / specified. T
On Wed, 21 Jan 2009, Dave Whipp wrote:
Moritz Lenz wrote:
A few months ago Larry proposed to add some testing
facilites to the language itself, because we want to
culturally encourage testing, and because the test
suite defines the language, so we need to specify the
behaviour of our testing fa
Hi!
I'd like to get started adding these:
is capitalize(:string($a)), "Pugs Is Cool!", "capitalize works with named
arg"
rakudo and pugs both fail this test. Should I add it anyway? And should I
just mail patches to rakudo...@perl.org? Or should this technically be
pugs?
--
-fREW
fREW Schmidt wrote:
> I'd like to get started adding these:
>
> is capitalize(:string($a)), "Pugs Is Cool!", "capitalize works with named
> arg"
>
> rakudo and pugs both fail this test. Should I add it anyway?
Yes. We have a mechanism for skipping tests that the implementations
fail. Just write
18 matches
Mail list logo