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
abbreviation. :-)
- Original Message
From: jerry gay jerry@gmail.com
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
On Fri, Jan 23, 2009 at 4:08 PM, jerry gay jerry@gmail.com wrote:
On Fri, Jan 23, 2009 at 12:37, Dave Whipp d...@dave.whipp.name 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
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
Timothy S. Nelson wrote:
method foo() does assumeconserve_sum { ... }
method bar() does ensureconserve_sum { ... }
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.
On Fri, Jan 23, 2009 at 08:01:14AM -0800, Dave Whipp wrote:
For example, I could conceive of a trait:
ok foo, :brokenrakudo
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
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, :brokenrakudo
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
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 it
Larry Wall wrote:
module MyTests {
sub group1 {
ok foo :nametest_foo; ## Q - would a label be better?
}
}
## Elsewhere
MyTests.group1.test_foo is also brokenrakudo;
I guess I don't see offhand what you're trying to do with that.
...
We must keep a clean
separation
On Fri, Jan 23, 2009 at 12:37, Dave Whipp d...@dave.whipp.name 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
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
- Original Message
From: Moritz Lenz mor...@faui2k3.org
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
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
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
- Original Message
From: Moritz Lenz mor...@faui2k3.org
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 just know that
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
Ovid wrote:
One concern is where Larry asks:
I wonder how often we'd have people making the error
of trying to interpoalte into :okbad $x pardner
I'd be one of them. The following is a very common idiom:
for my $method (@methods) {
can_ok $object, $method;
On Thu, Jan 22, 2009 at 09:22, Moritz Lenz mor...@faui2k3.org 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
- Original Message
From: jerry gay jerry@gmail.com
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
On Thu, Jan 22, 2009 at 4:51 PM, jerry gay jerry@gmail.com wrote:
$x == $y
:ok({ .true ?? 'message' !! 'failure message' })
:diag( 'tap comment', :some_tap_propertysome values)
I just want to stress again that I would like to see no focus on just tap
emitters. While I realize this
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.
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
(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
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
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'm
only
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 of a
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
On Tue, Jan 20, 2009 at 1:08 PM, Moritz Lenz mor...@faui2k3.org 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
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 it
30 matches
Mail list logo
