On Wed, 21 Jan 2009, Damian Conway wrote:
> > Maybe something in all caps. For what it's worth, :OK<> can be typed
> > with one hand while the other holds down the shift key. :)
>
> Typical right-hander fascism!
On the other hands we have :QA ... which also so happens to be an apposite
abbreviati
On Jan 23, 8:59 pm, jswit...@gmail.com (Jason Switzer) wrote:
> That sounds useful on the surface but often turns out to be more difficult
> to do than you might think. There are many cases where tests are performed
> from within loops. Something like S09.237 may or may not be in a loop, may
> be
On Fri, Jan 23, 2009 at 4:08 PM, jerry gay wrote:
> On Fri, Jan 23, 2009 at 12:37, Dave Whipp wrote:
>> I could also imagine writing code that reads from an Sqlite database, and
>> imposes that info onto the test. Whatever mechanism is used, I think we need
>> a language-defined mechanism to supp
- Original Message
> From: jerry gay
> i don't understand the drive to have unique test identifiers. we don't
> have unique identifiers for every code statement, or every bit of
> documentation. why are tests so important/special/different that each
> warrants a unique id?
Actually,
On 2009 Jan 21, at 7:35, Carl Mäsak wrote:
Moritz (>):
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');
I'm trying to explain to myself why I don't like this idea at all. I'm
only partially successfu
On Fri, Jan 23, 2009 at 6:39 PM, Dave Whipp wrote:
> A spec-test is (or should be) different from an ad-hoc test. I want to be
> able to say "test S09.237 passes on pugs but not on Rakudo" (perhaps with a
> nicer name). Unique identifiers allow comparisons of specific tests across
> multiple imp
jerry gay wrote:
i don't understand the drive to have unique test identifiers. we don't
have unique identifiers for every code statement, or every bit of
documentation. why are tests so important/special/different that each
warrants a unique id? that aside, this functionality sounds like it
can
On Fri, Jan 23, 2009 at 12:37, Dave Whipp wrote:
> I could also imagine writing code that reads from an Sqlite database, and
> imposes that info onto the test. Whatever mechanism is used, I think we need
> a language-defined mechanism to supply a stable unique identifier for each
> test, so that i
Larry Wall wrote:
module MyTests {
sub group1 {
ok foo :name; ## Q - would a label be better?
}
}
>> ## Elsewhere
>> MyTests.group1.test_foo is also broken;
I guess I don't see offhand what you're trying to do with that.
...
We must keep a clean
separation between code t
On Fri, Jan 23, 2009 at 11:16:21AM -0800, Dave Whipp wrote:
> I can see that. So the alternative is to give things names and/or tags,
> so that we can attach parameters remotely.
Hmm, well, we also decided not to use any solutions that encourage
putting the metadata too far away from the place i
Larry Wall wrote:
On Fri, Jan 23, 2009 at 08:01:14AM -0800, Dave Whipp wrote:
For example, I could conceive of a trait:
ok foo, :broken
which might downgrade the error to a warning on rakudo, but not on other
implementations.
On the surface that seems like a good idea, and pugs started o
On Fri, Jan 23, 2009 at 08:01:14AM -0800, Dave Whipp wrote:
> For example, I could conceive of a trait:
>
> ok foo, :broken
>
> which might downgrade the error to a warning on rakudo, but not on other
> implementations.
On the surface that seems like a good idea, and pugs started out doing
thi
Timothy S. Nelson wrote:
method foo() does assume { ... }
method bar() does ensure { ... }
Is "ensure" equivalent to the "assert" that you describe above?
Yes. "does ensure" was meant to be an englishification of
"postcondition"; and "does assume" is "precondition".
From the perspec
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
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 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
- 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 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;
>
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;
>
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:
> 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
- 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?
> >
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'
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
- 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:
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: 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
On Wed, Jan 21, 2009 at 13:44, Ovid
wrote:
> - Original Message
>
>> From: Moritz Lenz
>
>> * the word 'is' is overloaded in Perl 6
>>* if we export subs is() and ok(), we clutter the
>> namespace with subs with short names
>>* is() is rather imprecise; it doesn't say *h
- Original Message
> From: Moritz Lenz
> * the word 'is' is overloaded in Perl 6
>* if we export subs is() and ok(), we clutter the
> namespace with subs with short names
>* is() is rather imprecise; it doesn't say *how*
> things are compared.
> So Larry and Patr
On Wed, 2009-01-21 at 14:23 +, Peter Scott wrote:
> On Wed, 21 Jan 2009 13:35:50 +0100, Carl Mäsak wrote:
> > I'm trying to explain to myself why I don't like this idea at all. I'm
> > only partially successful. Other people seem to have no problem with it,
> > so I might just be wrong, or part
On Wed, 21 Jan 2009 13:35:50 +0100, Carl Mäsak wrote:
> Moritz (>):
>> 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');
>
> I'm trying to explain to myself why I don't like this idea at all. I'
Moritz (>):
> 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');
I'm trying to explain to myself why I don't like this idea at all. I'm
only partially successful. Other people seem to have no problem
(Daniel Ruoso also proposed to call the adverb :test
instead of :ok, making it easier to read but a bit
longer; my happiness doesn't depend on the exact name,
but of course we can discuss it once we have settled
on this scheme, if we do so).
My two-cents worth:
The adverb on a boolean chan
Hi
I assume that BDD(Behavior Driven Development) and the vocabulary that
it implies is not a good choice
at this stage ?
:describe("");
$x.should be(1e5) :it("");
and that a module based on the core testing facilities can be built if
someone feels like to.
Well, the vocabulary that i
Larry observed:
> My feeling on this is that the compiler should simply hardwire this
> particular adverb so that all the tests can be autogenerated, and the
> multi system never needs to see those versions.
I strongly agree.
> We are merely hijacking the adverb syntax so that is clear which
>
Hi,
I pretty much like this idea. Very perl6ish :)
- I don't think it's important whether it is called :ok, :OK or :test or
:wellhowdidthatworkout. I assume people who will be testing their
modules/code/etc. will be using more advanced modules for testing
anyway. This is for testing the imple
On Tue, Jan 20, 2009 at 1:08 PM, Moritz Lenz wrote:
> 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:
On Tue, Jan 20, 2009 at 08:08:57PM +0100, Moritz Lenz wrote:
: * We nearly double the number of built-in operators
:by adding an :ok multi
My feeling on this is that the compiler should simply hardwire
this particular adverb so that all the tests can be autogenerated,
and the multi system nev
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.
We also discussed some possible changes to t
39 matches
Mail list logo
