About TestCase >> assert:

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

> 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

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]>:
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

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

[hidden email] wrote:
...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

Em 14/10/2009 17:06, Mariano Martinez Peck <[hidden email]> escreveu:
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

Em  14/10/2009  20:59,  Martin  McClure <[hidden email]> escreveu:

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.  


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!
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

[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

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

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:
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>>>    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

Alexandre Bergel wrote:
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

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

> 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.

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

Em 15/10/2009 04:50,  Stéphane Ducasse <[hidden email]> escreveu:

I see.  Eiffel ideas cross breeding Pharo Smalltalk!
 


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

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



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

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:


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

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:


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

> 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

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