About TestCase >> assert:

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

About TestCase >> assert:

Mariano Martinez Peck
Hi folks:During this week someone wanted to use SqueakDBX in Squeak 3.8 and at the same time another person (thanks Marcelo Cortez!!!) has ported it to Dolphin. And I found something weird in TestCase >> assert:

In Squeak 3.10  TestCase >> assert: aBooleanOrBlock

Squeak 3.8, Dolphin and VAST (I don't know others) have:

TestCase >> assert: aBoolean

So...is there a reason of doing that? Is this expected?

cheers

mariano



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TestCase >> assert:

Alexandre Bergel
> In Squeak 3.10  TestCase >> assert: aBooleanOrBlock
>
> Squeak 3.8, Dolphin and VAST (I don't know others) have:
> TestCase >> assert: aBoolean
>
> So...is there a reason of doing that? Is this expected?


I do not see any particular reason. But having Object>>assert: aBlock  
is important, since one can simply redefine assert: in a class to  
supress all assertions.

Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TestCase >> assert:

Nicolas Cellier
In reply to this post by Mariano Martinez Peck
This is a facility...
If you want to be portable, don't use it.
Maybe (self should: aBlock) is portable if you really want a block...

Nicolas

2009/10/14 Mariano Martinez Peck <[hidden email]>:

> Hi folks:During this week someone wanted to use SqueakDBX in Squeak 3.8 and
> at the same time another person (thanks Marcelo Cortez!!!) has ported it to
> Dolphin. And I found something weird in TestCase >> assert:
>
> In Squeak 3.10  TestCase >> assert: aBooleanOrBlock
>
> Squeak 3.8, Dolphin and VAST (I don't know others) have:
>
> TestCase >> assert: aBoolean
>
> So...is there a reason of doing that? Is this expected?
>
> cheers
>
> mariano
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TestCase >> assert:

Michael Roberts-2
In reply to this post by Mariano Martinez Peck
Early sunit i believe had self should: [1 = 2] vs self assert: 1 = 2.
Perhaps as Alex says the api has moved...

cheers,
Mike

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TestCase >> assert:

csrabak
In reply to this post by Alexandre Bergel
Em  14/10/2009  17:11,  Alexandre  Bergel <[hidden email]> escreveu:

>
> > In Squeak 3.10 TestCase >> assert: aBooleanOrBlock
> > Squeak 3.8, Dolphin and VAST  (I don't know others) have: TestCase
> > >> assert: aBoolean
> > So...is there a reason of doing that? Is this expected?
>
>  I  do not  see any  particular reason.  But  having Object>>assert:
> aBlock  is important,  since one  can simply  redefine assert:  in a
> class to supress all assertions.

Which begs the question: then why the same method is re-implemented in TestCase anyway?


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TestCase >> assert:

Martin McClure-2
[hidden email] wrote:

> Em  14/10/2009  17:11,  Alexandre  Bergel <[hidden email]> escreveu:
>
>>> In Squeak 3.10 TestCase >> assert: aBooleanOrBlock
>>> Squeak 3.8, Dolphin and VAST  (I don't know others) have: TestCase
>>>>> assert: aBoolean
>>> So...is there a reason of doing that? Is this expected?
>>  I  do not  see any  particular reason.  But  having Object>>assert:
>> aBlock  is important,  since one  can simply  redefine assert:  in a
>> class to supress all assertions.
>
> Which begs the question: then why the same method is re-implemented in TestCase anyway?

...just thinking 'aloud'...

TestCase>>assert:, by convention, accepts a Boolean, and could be
extended to also accept a block (and apparently has been so extended in
Squeak).

Object>>assert: *should* accept a block, and it isn't really useful for
it to accept a Boolean.

As Alexandre says, you can suppress assertions by redefining #assert:.
One could also make Object>>assert: depend on some variable somewhere to
determine whether to actually run the assertion blocks. Then you can
turn assertions on and off system-wide, and not be running that
assertion code in the blocks all the time. If you accepted a boolean,
you'd be running the assertion expression whether assertions were turned
on or not, which is undesirable.

It's not too nice if Object>>assert: and TestCase>>assert: take
different kinds of arguments

TestCase>>assert: takes a Boolean. I suspect that's too widely used to
change.

I don't know how widely used Object>>assert: is. Perhaps we could have a
different selector for that which takes a block. Maybe a selector that
implies more strongly that its argument should be a block. Our test
framework (which I believe predates SUnit) uses #run:forResult:, with a
block for the first argument and the expected result of evaluating the
block as the second argument. I like this for a couple of reasons --
run: strongly implies that it should take a block argument, and giving
the expected result separately allows failure messages of the form
"Expected <a>; got <b>" which is handy anytime but *really* useful when
failures are not easily reproducible.


Regards,

-Martin


P.S. -- the following is marginally related:

In performance-critical code that is executed *very* frequently, even
making a message send and checking whether assertions are turned on or
not can have too much impact. In those situations, I banish all
assertions to a subclass, which has methods of this general form:

   someMethod
     | result |
     self assert: [assertions appropriate on entry to this method].
     result := super someMethod.
     self assert: [assertions appropriate on exit from this method].
     ^result.

Then to turn assertions on or off, I have code that can change the class
of the instances, and switch whether new instances are of the
no-assertions class or the with-assertions subclass.

This allows the application to run at full speed when assertions are
turned off, a real advantage in some cases. This also separates the
normal code from the assertion code, which has both advantages and
disadvantages.



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TestCase >> assert:

csrabak
In reply to this post by Mariano Martinez Peck
Em 14/10/2009 17:06, Mariano Martinez Peck <[hidden email]> escreveu:

>     Hi  folks:During this week  someone wanted  to use  SqueakDBX in
> Squeak  3.8 and  at the  same  time another  person (thanks  Marcelo
> Cortez!!!) has ported it to  Dolphin. And I found something weird in
> TestCase >> assert:
>
>     In Squeak 3.10 TestCase >> assert: aBooleanOrBlock
>
>     Squeak 3.8, Dolphin and VAST (I don't know others) have:
>
>     TestCase >> assert: aBoolean
>
>     So...is there a reason of doing that? Is this expected?
>
FWIW in VW it's also TestCase>>assert: aBoolean, and there is not an
Object>>assert: method there.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TestCase >> assert:

csrabak
In reply to this post by Martin McClure-2
Em  14/10/2009  20:59,  Martin  McClure <[hidden email]> escreveu:

>     [hidden email] wrote:
>     > Em 14/10/2009 17:11, Alexandre Bergel escreveu:
>     >
>     >>> In  Squeak 3.10 TestCase  >> assert:  aBooleanOrBlock Squeak
>     >>> 3.8, Dolphin and VAST (I don't know others) have: TestCase
>     >>>>> assert: aBoolean So...is there  a reason of doing that? Is
>     >>> this expected?
>     >> I   do   not   see   any  particular   reason.   But   having
>     >> Object>>assert:  aBlock is  important, since  one  can simply
>     >> redefine assert: in a class to supress all assertions.
>     > Which  begs  the  question:   then  why  the  same  method  is
>     > re-implemented in TestCase anyway?
>
>     ...just thinking 'aloud'...
>
>     TestCase>>assert:, by  convention, accepts a  Boolean, and could
>     be extended to  also accept a block (and  apparently has been so
>     extended in Squeak).

I see.  I _think_ the idea of having it more 'compatible' with other
dialects changing it back to accept a Boolean and keeping
TestCase>>should: aBlock is a better way.

>
>     Object>>assert:  *should* accept  a block,  and it  isn't really
>     useful for it to accept a Boolean.

I was keeping with your and Alexandre's reasoning, but when I look for
HierarchyImplementors of #assert: starting from Object the only one I
get (in a Pharo1.0beta dev image updated to 10470) are:

Object>>assert: {error handling}
  TestCase>>assert: {accessing}

So in Pharo we brought a functionality very up in the hierarchy.  


>     As  Alexandre says,  you can  suppress assertions  by redefining
>     #assert:.  One  could also  make Object>>assert: depend  on some
>     variable  somewhere to  determine  whether to  actually run  the
>     assertion  blocks.  Then you  can  turn  assertions  on and  off
>     system-wide,  and not  be  running that  assertion  code in  the
>     blocks all the time. If you accepted a boolean, you'd be running
>     the assertion  expression whether  assertions were turned  on or
>     not, which is undesirable.
>
>     It's not too nice  if Object>>assert: and TestCase>>assert: take
>     different kinds of arguments
>
>     TestCase>>assert: takes  a Boolean. I suspect  that's too widely
>     used to change.

I agrre as I wrote above, for blocks we have TestCase>>should:.

>     I  don't know  how widely  used Object>>assert:  is.  Perhaps we
>     could  have  a  different   selector  for  that  which  takes  a
>     block.  

I don't either, but I find  strange the complete  hierarchy of classes
of Pharo  having a method  assert: available.  Perhaps I'm blindfolded
and Pharo and Squeak have found a wider use for assertions?  

>     Maybe a  selector that  implies more  strongly  that its
>     argument should be a block.  

I think TestCase>>should: suffices for that.

>     Our test framework (which I believe
>     predates SUnit) uses #run:forResult:, with a block for the first
>     argument and the expected result  of evaluating the block as the
>     second argument.  I like  this for a  couple of reasons  -- run:
>     strongly  implies that  it  should take  a  block argument,  and
>     giving the expected result separately allows failure messages of
>     the form "Expected  ; got " which is  handy anytime but *really*
>     useful when failures are not easily reproducible.

Yes, I see, but I think this is lateral to this discussion!

>
>     Regards,
>
>     -Martin
>
>
>     P.S. -- the following is marginally related:
>
>     In performance-critical code that is executed *very* frequently,
>     even making  a message send and checking  whether assertions are
>     turned on or not can  have too much impact. In those situations,
>     I banish all assertions to a subclass, which has methods of this
>     general form:
>
>     someMethod |  result |  self assert: [assertions  appropriate on
>     entry  to  this  method].   result :=  super  someMethod.   self
>     assert:  [assertions  appropriate  on  exit from  this  method].
>     ^result.
>
>     Then to turn  assertions on or off, I have  code that can change
>     the class of the instances, and switch whether new instances are
>     of the no-assertions class or the with-assertions subclass.
>
>     This allows the application to run at full speed when assertions
>     are  turned off,  a  real  advantage in  some  cases. This  also
>     separates  the normal code  from the  assertion code,  which has
>     both advantages and disadvantages.
>
I really don't follow this, are you using assertions for checking
invariants a la Eiffel?



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TestCase >> assert:

Martin McClure-2
[hidden email] wrote:

>>     TestCase>>assert:, by  convention, accepts a  Boolean, and could
>>     be extended to  also accept a block (and  apparently has been so
>>     extended in Squeak).
>
> I see.  I _think_ the idea of having it more 'compatible' with other
> dialects changing it back to accept a Boolean and keeping
> TestCase>>should: aBlock is a better way.

Agreed.

[...]

>>     I  don't know  how widely  used Object>>assert:  is.  Perhaps we
>>     could  have  a  different   selector  for  that  which  takes  a
>>     block.  
>
> I don't either, but I find  strange the complete  hierarchy of classes
> of Pharo  having a method  assert: available.  Perhaps I'm blindfolded
> and Pharo and Squeak have found a wider use for assertions?  

Ah, sorry for the confusion. What I'm talking about here (and I assumed
Alexandre was as well, but I could be mistaken) is indeed the use of
#assert: or some other message to test runtime invariants. So you'd put
something like:

   self assert: [startIndex < endIndex].

somewhere in the main code of your application, not in test code. The
nice thing about using blocks is that the assertion code inside the
block doesn't run if global assertions are turned off, or if (as
Alexandre suggests) you temporarily override #assert: in your class to
do nothing.

It's this rather separate use that I was suggesting might want a
different selector, and gave #run:forResult: as one possible example.

Regards,

-Martin

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TestCase >> assert:

Stéphane Ducasse
In reply to this post by csrabak
The idea is that one day or later we will have to think about the  
benefit of pre and post condition.
So assert: in object makes a lot of sense.

Now indeed it would be good that all the tests use assert: without  
block and use should: for that case.

Stef
On Oct 15, 2009, at 3:55 AM, [hidden email] wrote:

>
> I don't either, but I find  strange the complete  hierarchy of classes
> of Pharo  having a method  assert: available.  Perhaps I'm blindfolded
> and Pharo and Squeak have found a wider use for assertions?


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TestCase >> assert:

Henrik Sperre Johansen
Why not rename Object>>assert: to should:, so it avoids breaking
polymorphism, and keep TestCase>>assert: reserved for a boolean argument
to stay compatible with SUnit in other dialects?

On the negative side, it might not be as intuitive using should: for
pre/post-assertions, as well as inconvenient to remember the difference
between assert: and should: in TestCases. Not big enough negatives to
outweigh the benefits though, imo.

Cheers,
Henry

Stéphane Ducasse skrev:

> The idea is that one day or later we will have to think about the  
> benefit of pre and post condition.
> So assert: in object makes a lot of sense.
>
> Now indeed it would be good that all the tests use assert: without  
> block and use should: for that case.
>
> Stef
> On Oct 15, 2009, at 3:55 AM, [hidden email] wrote:
>
>  
>> I don't either, but I find  strange the complete  hierarchy of classes
>> of Pharo  having a method  assert: available.  Perhaps I'm blindfolded
>> and Pharo and Squeak have found a wider use for assertions?
>>    
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
>  

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TestCase >> assert:

Alexandre Bergel
In reply to this post by Martin McClure-2
>>>    I  don't know  how widely  used Object>>assert:  is.  Perhaps we
>>>    could  have  a  different   selector  for  that  which  takes  a
>>>    block.
>>
>> I don't either, but I find  strange the complete  hierarchy of  
>> classes
>> of Pharo  having a method  assert: available.  Perhaps I'm  
>> blindfolded
>> and Pharo and Squeak have found a wider use for assertions?

> Ah, sorry for the confusion. What I'm talking about here (and I  
> assumed
> Alexandre was as well, but I could be mistaken) is indeed the use of
> #assert: or some other message to test runtime invariants. So you'd  
> put
> something like:
[...]

This is exactly what I had in mind
I regularly use assert: to describe invariant, pre and postcondition.  
This complement testing pretty well in my opinion.

Cheers,
Alexandre

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TestCase >> assert:

Martin McClure-2
Alexandre Bergel wrote:

>> Ah, sorry for the confusion. What I'm talking about here (and I  
>> assumed
>> Alexandre was as well, but I could be mistaken) is indeed the use of
>> #assert: or some other message to test runtime invariants. So you'd  
>> put
>> something like:
> [...]
>
> This is exactly what I had in mind
> I regularly use assert: to describe invariant, pre and postcondition.  
> This complement testing pretty well in my opinion.

Agreed. I prefer, though, to use BlockClosure>>assert, so usage becomes
something like:

   [2 + 2 = 5] assert.

I see that this is already implemented, based on Object>>assert:


There are inconsistencies that bother me.

* TestCase>>assert: in most Smalltalks accepts only a boolean. In Pharo,
it accepts either a boolean or a block. This makes tests less portable.

* TestCase>>assert:equals: (a very useful method) does not accept a
block. Anyone used to giving blocks to #assert: would probably expect
this method to accept a block.

* Object assert: accepts a boolean or a block. I don't know of any
standard for this.

* BlockClosure>>assert does not take any arguments, so I feel it is very
clean.


Proposed changes: (based on earlier discussion plus personal opinion)

TestCase>>assert: should only accept a boolean. This brings
compatibility with other Smalltalks, and consistency with
TestCase>>assert:equals:.

Object>>assert: should be removed/deprecated in favor of
BlockClosure>>assert. This removes confusion with TestCase>>assert:.

Object>>assert:description: and Object>>assert:descriptionBlock: should
be removed/deprecated in favor of (new)
BlockClosure>>assertWithDescription:, which accepts either a block or a
string. This provides convenient invariant and pre/post condition testing.


Opinions?

-Martin

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TestCase >> assert:

Martin McClure-2
In reply to this post by Henrik Sperre Johansen
Henrik Johansen wrote:
> Why not rename Object>>assert: to should:, so it avoids breaking
> polymorphism, and keep TestCase>>assert: reserved for a boolean argument
> to stay compatible with SUnit in other dialects?
>
> On the negative side, it might not be as intuitive using should: for
> pre/post-assertions, as well as inconvenient to remember the difference
> between assert: and should: in TestCases. Not big enough negatives to
> outweigh the benefits though, imo.
>

Henry,

Sorry, I hadn't read this mail before making a proposal.

I agree that renaming Object>>assert: to #should: would be an
improvement. But I still think it's probably better to remove it
altogether and send #assert to a block. It may just be me, but I've
always felt that as a selector 'should' doesn't really communicate the
intent as well as 'assert'.

Regards,

-Martin

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TestCase >> assert:

Alexandre Bergel
In reply to this post by Martin McClure-2
> Agreed. I prefer, though, to use BlockClosure>>assert, so usage  
> becomes
> something like:
>
>   [2 + 2 = 5] assert.
>
> I see that this is already implemented, based on Object>>assert:

I agree this is more concise, there is no reference to "self" to  
formulate the assertion. Having to use "self" in "self assert:" has  
more to do with an unnecessary convention than bringing a real value.
In that case, disabling assertion has to be done by modifying  
BlockClosure>>assert.

> There are inconsistencies that bother me.
>
> * TestCase>>assert: in most Smalltalks accepts only a boolean. In  
> Pharo,
> it accepts either a boolean or a block. This makes tests less  
> portable.
>
> * TestCase>>assert:equals: (a very useful method) does not accept a
> block. Anyone used to giving blocks to #assert: would probably expect
> this method to accept a block.

The method assert:equals: should accept a block in my opinion.  
TestCase>>assert:equals: may be rewritten as:

assert: expectedAsBlockOrValue equals: actualAsBlockOrValue
        | v1 v2 |
        v1 := expectedAsBlockOrValue value.
        v2 := actualAsBlockOrValue value.
        ^ self
                assert: (v1 = v2)
                description: (self comparingStringBetween: v1 and: v2)



> * Object assert: accepts a boolean or a block. I don't know of any
> standard for this.

No standard as far as I know

> * BlockClosure>>assert does not take any arguments, so I feel it is  
> very
> clean.

But you need to modify it to cancel runtime checks

> Proposed changes: (based on earlier discussion plus personal opinion)
>
> TestCase>>assert: should only accept a boolean. This brings
> compatibility with other Smalltalks, and consistency with
> TestCase>>assert:equals:.

assert:equals: could also be updated.
Some test units in the image use [] as arguments to assert: and deny:.  
StringTest is one of them.

> Object>>assert: should be removed/deprecated in favor of
> BlockClosure>>assert. This removes confusion with TestCase>>assert:.

Ideally, this is valuable. However, there is a number of tests that  
use Object>>assert: (and not only my code :-). ZipEncoderTree is an  
example


> Object>>assert:description: and Object>>assert:descriptionBlock:  
> should
> be removed/deprecated in favor of (new)
> BlockClosure>>assertWithDescription:, which accepts either a block  
> or a
> string. This provides convenient invariant and pre/post condition  
> testing.

#assertWithDescription: is useful yes.

Alexandre

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TestCase >> assert:

csrabak
In reply to this post by Stéphane Ducasse
Em 15/10/2009 04:50,  Stéphane Ducasse <[hidden email]> escreveu:

I see.  Eiffel ideas cross breeding Pharo Smalltalk!
 

>
>     The idea  is that one day or  later we will have  to think about
>     the benefit  of pre  and post condition.   So assert:  in object
>     makes a lot of sense.
>
>     Now  indeed it  would be  good that  all the  tests  use assert:
>     without block and use should: for that case.
>
>     Stef On Oct 15, 2009, at 3:55 AM, [hidden email] wrote:
>
>     > I don't either,  but I find strange the  complete hierarchy of
>     > classes of  Pharo having  a method assert:  available. Perhaps
>     > I'm blindfolded  and Pharo and  Squeak have found a  wider use
>     > for assertions?
>



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TestCase >> assert:

Mariano Martinez Peck
I like the ability I have to generate big and interesting threads from a little question hahaha.

On Thu, Oct 15, 2009 at 8:55 PM, <[hidden email]> wrote:
Em 15/10/2009 04:50,  Stéphane Ducasse <[hidden email]> escreveu:

I see.  Eiffel ideas cross breeding Pharo Smalltalk!

>
>     The idea  is that one day or  later we will have  to think about
>     the benefit  of pre  and post condition.   So assert:  in object
>     makes a lot of sense.
>
>     Now  indeed it  would be  good that  all the  tests  use assert:
>     without block and use should: for that case.
>
>     Stef On Oct 15, 2009, at 3:55 AM, [hidden email] wrote:
>
>     > I don't either,  but I find strange the  complete hierarchy of
>     > classes of  Pharo having  a method assert:  available. Perhaps
>     > I'm blindfolded  and Pharo and  Squeak have found a  wider use
>     > for assertions?
>



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TestCase >> assert:

Stéphane Ducasse
In reply to this post by csrabak
Yes and this is really important because pre and post are valuable for  
software engineering quality
promotion.

Stef

On Oct 16, 2009, at 1:55 AM, [hidden email] wrote:

> Em 15/10/2009 04:50,  Stéphane Ducasse <[hidden email]>  
> escreveu:
>
> I see.  Eiffel ideas cross breeding Pharo Smalltalk!
>
>>
>>    The idea  is that one day or  later we will have  to think about
>>    the benefit  of pre  and post condition.   So assert:  in object
>>    makes a lot of sense.
>>
>>    Now  indeed it  would be  good that  all the  tests  use assert:
>>    without block and use should: for that case.
>>
>>    Stef On Oct 15, 2009, at 3:55 AM, [hidden email] wrote:
>>
>>> I don't either,  but I find strange the  complete hierarchy of
>>> classes of  Pharo having  a method assert:  available. Perhaps
>>> I'm blindfolded  and Pharo and  Squeak have found a  wider use
>>> for assertions?
>>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TestCase >> assert:

Stéphane Ducasse
In reply to this post by Martin McClure-2
Hi martin

I agree should: is not that communicating.
I would favor
        [] assert
        [] assertWithDescription: 'funky preconditions'
               
Stef

On Oct 15, 2009, at 8:35 PM, Martin McClure wrote:

> Henrik Johansen wrote:
>> Why not rename Object>>assert: to should:, so it avoids breaking
>> polymorphism, and keep TestCase>>assert: reserved for a boolean  
>> argument
>> to stay compatible with SUnit in other dialects?
>>
>> On the negative side, it might not be as intuitive using should: for
>> pre/post-assertions, as well as inconvenient to remember the  
>> difference
>> between assert: and should: in TestCases. Not big enough negatives to
>> outweigh the benefits though, imo.
>>
>
> Henry,
>
> Sorry, I hadn't read this mail before making a proposal.
>
> I agree that renaming Object>>assert: to #should: would be an
> improvement. But I still think it's probably better to remove it
> altogether and send #assert to a block. It may just be me, but I've
> always felt that as a selector 'should' doesn't really communicate the
> intent as well as 'assert'.
>
> Regards,
>
> -Martin
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TestCase >> assert:

Stéphane Ducasse
In reply to this post by Martin McClure-2
> There are inconsistencies that bother me.
>
> * TestCase>>assert: in most Smalltalks accepts only a boolean. In  
> Pharo,
> it accepts either a boolean or a block. This makes tests less  
> portable.

+1

> * TestCase>>assert:equals: (a very useful method) does not accept a
> block. Anyone used to giving blocks to #assert: would probably expect
> this method to accept a block.

+1 consistency is nice.

> * Object assert: accepts a boolean or a block. I don't know of any
> standard for this.

me neither

> * BlockClosure>>assert does not take any arguments, so I feel it is  
> very
> clean.

+1

> Proposed changes: (based on earlier discussion plus personal opinion)
>
> TestCase>>assert: should only accept a boolean. This brings
> compatibility with other Smalltalks, and consistency with
> TestCase>>assert:equals:.

+ 1

> Object>>assert: should be removed/deprecated in favor of
> BlockClosure>>assert. This removes confusion with TestCase>>assert:.

deprecation!

> Object>>assert:description: and Object>>assert:descriptionBlock:  
> should
> be removed/deprecated in favor of (new)
> BlockClosure>>assertWithDescription:, which accepts either a block  
> or a
> string. This provides convenient invariant and pre/post condition  
> testing.

Let us do that.
Any taker?

Stef

>
>
> Opinions?
>
> -Martin
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
12