Re: RFD: Built-in testing

2009-01-22 Thread Ovid
- 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

Re: RFD: Built-in testing

2009-01-22 Thread Richard Hainsworth
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

Re: RFD: Built-in testing

2009-01-22 Thread Ovid
- 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:

Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)

2009-01-22 Thread Dave Whipp
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

Re: RFD: Built-in testing

2009-01-22 Thread Dave Whipp
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

Re: RFD: Built-in testing

2009-01-22 Thread Dave Whipp
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'

Re: RFD: Built-in testing

2009-01-22 Thread Ovid
- 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? > >

Re: RFD: Built-in testing

2009-01-22 Thread Moritz Lenz
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

Re: RFD: Built-in testing

2009-01-22 Thread Moritz Lenz
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

Re: RFD: Built-in testing

2009-01-22 Thread Moritz Lenz
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; >

Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)

2009-01-22 Thread Darren Duncan
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

Re: RFD: Built-in testing

2009-01-22 Thread 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 want such a feature?). It shouldn't be too hard to do; >

Re: RFD: Built-in testing

2009-01-22 Thread Ovid
- 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

Re: RFD: Built-in testing

2009-01-22 Thread jason switzer
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

Re: RFD: Built-in testing

2009-01-22 Thread Timothy S. Nelson
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

Re: RFD: Built-in testing

2009-01-22 Thread Timothy S. Nelson
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

perl6 Testing

2009-01-22 Thread fREW Schmidt
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

Re: perl6 Testing

2009-01-22 Thread Moritz Lenz
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